What about that new fangled plus plus thingie?



  • Here's a snippet from a C# for-loop:

    for (int i = 0; (i < this.MyCollection.Length); i = (i + 1)) 
    

    If you don't actually need the index other than to access the element, then I much prefer "foreach" to "for".

    foreach (MyThingie thingie in this.MyCollection) 
    

    Some folks don't like "foreach". But (i + 1)? Why??

    BTW -- the instance variable MyCollection might make you wonder about our naming conventions. As far as I can tell, the corporate standard for instance variables is random choice for initial cap vs. initial lower case. And the "Collection" is really an array. Harumph!



  • @rstinejr said:

    for (int i = 0; (i < this.MyCollection.Length); i = (i + 1))

    Yay for gratuitous parentheses and not knowing about the ++ operator?



  • @rstinejr said:


    Some folks don't like "foreach".

    I found the hidden WTF.



  • @lettucemode said:

    @rstinejr said:


    Some folks don't like "foreach".

    I found the hidden WTF.

    Those are German golfers...
    Fore! pow Ach!!



  • @ekolis said:

    @rstinejr said:
    for (int i = 0; (i < this.MyCollection.Length); i = (i + 1))
    Yay for gratuitous parentheses and not knowing about the ++ operator?
    Well atleast you call them parentheses.



  • @rstinejr said:

    BTW -- the instance variable MyCollection might make you wonder about our naming conventions. As far as I can tell, the corporate standard for instance variables is random choice for initial cap vs. initial lower case. And the "Collection" is really an array. Harumph!

    I was just going to ask about that, not being a C# bod: does C# have an Iterator, and do C# coders tend towards Collections rather than Arrays?

    (yes, I know in this example they didn't... I wanted to know about non-WTF C# code)



  • @Cassidy said:

    @rstinejr said:

    BTW -- the instance variable MyCollection might make you wonder about our naming conventions. As far as I can tell, the corporate standard for instance variables is random choice for initial cap vs. initial lower case. And the "Collection" is really an array. Harumph!

    I was just going to ask about that, not being a C# bod: does C# have an Iterator, and do C# coders tend towards Collections rather than Arrays?

    (yes, I know in this example they didn't... I wanted to know about non-WTF C# code)

    We call them enumerators.  And yes, we tend towards collections over arrays.  Unless you're my coworker working on a web interface.


  • The real wtf is using [url=http://msdn.microsoft.com/en-us/library/system.array.length%28v=vs.100%29.aspx].Length[/url] instead of GetLength(0), right?

    Sorry, I just remembered the pain of using .Length on a multi-dimensional array in C#.  Who in their right mind at Microsoft thought it was a good idea to return the total number of elements in the entire array rather than the number of elements in the first dimension?  Particularly if you used Java before C#, in which .length is just the number of elements in the first dimension.



  • Douglas Crockford (and therefore JSLint) prefers i+=1 over i++, so it's not just a newbie thing.



  • @Jaime said:

    Douglas Crockford (and therefore JSLint) prefers i+=1 over i++, so it's not just a newbie thing.

    Any particular reason why?

    And technically it should be ++i, not i++..



  • @morbiuswilters said:

    @Jaime said:
    Douglas Crockford (and therefore JSLint) prefers i+=1 over i++, so it's not just a newbie thing.

    Any particular reason why?

    And technically it should be ++i, not i++..

    From here
    @Douglas Crockford said:
    The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by encouraging excessive trickiness. They are second only to faulty architecture in enabling to viruses and other security menaces. Also, preincrement/postincrement confusion can produce off-by-one errors that are extremely difficult to diagnose.



  • @Jaime said:

    @morbiuswilters said:
    @Jaime said:
    Douglas Crockford (and therefore JSLint) prefers i+=1 over i++, so it's not just a newbie thing.

    Any particular reason why?

    And technically it should be ++i, not i++..

    From here
    @Douglas Crockford said:
    The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by encouraging excessive trickiness. They are second only to faulty architecture in enabling to viruses and other security menaces. Also, preincrement/postincrement confusion can produce off-by-one errors that are extremely difficult to diagnose.

    Excessive trickiness? Enabling viruses and other security menaces? WTF is he on about? I'm starting to suspect Douglas Crockford might be an lunatic.



  • @powerlord said:

    The real wtf is using .Length instead of GetLength(0), right?

    No.  We don't even know if this is an array, much less a multi-dimensional array.  It probably doesn't have that method.

    @morbiuswilters said:

    And technically it should be ++i, not i++..
    Eh.  I use ++i, but I'm pretty sure the compiler optimizes the handle away in any modern system, especially C#. 

     

    As for "excessive trickiness" (in C++, from memory):

    while(*dest++ = *src++);



  • @morbiuswilters said:

    Excessive trickiness? Enabling viruses and other security menaces? WTF is he on about? I'm starting to suspect Douglas Crockford might be an lunatic.

    JSLint is a little extreme. But to be fair, every instance of excessive trickiness I can remember uses ++ somewhere in it. Duff's device comes to mind right off the bat. Crockford's stance on the increment operator has been criticized widely.

    However, the point still stands that a competent professional programmer may actually prefer the code that was posted above as a WTF (other than the excessive parentheses).



  • @Sutherlands said:

    @morbiuswilters said:
    And technically it should be ++i, not i++..
    Eh.  I use ++i, but I'm pretty sure the compiler optimizes the handle away in any modern system, especially C#.

    Yes, most do, but it's still incorrect to do i++ for a simple increment. (And there's really no good reason to use a postincrement anyway.) It's not an issue of optimization so much as it's an issue of semantics.

    @Sutherlands said:

    As for "excessive trickiness" (in C++, from memory):

    while(*dest++ = *src++);

    Which, of course, is meaningless in Javascript. I mean, I guess you can probably abuse ++ in Javascript if you really wanted to, but that's true of every single language feature.



  • @Jaime said:

    However, the point still stands that a competent professional programmer may actually prefer the code that was posted above as a WTF (other than the excessive parentheses).

    Anybody, who uses a for loop in place where foreach loop would have been simpler might be a professional programmer, but they are definitely not competent.



  • @Jaime said:

    From here
    [quote user="Douglas Crockford"]The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by encouraging excessive trickiness. They are second only to faulty architecture in enabling to viruses and other security menaces. Also, preincrement/postincrement confusion can produce off-by-one errors that are extremely difficult to diagnose.
    [/quote]

    God forbid a user find a way to inject code into something that runs... on their own system...

    Unless he's one of those people who don't validate input coming from client-side JavaScript or user Node.js.



  • @lettucemode said:

    @rstinejr said:


    Some folks don't like "foreach".

    I found the hidden WTF.

    I love foreach, but I'm a PHP guy in my day job. So I'd just like to add my $.02 that in PHP, a foreach loop looks like this:

    foreach($set as $element)

    I know, I know: PHP is TRWTF. But IMO that's one of the more moronic ones in the language.



  • @powerlord said:

    The real wtf is using .Length instead of GetLength(0), right?

    Sorry, I just remembered the pain of using .Length on a multi-dimensional array in C#.  Who in their right mind at Microsoft thought it was a good idea to return the total number of elements in the entire array rather than the number of elements in the first dimension?  Particularly if you used Java before C#, in which .length is just the number of elements in the first dimension.

    There are no multidimensional arrays in Java.

     



  • Not sure if it still is this way, but doesn't Foreach give you the elements in a 'random' order?



  • @powerlord said:

    Who in their right mind at Microsoft thought it was a good idea to return the total number of elements in the entire array rather than the number of elements in the first dimension?

    If I were that person (who I am not) I'd figure that the length of an array should equal the number of elements in the array. Frankly, the fact that you'd expect any other number seems weird to me.



  • @toon said:

    If I were that person (who I am not) I'd figure that the length of an array should equal the number of elements in the array. Frankly, the fact that you'd expect any other number seems weird to me.
     

    Really? You really think that? There's a level of hell reserved for people who think like that...


  • ♿ (Parody)

    @toon said:

    @powerlord said:
    Who in their right mind at Microsoft thought it was a good idea to return the total number of elements in the entire array rather than the number of elements in the first dimension?

    If I were that person (who I am not) I'd figure that the length of an array should equal the number of elements in the array. Frankly, the fact that you'd expect any other number seems weird to me.

    If you were asked about the length of a rectangular prism, would you compute the area of a face, or just go right to the volume?



  • @boomzilla said:

    If you were asked about the length of a rectangular prism, would you compute the area of a face, or just go right to the volume?

    @ASheridan said:
    Really? You really think that? There's a level of hell reserved for people who think like that...

    Ah, I see now. That was a real WTFy comment of mine. Excuse me while I attempt to wrench this foot out of my mouth...



  • @MiffTheFox said:

    @Jaime said:
    From here
    @Douglas Crockford said:
    The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by encouraging excessive trickiness. They are second only to faulty architecture in enabling to viruses and other security menaces. Also, preincrement/postincrement confusion can produce off-by-one errors that are extremely difficult to diagnose.

    God forbid a user find a way to inject code into something that runs... on their own system...

    Unless he's one of those people who don't validate input coming from client-side JavaScript or user Node.js.

    Never heard of an XSS attack then?

    If you can inject JS onto a page and can get someone else to visit such an injected page, you've just injected code onto _their_ computer. Such code could steal cookies, perform website actions with their account, etc... Remember the days of MySpace worms?



  • @boomzilla said:

    If you were asked about the length of a rectangular prism, would you compute the area of a face, or just go right to the volume?
     

    A multidimensional array is a set of discrete points, not a volume.

    What is the length of 8-bit RGB colour space?



  • @dhromed said:

    @boomzilla said:

    If you were asked about the length of a rectangular prism, would you compute the area of a face, or just go right to the volume?
     

    A multidimensional array is a set of discrete points, not a volume.

    What is the length of 8-bit RGB colour space?

    Zilla's point helped me clearly see what my error was. It was a metaphor, rather than an analogy. Also, 8-bit RGB color space, isn't an array, is it?


  • ♿ (Parody)

    @dhromed said:

    @boomzilla said:
    If you were asked about the length of a rectangular prism, would you compute the area of a face, or just go right to the volume?

    A multidimensional array is a set of discrete points, not a volume.

    Yes, but I've never seen a set's measurement described as "length." If the method in question were "size," then it would make sense. Length is a measurement of a single dimension. A multidimensional array is, by definition, not of a single dimension.

    @dhromed said:

    What is the length of 8-bit RGB colour space?

    I'm not sure "length" makes sense here. I suppose the implementation could be a total of 8-bits, so you could consider it an array of 8 bits, or a single byte. Or maybe it's an array of three color values. It would depend upon the implementation.



  • @Weps said:

    Not sure if it still is this way, but doesn't Foreach give you the elements in a 'random' order?

    When was it random? The foreach returns the elements according to how the enumerator is implemented. So unless you change the collection between foreachs, it won't change.



  • @Weps said:

    Not sure if it still is this way, but doesn't Foreach give you the elements in a 'random' order?

    foreach uses the enumerator on the class it's enumerating. I've yet to run across an enumerator that's non-deterministic.


  • @boomzilla said:

    @dhromed said:
    @boomzilla said:
    If you were asked about the length of a rectangular prism, would you compute the area of a face, or just go right to the volume?

    A multidimensional array is a set of discrete points, not a volume.

    Yes, but I've never seen a set's measurement described as "length." If the method in question were "size," then it would make sense. Length is a measurement of a single dimension. A multidimensional array is, by definition, not of a single dimension.

    I think everyone is looking at this the wrong way. Considering that arrays don't also have Width and Height properties, I think it's safe to assume that Length is not referring to a spatial dimension. Length is the size of the array, such that the memory footprint of the array is Length * sizeof(T) + object overhead (If T is a reference type, then sizeof(T) is the size of a pointer, but that's beside the point).

    Consider if Length was actually the size of dimension 0. Well, now there's two ways to get the size of dimension 0, which is a violation of DRY. Further, dimensions 1+ only have one way to retrieve them, which is weird. Also, what if you want to know the total number of elements? Well, the computer knows, but it isn't telling you, so you need to calculate it manually: GetUpperBound(0) * GetUpperBound(1) * GetUpperBound(2) * ...

    Finally, the documentation explicitly spells it out for you, so there shouldn't be any reason for confusion in the first place:

    @MSDN said:

    Length Gets a 32-bit integer that represents the total number of elements in all the dimensions of the Array.

    @boomzilla said:

    @dhromed said:
    What is the length of 8-bit RGB colour space?

    I'm not sure "length" makes sense here. I suppose the implementation could be a total of 8-bits, so you could consider it an array of 8 bits, or a single byte. Or maybe it's an array of three color values. It would depend upon the implementation.

    The length of 8-bit colour space is the number of unique colours that can be represented in 8-bits. Doesn't matter if you use something like RRGGGBBB or if you go for an indexed palette scheme, the number of unique colours is still only 256. Thus, RGBColourSpace.Length == 256.



  • @serguey123 said:

    @Weps said:

    Not sure if it still is this way, but doesn't Foreach give you the elements in a 'random' order?

    When was it random? The foreach returns the elements according to how the enumerator is implemented. So unless you change the collection between foreachs, it won't change.

    Should not have used the word "random".What I meant was that ForEach does not necessarily go through the elements in the same order as a For - loop. That's why (see op) some guys don't like "foreach", I assume.



  • @Weps said:

    @serguey123 said:
    @Weps said:

    Not sure if it still is this way, but doesn't Foreach give you the elements in a 'random' order?

    When was it random? The foreach returns the elements according to how the enumerator is implemented. So unless you change the collection between foreachs, it won't change.

    Should not have used the word "random".What I meant was that ForEach does not necessarily go through the elements in the same order as a For - loop. That's why (see op) some guys don't like "foreach", I assume.

    Technically, nothing is required of an enumerator. This is perfectly legal:

    Random r = new Random();
    while(true) {
        yield return r.Next(int.MinValue, int.MaxValue);
    }

    In practice, enumerators for ordered collections (ICollection<T>, IList<T>, etc) are likely just wrappers around a for loop that enumerates the collection. Enumerators for unordered collections (IDictionary<T,T>, ISet<T>, etc) are undefined, but they will be consistent (at least, as long as you don't modify the collection in between).



  • @Weps said:

    t ForEach does not necessarily go through the elements in the same order as a For - loop.

    Depends on how the the for loop and the enumerator are implemented. Default implementations work fine.


  • ♿ (Parody)

    @pkmnfrk said:

    I think everyone is looking at this the wrong way. Considering that arrays don't also have Width and Height properties, I think it's safe to assume that Length is not referring to a spatial dimension. Length is the size of the array, such that the memory footprint of the array is Length * sizeof(T) + object overhead (If T is a reference type, then sizeof(T) is the size of a pointer, but that's beside the point).

    I think we understand why they did it. We're just pointing out why they must have been on crack to have seriously considered doing so. Because they've either now ignored the meaning of the word length and twisted it to mean something that it doesn't mean, or they're exposing an implementation detail that's not appropriate for this level of abstraction (maybe the "leaf" arrays are stored in completely separate memory locations...maybe it's stored sparsely in other ways...who knows?...who should care?).

    @pkmnfrk said:

    Consider if Length was actually the size of dimension 0. Well, now there's two ways to get the size of dimension 0, which is a violation of DRY. Further, dimensions 1+ only have one way to retrieve them, which is weird. Also, what if you want to know the total number of elements? Well, the computer knows, but it isn't telling you, so you need to calculate it manually: GetUpperBound(0) * GetUpperBound(1) * GetUpperBound(2) * ...

    What are you talking about? GetUpperBound doesn't return the same thing as the length. I'm not a .Net guy, but GetLength(int) does what you'd think it does based on its name. This API is starting to sound like the PHP guys designed it.

    @pkmnfrk said:

    Finally, the documentation explicitly spells it out for you, so there shouldn't be any reason for confusion in the first place:

    Look, we get what the method actually does. A well documented, retarded method is still retarded.

    @pkmnfrk said:

    @boomzilla said:
    @dhromed said:
    What is the length of 8-bit RGB colour space?

    I'm not sure "length" makes sense here. I suppose the implementation could be a total of 8-bits, so you could consider it an array of 8 bits, or a single byte. Or maybe it's an array of three color values. It would depend upon the implementation.

    The length of 8-bit colour space is the number of unique colours that can be represented in 8-bits. Doesn't matter if you use something like RRGGGBBB or if you go for an indexed palette scheme, the number of unique colours is still only 256. Thus, RGBColourSpace.Length == 256.

    This makes sense if you define the space as having one dimension. That was never specified. You've also assumed that the metric is number of colors. Which is fine, but it's an implementation detail, and no more valid than other representations.



  • @Bulb said:

    @Jaime said:

    However, the point still stands that a competent professional programmer may actually prefer the code that was posted above as a WTF (other than the excessive parentheses).

    Anybody, who uses a for loop in place where foreach loop would have been simpler might be a professional programmer, but they are definitely not competent.

     

    Also we don't see what is inside the loop, so you may not be able to use a foreach as the MyCollection may be getting modified inside the loop (which foreach can't handle).



  • @boomzilla said:

    @pkmnfrk said:
    I think everyone is looking at this the wrong way. Considering that arrays don't also have Width and Height properties, I think it's safe to assume that Length is not referring to a spatial dimension. Length is the size of the array, such that the memory footprint of the array is Length * sizeof(T) + object overhead (If T is a reference type, then sizeof(T) is the size of a pointer, but that's beside the point).

    I think we understand why they did it. We're just pointing out why they must have been on crack to have seriously considered doing so. Because they've either now ignored the meaning of the word length and twisted it to mean something that it doesn't mean, or they're exposing an implementation detail that's not appropriate for this level of abstraction (maybe the "leaf" arrays are stored in completely separate memory locations...maybe it's stored sparsely in other ways...who knows?...who should care?).

    It's an array. It's well defined. There are no leaf arrays, it's a one dimensional contiguous block of memory. The compiler is nice enough to let us pretend it has more than one dimension by hiding the math for us, but that's only an abstraction.

    @boomzilla said:

    @pkmnfrk said:
    Consider if Length was actually the size of dimension 0. Well, now there's two ways to get the size of dimension 0, which is a violation of DRY. Further, dimensions 1+ only have one way to retrieve them, which is weird. Also, what if you want to know the total number of elements? Well, the computer knows, but it isn't telling you, so you need to calculate it manually: GetUpperBound(0) * GetUpperBound(1) * GetUpperBound(2) * ...

    What are you talking about? GetUpperBound doesn't return the same thing as the length. I'm not a .Net guy, but GetLength(int) does what you'd think it does based on its name. This API is starting to sound like the PHP guys designed it.

    That's on me. I glanced at the documentation really quick this morning since I couldn't remember what the method was called, but yes, it should be GetLength, not GetUpperBound.

    @boomzilla said:

    @pkmnfrk said:
    Finally, the documentation explicitly spells it out for you, so there shouldn't be any reason for confusion in the first place:

    Look, we get what the method actually does. A well documented, retarded method is still retarded.

    If you're going to play that game, then at least get it right: A property is distinct from a method.

    @boomzilla said:

    @pkmnfrk said:
    @boomzilla said:
    @dhromed said:
    What is the length of 8-bit RGB colour space?

    I'm not sure "length" makes sense here. I suppose the implementation could be a total of 8-bits, so you could consider it an array of 8 bits, or a single byte. Or maybe it's an array of three color values. It would depend upon the implementation.

    The length of 8-bit colour space is the number of unique colours that can be represented in 8-bits. Doesn't matter if you use something like RRGGGBBB or if you go for an indexed palette scheme, the number of unique colours is still only 256. Thus, RGBColourSpace.Length == 256.

    This makes sense if you define the space as having one dimension. That was never specified. You've also assumed that the metric is number of colors. Which is fine, but it's an implementation detail, and no more valid than other representations.

    What the fuck else could possibly be meant by "8-bit colour space"? If it actually means 8 bits per channel, that's not 8-bit colour space, that's 24-bit colour space. If it actually means something else entirely, well, that's not my problem. One cannot just redefine terms arbitrarily to whatever one wants and expect others to understand what they're saying.



  • @pkmnfrk said:

    What the fuck else could possibly be meant by "8-bit colour space"? If it actually means 8 bits per channel, that's not 8-bit colour space, that's 24-bit colour space
     

    Lol, I think I intended to mean 8 bits per dimension, i.o.w. 256 elements per dimension. what would the "length" of this 3D array be?

    256 or 256^3?

    Sane arguments can go either way.



  • @dhromed said:

    @boomzilla said:

    If you were asked about the length of a rectangular prism, would you compute the area of a face, or just go right to the volume?
     

    A multidimensional array is a set of discrete points, not a volume.

    What is the length of 8-bit RGB colour space?

    A suffusion of yellow.



  • @pkmnfrk said:

    If you're going to play that game, then at least get it right: A property is distinct from a method.
    If you're going to play that game, and also if you're going to use the implementation of an array to support your argument, then a property is nothing but a setter and a getter method with some syntactic sugar.

    No one cares about how an array is actually implemented. For all we know, there could be guard blocks between elements to detect buffer overruns, or they could be stored discontinously. Implementations come and go, the Length property is part of the API and is here for a very long time.


  • ♿ (Parody)

    @pkmnfrk said:

    It's an array. It's well defined. There are no leaf arrays, it's a one dimensional contiguous block of memory. The compiler is nice enough to let us pretend it has more than one dimension by hiding the math for us, but that's only an abstraction.

    You're right, leaf arrays doesn't work well here, because it makes assumptions just like you're making up about the memory layout of the array. TFM says:
    @MSDN said:

    An array is a data structure that contains a number of variables called the elements of the array. The array elements are accessed through computed indexes. C# arrays are zero indexed; that is, the array indexes start at zero. All of the array elements must be of the same type, which is called the element type of the array. Array elements can be of any type, including an array type. An array can be a single-dimensional array, or a multidimensional array. Array types are reference types derived from the abstract base type System.Array.

    The compiler isn't pretending anything. It just presumably chooses to allocate the memory like that as an implementation detail. But I don't see anything in there that would require that particular layout. In fact, the implementation could be just to use jagged arrays and to initialize them automatically. Suppose you wanted a really big array. You might have to do something else just to avoid the memory limits on single objects. I wouldn't be surprised to see them do this at some point in the future.

    @pkmnfrk said:

    What the fuck else could possibly be meant by "8-bit colour space"? If it actually means 8 bits per channel, that's not 8-bit colour space, that's 24-bit colour space. If it actually means something else entirely, well, that's not my problem. One cannot just redefine terms arbitrarily to whatever one wants and expect others to understand what they're saying.

    Emphasis mine. So why are you trying to do just that? Not well defined means just that. "8-bit color space" implies 256 colors, which, again, is a set. A set does not normally have a length. A list of all the possible colors has a well defined length. The discrete elements used to represent a point in that space could be listed, and said to have a length. But applying the concept of "length" to a set doesn't make sense. Can you give an example where the cardinality of a set is referred to as "length?"

    Why are you arguing this point? Does a bad API naming decision in .Net really mean that much to you?



  • @mallard said:

    @MiffTheFox said:
    @Jaime said:
    From here
    @Douglas Crockford said:
    The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by encouraging excessive trickiness. They are second only to faulty architecture in enabling to viruses and other security menaces. Also, preincrement/postincrement confusion can produce off-by-one errors that are extremely difficult to diagnose.

    God forbid a user find a way to inject code into something that runs... on their own system...

    Unless he's one of those people who don't validate input coming from client-side JavaScript or user Node.js.

    Never heard of an XSS attack then?

    If you can inject JS onto a page and can get someone else to visit such an injected page, you've just injected code onto _their_ computer. Such code could steal cookies, perform website actions with their account, etc... Remember the days of MySpace worms?

    I'm still curious how you think preincrement and postincrement can lead to XSS.



  • @morbiuswilters said:

    I'm still curious how you think preincrement and postincrement can lead to XSS.
    A bug in a cookie parser, JSON sanitizer, or form field santizer. Not that anyone should be writing any of those.



  • @morbiuswilters said:

    @Jaime said:
    Douglas Crockford (and therefore JSLint) prefers i+=1 over i++, so it's not just a newbie thing.

    Any particular reason why?

    And technically it should be ++i, not i++..

    Your special crazy shines through again. Preincrement vs postincrement in a for loop doesn't make any damn difference.



  • @Zylon said:

    @morbiuswilters said:
    @Jaime said:
    Douglas Crockford (and therefore JSLint) prefers i+=1 over i++, so it's not just a newbie thing.

    Any particular reason why?

    And technically it should be ++i, not i++..

    Your special crazy shines through again. Preincrement vs postincrement in a for loop doesn't make any damn difference.

    Except, of course, for having completely different semantics. ++i says "increment the value of i by one" whereas i++ says "create a temporary variable, copy the value of i into the temporary variable, then increment i". Compilers can generally optimize away the temporary variable if it's not needed, but then you're relying on the compiler to know that it needs to modify the interpretation of your code because you couldn't be bothered to do it correctly in the first place. The question is: why are you using postincrement when preincrement does what you actually need?



  • @Zylon said:

    @morbiuswilters said:
    @Jaime said:
    Douglas Crockford (and therefore JSLint) prefers i+=1 over i++, so it's not just a newbie thing.
    Any particular reason why?

    And technically it should be ++i, not i++..
    Your special crazy shines through again. Preincrement vs postincrement in a for loop doesn't make any damn difference.

    You're a little late to the party.  We already addressed this, and morbs already said that he was talking from an ideological standpoint.


  • @Zylon said:

    @morbiuswilters said:
    @Jaime said:
    Douglas Crockford (and therefore JSLint) prefers i+=1 over i++, so it's not just a newbie thing.

    Any particular reason why?

    And technically it should be ++i, not i++..

    Your special crazy shines through again. Preincrement vs postincrement in a for loop doesn't make any damn difference.

    Call me special crazy, but that second answer from the top, Anders Sjöqvist's, paints a wholly different picture. Believing the first opinion you read after 1 second of googling: it's a lot of things, but smart isn't one of them.


  • ♿ (Parody)

    @morbiuswilters said:

    Except, of course, for having completely different semantics. ++i says "increment the value of i by one" whereas i++ says "create a temporary variable, copy the value of i into the temporary variable, then increment i". Compilers can generally optimize away the temporary variable if it's not needed, but then you're relying on the compiler to know that it needs to modify the interpretation of your code because you couldn't be bothered to do it correctly in the first place.

    I think it's probably simpler than that, actually. The semantics of post-increment say increment the variable but return the value as it was before incrementing. There's really no requirement for a temporary variable. It depends on how the value is being used. In a loop, it's generally discarded. It's no different than being its own statement anywhere else. I wonder if most compilers would create a temporary variable even with optimizations turned off.

    The real problem with pre-incrementing is that most people are used to reading post-incrementing operators, so using the "funny" syntax causes slower comprehension among the readers of your code. You should be appropriately ashamed.



  • @toon said:

    @Zylon said:
    @morbiuswilters said:
    @Jaime said:
    Douglas Crockford (and therefore JSLint) prefers i+=1 over i++, so it's not just a newbie thing.

    Any particular reason why?

    And technically it should be ++i, not i++..

    Your special crazy shines through again. Preincrement vs postincrement in a for loop doesn't make any damn difference.

    Call me special crazy, but that second answer from the top, Anders Sjöqvist's, paints a wholly different picture. Believing the first opinion you read after 1 second of googling: it's a lot of things, but smart isn't one of them.

    I think it's also a good argument against operator overloading. Still, he actually neglected to mention the ramifications of overloaded postincrement: the copy the compiler has to create is of the entire object, not just an int. So ++obj moves the internal iterator pointer forwards whereas obj++ allocates a (quite possibly large) chunk of memory, invokes the copy constructor, does whatever logic is in the copy constructor (which might involve deep copying member objects) and then discards it all because it wasn't actually needed. Then there are also the bugs and memory leaks to be considered if the copy constructor isn't carefully implemented: maybe the destructor calls delete on a shallow-copied pointer or dynamically allocates memory but doesn't delete it.. Of course, most of these unexpected side-effects are just due to the awfulness of C++.

    And of course, iterators are used all of the time in for loops so that's a very good reason to avoid postincrement in a for loop. A better reason is: why are you telling the computer to do one thing and then relying on the compiler to fix your mistake?



  • @toon said:

    @Zylon said:
    @morbiuswilters said:
    @Jaime said:
    Douglas Crockford (and therefore JSLint) prefers i+=1 over i++, so it's not just a newbie thing.
    Any particular reason why?

    And technically it should be ++i, not i++..
    Your special crazy shines through again. Preincrement vs postincrement in a for loop doesn't make any damn difference.

    Call me special crazy, but that second answer from the top, Anders Sjöqvist's, paints a wholly different picture. Believing the first opinion you read after 1 second of googling: it's a lot of things, but smart isn't one of them.

    Ok, special crazy.  Anders' answer is like the 4th one.  Also, the example is pretty clear that it's an int.

    I think I agree with morbs that this is a reason against overloading operators.


Log in to reply