|
I'd be interested to know how early versions of C would handle it.
I expect the increment should happen first (if indeed it's handled by a hardware instruction), then the original value assigned back, yielding the infinite loop.
|
|
|
|
|
I have used dozens of C compilers over the years, most if not all of them did not care about
the ambiguity, but simply evaluated the entire expression including side-effects before storing
the result. It is only with the advent of RISC and advanced instruction scheduling that
things got unclear, and the undefined stuff got introduced.
Anyway, I learned long ago not to write code that would be ambiguous or just difficult to read
and understand, so it never really mattered ... What is the point of studying a page of rules
to make sure something is/isn't ambiguous or undefined, where one could add an intermediate
statement or a pair of parentheses? It isn't APL or Lisp after all.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
It seems assigning the value of an incremented variable to itself overrides the increment operation.
If not, it wouldn't actually matter in which order the operations are executed as the result would be the same:
increment comes first:
i = 0 // i = 0
i++ = 1 // i = 1
i = i // i = 1
result: 1
assignment comes first
i = 0 // i = 0
i = i // i = 0
i++ // i = 1
result: 1
|
|
|
|
|
I agree. If the code would look like this:
a = i++;
Then a would be assigned the value of i and i would be incremented after that, so I would expect in given case that in first iteration i would be assigned value of 0 then i would be incremented. Weird indeed.
modified 19-Nov-18 21:01pm.
|
|
|
|
|
Today, I was reviewing the code of a particular module that a vendor who I had outsourced the product had delivered. There was one interesting line. He is reading input from .NET Cache. Good! He is trying to enhance the performance instead of making a costly remoting call.
He is also making a not null check after getting the elements from cache. It sounds still good right?
Well! Now the fun is; there is nothing to handle when cache is null. When I contacted him for this reckless coding horror, the coolest reply was 'IIS needs to be reset when cache gets emptied'.
Is guillotine available in India?
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Vasudevan Deepak K wrote: Is guillotine available in India?
That's too humane. North Korea is always available as a harsher alternative.
ROFLOLMFAO
|
|
|
|
|
another example of promising the earth and cutting quality corners to meet the targets.. its just a case of a "developer" being lazy
|
|
|
|
|
PeterTheGreat wrote: another example of promising the earth and cutting quality corners to meet the targets.. its just a case of a "developer" being lazy
Yes, and probably a you-get-what-you-pay-for kind of thing, too.
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
This guy walks into a bar and...
|
|
|
|
|
Vasudevan Deepak K wrote: When I contacted him for this reckless coding horror, the coolest reply was 'IIS needs to be reset when cache gets emptied'.
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
I cant tell you how many of these ive cleaned up in recent months:
if(HttpContext.Current.Cache["someKey"] != null)<br />
{<br />
SomeClass someClass = (SomeClass)HttpContext.Current.Cache["someKey"];<br />
}
The problem being that occasionaly the cache item is expired between lines 1 & 2 leading to rather hard to spot null instance exceptions when trying to use someClass.
|
|
|
|
|
Within one of my company's XSLT document's, I came across the following. Seems to be an XSLT version of a familiar coding horror...
<xsl:for-each select="fl:values/fl:dataItem[@field='fl_name']>
<xsl:if test="position()=1">
Output Here
</xsl:if>
</xsl:for-each>
|
|
|
|
|
From time to time it is necessary for me to code xslt. Each time is a horror.
the horror
the horror
|
|
|
|
|
Personally, I'm torn. I do like the declarative nature of specifying transforms on XML documents. However, two problems remain:
1. XML. Fine for structured data passing between systems. I use it regularly for these purposes. However, as a programming language, I'd say it leaves something to be desired. I'm a C-family developer (C++, Java, C#) and appreciate the terseness, so XSLT makes me shudder with its verbosity.
2. As with many scripting languages, if used well code is fairly readable, but put it in the hands of a less capable developer, and the source is virtually unreadable.
Obviously what we need is an XSLT transform to transform badly written XSLT into well-written XSLT  , and a transform to render (and the reverse) XSLT to more user- (i.e. developer) friendly syntax.
|
|
|
|
|
Well, I don't create XSLTs on a daily basis, only once a month. Each time I have to go back to look at already created ones to see how to do it. It just doesn't seem natural to me, especially dealing with variables and parameters.
When I look at XSLTs in bigger projects that have been worked on for a while (by other people) - it makes XSL to look like a self-obfuscating language. People tend to put the whole application into one file (doesn't matter if it got 10.000 lines), do not properly group things, use copy & paste and the rest is done by the overhead of tags and symbols through XML.
It makes me think XSL is generally treated as throw-away code, like prototypes going into production.
|
|
|
|
|
Doc Lobster wrote: People tend to put the whole application into one file (doesn't matter if it got 10.000 lines), do not properly group things, use copy & paste and the rest is done by the overhead of tags and symbols through XML.
Ouch. Well, slap 'em around a bit. There's just no excuse for that.
|
|
|
|
|
Doc Lobster wrote: From time to time it is necessary for me to code xslt. Each time is a horror.
Eh, not so sure about that. Sure, the syntax is horrible, but the semantics make sense IMHO.
|
|
|
|
|
From time to time, it is necessary for me to review procedural XML translation code from people who don't know how to use XSLT. Each time is a horror... 
But who is the king of all of these folks?
|
|
|
|
|
Spot on - I'm having just such a horror going through current use in my project.
I think though that many developer's expect just to leap into XSLT as with most languages, without observing that it requires a paradigm shift from imperative to declarative logic.
Still hate the syntax though. XML is just way to verbose for some applications. I've heard justifications that a tree-like structure is well suited to such tasks, but as far I'm aware most parsers form a tree (Abstract Syntax Tree) representing the program structure, so that doesn't cut ice with me.
|
|
|
|
|
We have some third-party software that lets message objects accumulate in a huge LinkedList. How huge? They actually let it grow to fill up the heap and then catch the OutOfMemoryError. Even ignoring the question of whether this is a good design decision, their error-handling method leaves something to be desired.
if (throwable isinstance OutOfMemoryError)
{
System.gc();
throwable.printStackTrace();
}
If you don't instantly see what's wrong with that, here are some hints:
- The JVM will always attempt a garbage collection before throwing an
OutOfMemoryError. - Stack traces require string manipulation. Strings require memory...
|
|
|
|
|
ClementsDan wrote: If you don't instantly see what's wrong with that, here are some hints:
The JVM will always attempt a garbage collection before throwing an OutOfMemoryError.
Stack traces require string manipulation. Strings require memory...
But is this documented (in the Java API) along side the System.gc(); call? If not it should be, and would prevent such superfluous calls.
WPF - Imagineers Wanted
Follow your nose using DoubleAnimationUsingPath
|
|
|
|
|
ClementsDan wrote: The JVM will always attempt a garbage collection before throwing an OutOfMemoryError
Really? It does? Because the .NET garbage collector does not.
(Tess' MSDN blog.)
|
|
|
|
|
Not true. See Maoni's blog at http://blogs.msdn.com/maoni/archive/2006/06/06/when-memory-is-running-low.aspx[^].
"If you don't have enough physical storage we will fail when we need to commit memory. We attempt a GC at this point and if afterwards there's still not enough physical storage to commit we will throw an OOM.
"When you have a page file, physical storage includes both physical memory and the page file." -- from comment #3[^].
So the order goes:
- application tries to allocate memory
- existing heap VM segments are full
- try to create new segment
- cannot create a new segment (out of VA space or commit limit reached)
- performs a GC to compact heap
- if still not enough space available, fails with OutOfMemoryException.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
From Tess' blog:
"Virtual memory allocations are not necessarily (or very seldom) lined up nicely in memory. For example, dll’s have preferred loading addresses so gaps are left between them, and virtual allocations that have been de-allocated will also leave gaps. This means that even though you can address 2 GB of virtual memory you may not be able to use it all since when enough memory is used, the memory will look somewhat like a Swiss cheese and your plug might have a big enough hole to fit in.
This is what happens when you get an OutOfMemory exception."
It seems to me like what these two blogs are saying is conflicting, and I don't know which one to believe.
|
|
|
|
|
actually they're both right.
What Tess is saying is that even though the total free memory you have may be in theory enough to satisfy the request, it may be fragmented into many free blocks. None of these free blocks is large enough to satisfy the request.
Silence is the voice of complicity.
Strange women lying in ponds distributing swords is no basis for a system of government. -- monty python
Might I suggest that the universe was always the size of the cosmos. It is just that at one point the cosmos was the size of a marble. -- Colin Angus Mackay
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
