It was put in C89 for compatibility with legacy code. It's not in C99, as Mario said. If you don't want it in C89, then disallow it with a compiler switch, or use a static code checker, or both.
It was put in C89 for compatibility with legacy code. It's not in C99, as Mario said. If you don't want it in C89, then disallow it with a compiler switch, or use a static code checker, or both.
Yeah, I get it was there for a purpose, but that doesn't mean I agree with it.
BUT it is good to know that it isn't there in C99. C99 actually seems to fix a number of small issues, mainly implicit function types and the whole ordeal with calling functions without prototypes.
Are you adverse to using a compiler switch to fix that problem in C89?
I just don't see why you always rag on C, Elysia. I mean I do realize that I do write a lot of C++ code and all, and perhaps I am just fond of C because it was what some of my proudest projects were written in. But either way I don't see what difference it makes. At least I don't like C#. Everytime someone says they like C# a sun microsystems angel loses its wings.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I don't see how it's undefined.
Last edited by Mario F.; 10-06-2008 at 03:37 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Ah yes I was confused. I thought the post-increment operator would only take effect after the sequence point was encountered, but I was confusing things.
Last edited by robwhit; 10-06-2008 at 03:38 PM.
It took me a while to see the undefined behavior also.
Code:bar[i] = foo[i++];
Could you perhaps explain it to me then? Because neither example attempts to modify i more than once. That would be the only place undefined behavior could occur.
bar[i] = foo[i++];
i++ evaluates to i for both sides, bar[i] is assigned, and after the sequence point is encountered, the increment occurs. Am I wrong? i = v[i++]; seems to be the closest thing that would support Mario's claim but that isn't happening here.
And see http://www.difranco.net/cop2220/op-prec.htm, or perhaps any other table for information on delayed increments. There's likely chapter and verse somewhere...
I thought that too, but I think the relevant part is here:Furthermore, the prior value shall be accessed only to determine the value to be stored.
Ah, well, err to the side of caution I suppose.
My apologies.
I tried to display that undefined behavior behind an implementation only to further the idea C++ (whether through its C roots or not is irrelevant) also has its share of undefined behavior and no compiler warnings, as seems to be Elysia's major gripe with C and her crusade to rid the world of C textbooks.
Perhaps I overdid it. So apologies again.
But I feel It could go much further. It is often said of C++ that with C you are given a gun with which you can accidentally shoot your own foot, but with C++ you can blow your whole leg off (or some variation of this). If we were to crusade against languages for their inherent general-purpose idiosyncrasies, there would not be any programming languages in the world and not even interpreted languages would have a chance at being developed.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.