4 ms·
I felt the same way about "C++" postincrement, returns C. This seems more like it should be a predecrement (--C) because it does not return C, rather assembly.
by blueblob 13y ago
I felt the same way about "C++" postincrement, returns C. This seems more like it should be a predecrement (--C) because it does not return C, rather assembly.
EDIT: changed, I said decrement and meant increment.
- _delirium 13y agoPredecrement is fairly unidiomatic in C, much less commonly used than in C++. Typically it's only really used if you're doing something tricky that actually depends on the semantics of predecrementing, usually in an array reference of the x[--i] variety. It's idiomatic in C++ I'd guess because of operator overloading: postdecrement/postincrement may produce large unused object copies that not all compilers will optimize away, so using the pre- versions by default has become idiomatic in that community.
- robert_tweed 13y agoIt's actually pretty idiomatic in optimised C, for the same sort of reason (when all extra instructions count), e.g., this sort of loop: for( i=LEN-1; i>=0; --i ) {...} I've carried this into a lot of other languages, as it's equally readable to the alternatives, when ordering isn't important. In (mainly older) optimised code where ordering is important, you'll often still see this, with a second incrementing variable so that the exit condition retains the compare to zero (avoiding a variable comparison); although that part is separate from the use of the pre-decrement. I'm not sure if either of these make much difference with modern CPUs and compilers. Certainly not worth worrying about for the most part. It's untrue that this idiom started with C++. This style is preferred by K&R, which predates optimising compilers. Since then it's use among C programmers has probably been force of habit, but it is definitely idiomatic. It's use in K&R makes it about as idiomatic as it is possible to be.
- _delirium 13y agoThat isn't the style used in K&R, though. When K&R introduces a for loop for the first time, in section 3.5, it does it like so, and sticks to this style throughout: for (i = 0; i < n; i++) ... This is the kind of code I run across most commonly (almost exclusively) in pre-1990s C. It's also the style used in the old Unix sources. For example, take a look at the source code to 'nohup' or 'mount' from 5th Edition Unix, 1974: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s2/nohup.c http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s... http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s2/mount.c http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s... They do also use predecrement/preincrement, but only in assignments or comparisons, where it actually semantically matters that the increment/decrement is "pre": while(*--np == '/') *np = '\0'; In contexts where it doesn't matter, like the 3rd clause of a for loop, or just incrementing a variable as a standalone operation, they always default to x++.
- gsg 13y agoI just flicked through my copy of K&R (second edition), and at the beginning it clearly prefers preincrement. The introduction of for loops comes before that of ++, and the first for loop in the book is actually for (fahr = 0; fahr <= 300; fahr = fahr + 20) ... Each for loop after the introduction of ++ uses preincrement (where applicable) for a while, and then the style shifts to postincrement. EDIT: specifically, increments are deliberately prefix ("For the moment we will stick with the prefix form") until the full introduction of increment and decrement operators in section 2.8, after which they are postfix.
- zanny 13y agoWell, the really early C++ compilers would output C code and daisy chain on a C compiler. That trend didn't last very long, though.
- cwzwarich 13y agoThe EDG C/C++ frontend (used by a lot of commercial C++ compilers) still supports this, and Comeau's compiler still relies on this for code generation. EDG also implements a different template instantiation model than other C++ compilers, partially so that it can function with a C++-agnostic linker.