tag:blogger.com,1999:blog-6800934446457898793.post656325068512394681..comments2010-07-04T08:51:33.462-04:00Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-6800934446457898793.post-46759457699462773652008-05-30T20:49:00.000-04:002008-05-30T20:49:00.000-04:00<B>Kevin</B>: Interesting observation ; I hadn't considered that path. I think a lot of it was influenced by examples, but it could cause a subconscious preference.Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-10207981853892548052008-05-30T12:08:00.000-04:002008-05-30T12:08:00.000-04:00A thought: programmers are probably drawn to postfix notation because by definition, the name C++ is itself postfix?Kevinnoreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-27790551172053215812008-02-07T20:30:00.000-05:002008-02-07T20:30:00.000-05:00Mike: thanks for the follow-up response. Your points are well taken. <BR/><BR/>I think that every language has to make decisions on several areas like syntax, expressiveness, raw power, and what it will protect you from. <BR/><BR/>I think it's clear that Bjarne choose to write as think of a layer on top of C that would give the majority of OO ideas. To him, I think performance was paramount like you mentioned.<BR/><BR/>I also think that people write in C++ now since it's the language of their legacy codebase that companies have spent an enormous amount of time creating. (If MS Office was greenfield now, it'd probably be written in C#). The other reason is for cross-platform programs that need good performance. (This will likely become more negligible as the CLR and JVM continue to expand)<BR/><BR/>However, when they do write in C++, it would be silly to ignore libraries like Boost and ACE that implement a lot of low level stuff for you. By the time you resolve to use smart pointers and structured exception handling, no one is worried excessively on the copy constructor that's wasted.<BR/><BR/>Still, you made good points. Some places are going to demand perf above all else. That's why I have to acknowledge that it might be worth the battle to fight for unilateral ++i syntax as a coding standard if you're in a pure C++ shop.<BR/><BR/>However, for the vast majority of cases, readability and maintainability is a trump card. As we move into the dynamic language and functional paradigms more, people will drift away from for loops altogether and start to think more and more in terms of things like Count() and higher order functions like map and reduce.Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-65275364104919679572008-02-07T17:20:00.000-05:002008-02-07T17:20:00.000-05:00Jeff,<BR/>Sorry for the nitpick. Your illustration of C++ pre vs post increment was perfect but I didn't think it was clear that STL iterators are implemented by overloading the increment operators. But you clearly pointed out the STL iterators are coded in a way that conforms to the semantics of those operators. Any class that overloads the post-increment operator in C++ must return a copy-constructed version of itself which could be a performance hit if the class held enough data. <BR/>Of course the performance hit is negligible. If you are required to program in C++ it is typically because you are coding a performance sensitive capability and ignoring even modest opportunities to improve performance just seems wrong. <BR/>Otherwise, this entry is probably the best I have seen from somebody I personally know.Mike Petryhttp://www.blogger.com/profile/00900707625184132791noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-72194547351818239432008-02-04T22:57:00.000-05:002008-02-04T22:57:00.000-05:00Mike: Glad you liked it!<BR/><BR/>Bart: foreach does create an enumerator object, but it's very fast since it's going to use generation 0 memory (quick birth, quick death)<BR/><BR/>The for(..;..;..) method really requires, like you say, that the underlying data structure has array like semantics rather than linked-list semantics.Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-77224100641855526052008-02-04T14:39:00.000-05:002008-02-04T14:39:00.000-05:00Nice article. <BR/><BR/>However, I would add that foreach is also avoided when doing programming games in managed C#. It leaves behind objects that need to be GC'ed :)<BR/><BR/>Having said that the for loop is not faster all the time! Check out this link (guy who created MDX) where in SSAS 2005 the dvelopers screwed up in the implementation of iterators/enumerators...foreach is exponentially faster:<BR/>http://sqljunkies.com/WebLog/mosha/archive/2007/04/19/stored_procs_best_practices.aspx<BR/><BR/>It alawys goes back to that rule: "It Depends" :)Bart Czernickinoreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-64845281358270524622008-02-04T12:38:00.000-05:002008-02-04T12:38:00.000-05:00Nice article Jeff. Appreciate the insights.Mikehttp://www.blogger.com/profile/10903880768750599460noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-12417004609199498072008-02-03T07:20:00.000-05:002008-02-03T07:20:00.000-05:00Anonymous: do <I>what</I> in C? What exactly are you dumbfounded by?Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-89220901378575635912008-02-03T07:19:00.000-05:002008-02-03T07:19:00.000-05:00Paolo: thanks for the insight! I had a hunch that it might have had to deal with that I,J, and K are used for vectors in physics. However, I didn't find any reference to this in my limited research.Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-35077870445394432522008-02-03T07:17:00.000-05:002008-02-03T07:17:00.000-05:00Robert: Interesting views on aesthetics. I would have thought that i++ would look better since everything else starts with a letter (i =; i <; i..) and you'd have more balance, but I can also see your point.Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-88818229301878339722008-02-03T06:31:00.000-05:002008-02-03T06:31:00.000-05:00This is so funny...<BR/><BR/>I guess you can't do that in C either?<BR/><BR/>I'm just dumbfounded by this whole blog.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-80428394180356386012008-02-03T04:21:00.000-05:002008-02-03T04:21:00.000-05:00The reason why IJKLMN were used for integer variables in Fortran, by the way, is that those were used often as indexes or sizes (both of which are integers) in math.Paolo Bonzinihttp://www.blogger.com/profile/13626037576749368651noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-70043415295736347362008-02-03T02:36:00.000-05:002008-02-03T02:36:00.000-05:00I've stuck to pre-increment simply on aesthetic grounds: I dislike seeing the ++ immediately next to a close parenthesis.<BR/><BR/>However, I would point out that in general making such decisions based on a hazy idea of what might be faster is farcical (and unfortunately common). Optimization is not optimization without cold hard data: measure the speed.<BR/><BR/>For typical tight inner loops, anyhow, the code for incrementing is probably nowhere near as important as memory access concerns---e.g. setting up cache prefetches. Which of course, and very frustatingly, we don't yet have much control over in languages above assembly: I find it amazing that something so critical to performance is still left up to hoping for compiler magic or weird non-portable hacks.roberthttp://www.blogger.com/profile/02285636896312756581noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-77871657984709759282008-02-02T22:23:00.000-05:002008-02-02T22:23:00.000-05:00Mike:<BR/><BR/>C# <A HREF="http://msdn2.microsoft.com/en-us/library/8edha89s.aspx" REL="nofollow">supports operator overloading for some operators</A>, but not for ++. <BR/><BR/>In addition, I think that C# was influenced by having to design features that would play nice with features available in a vast amount of other languages that ride on the CLR. This is what probably led to the push towards an interface/Enumerator based approach.<BR/><BR/><A HREF="http://msdn2.microsoft.com/en-us/library/system.collections.ienumerable.aspx" REL="nofollow">IEnumerable</A> is a very powerful interface and indeed is what <A HREF="http://msdn2.microsoft.com/en-us/library/bb397919.aspx" REL="nofollow">LINQ to Objects</A> is built on. <BR/><BR/>Having the clear semantics that IEnumerable has made LINQ possible.<BR/><BR/>Maybe I misunderstood your comment?Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-38024660751577176942008-02-02T22:13:00.000-05:002008-02-02T22:13:00.000-05:00Cool post, I ran across it on the front page of programming.reddit. <BR/><BR/>One needs to look a bit deeper at the C++ pre/postfix unary operator. The main point is that C++ supports operator overloading. There are semantical differences between the two operators (as you described very lucidly). Languages such a C# and Java do not support operator overloading.Mike Petryhttp://www.blogger.com/profile/00900707625184132791noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-3414693520499484952008-02-02T20:17:00.000-05:002008-02-02T20:17:00.000-05:00Eelis: interesting thoughts. It's sort of a shame from a language perspective that new programmers need to be concerned about such details. <BR/><BR/>However, I agree that it would help better inform the programmer if it caused him/her to investigate the issue more.<BR/><BR/>I also agree that it probably wasn't given much thought at the start and that has just grown (in non-thought that is) as the years have gone by. <BR/><BR/>For C++ code, I'm still undecided if I would make the push for preincrement notation since it would make the overall codebase more uniform because the preferred syntax for iterators would be preincrement. <BR/><BR/>For C#, what I work in the most at the moment, it doesn't matter nearly as much and that's why I'm leaning to favoring the community trend of postincrement.<BR/><BR/>Regardless, it's an interesting to find what's most elegant from a technical, community, and common sense perspective on the issue.Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-18716293407222449502008-02-02T20:06:00.000-05:002008-02-02T20:06:00.000-05:00Jeff:<BR/><BR/>I agree that working with inexperienced programmers in a crappy codebase can often be a very strong argument for choosing solutions that would be frowned upon by more experienced programmers working in a clean codebase. However, I don't consider this one of those cases.<BR/><BR/>If a programmer sees prefix increment where he would have expected postfix increment because he doesn't know any better, what's the worst that can happen? Either he will ignore it, or he will decide to investigate, learn the difference, and end up a more informed programmer who has now seen another demonstration of the KISS principle.<BR/><BR/>As for "popularity", I highly doubt it was ever a very conscious thing, let alone active enthusiasm. Most likely neither the first needless-postfix users nor their countless imitators gave it any thought at all.Eelisnoreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-43722910247358552402008-02-02T19:44:00.000-05:002008-02-02T19:44:00.000-05:00Eelis: Thanks for sharing the comment.<BR/><BR/>I absolutely agree that pre-increment semantics are better. I want to use pre-increments from a technical perspective. <BR/><BR/>It's just that in C# at least, it makes no difference in the case I mentioned. Since pre-increment goes against the norm, it would just serve to make the code-base on a large project less uniform. <BR/><BR/>So, althought it is better from an imperative purity perspective, I am bound from a practical aspect to go with post-increment since consistency and readability are higher priorities.<BR/><BR/>Any thoughts on why post-increment became so popular even before objects?Jeff Moserhttp://www.blogger.com/profile/16074905903060665396noreply@blogger.comtag:blogger.com,1999:blog-6800934446457898793.post-14403124828078636552008-02-02T19:39:00.000-05:002008-02-02T19:39:00.000-05:00(In what follows I'll only talk about C++, because I know nothing about C# and Java and whatnot.)<BR/><BR/>The efficiency argument against i++ vs ++i is indeed very weak. However, there is a stronger argument.<BR/><BR/>Postfix increment (which makes a copy of the argument, increments the argument, and then returns the copy) has more complex semantics than prefix increment (which just increments the argument and returns it). This is not an implementation issue; we're talking about the semantics specified by the language definition. With this observation, the well known KISS principle is directly applicable: postfix increment's more complex semantics don't win one anything, so prefer the simpler prefix increment solution.<BR/><BR/>Note that the argument applies not only when i happens to be a C++ iterator, but also when it is an int.Eelisnoreply@blogger.com