6 ms·
Or rather I wish the standard did not bend over backwards to allow every kind of aggressive optimisation that some compiler writer claims will increase speed of
by adrianratnapala 10y ago
Or rather I wish the standard did not bend over backwards to allow every kind of aggressive optimisation that some compiler writer claims will increase speed of unoptimized code by 0.5%.
- thomasahle 10y agoIsn't that the point of C/C++? "Code should run as fast as the hardware allows" and "We allow you to do crazy things that probably won't be portable, if that's what you want". I wonder, if somebody created a language with C like semantics, like pointer arithmetic, but with a layer in between to ensure consistency and portability.. Would people want to use that, or would the semantics be considered less interesting, when they don't map directly to hardware?
- lmm 10y agoCorresponding directly to the hardware makes sense, sure. But what modern GCC (especially) does goes far beyond that. The intent of signed integer overflow being undefined is that it will be twos complement on a twos complement machine, not that I want half my code to not run if I had an overflow somewhere.
- Sacho 10y agoIf that was the intent, then overflow should have been classified as enumerated implementation-defined behavior, just like the bit representation of an integer type which already deals with those variations.
- caf 10y agoIf that had been the intent, it would have been specified as implementation-defined, not undefined. More likely, the intent was to also accomodate implementations that trapped on overflow.
- jjnoakes 10y agoImplementation-defined includes trapping on overflow.
- lmm 10y ago"Evaluates to an implementation-defined value" would not include that. I'm not sure if any of the usual definitions in the standard includes trapping and doesn't include arbitrary behaviour.
- jjnoakes 10y agoSure, but the standard need not say "Evaluates to an implementation-defined value". There are other wordings which use "implementation-defined" and would support trapping on overflow.
- lmm 10y agoCan you give an example? I struggle to think of anywhere the standard uses a wording that would fit here.
- jjnoakes 10y agoWhy would it have to be wording already in the standard? Does each phrasing in the standard have to appear more than once?
- lmm 10y agoAdding a new phrase with a new meaning would add a substantial amount of complexity to what's already a very complex standard.
- jjnoakes 10y agoI disagree. There's nothing difficult to understand about new phrases with new meanings in general. Do you have a specific phrase which you can show to be sufficiently difficult to understand by a group of people, and which you don't think could be rewritten to retain the same meaning but be easier to understand? If you do, let me know, and I will try to simplify it for you and help you understand it. If you don't, then there isn't much to say. Your current argument ("phrases could be written in a difficult to understand way") is too general to be useful.
- tehrei 10y agoYeah but with those aggressive optimizations my code doesn't run at all.
- qb45 10y agoThis one is about portability, not optimizations. There are architectures where pointer isn't a simple int, due to things like segmentation, tagging or even possibly something as stupid as lack of sufficiently wide integer type. Heck, there were even C implementations for 36-bit machines, which had 36-bit registers and could only load/store 36-bit-sized and 36-bit-aligned chunks of memory. They packed 4 chars into such word (leaving 4 bits unused) and I don't know how they implemented char* but it must have been something totally mad and not reasonably castable to int or even int*.
- userbinator 10y agobut it must have been something totally mad and not reasonably castable to int or even int.* As long as you can impose an ordering on the elements in memory and thus derive a number for each one, it's possible to define the straightforward representation of a pointer. 4 chars per word is an easy case since you can just let char* be a number with the lowest 2 bits indicating the index within a single word, and the rest of the bits are the word-address. int* can be the same number with the lowest 2 bits always 0. If word addresses are smaller than 36 bits, then values with the higher bits set are invalid, and if they're larger, then use multiple words to hold them. Working with chars on such a machine is going to involve a lot of shifting and otherwise data movement, but there you go, a way to implement C pointers on such a machine.
- qb45 10y ago> int* can be the same number with the lowest 2 bits always 0. And now you have to right-shift int pointers on every dereference for some dubious benefit. It's easier and more efficient to make pointer arithmetic and casting painful.
- adrianratnapala 10y agoNo, you left-shift them on every cast. And is someone type-puns using a union, they get a thing four times samller than they might have expected. Stil it is totally well behaved in a hash.