First of all compilers disagree on many interpretations and consequences of abstract machine rules. Also compilers have bugs.
So a proficient C/C++ programmer does have to learn what compilers actually do in practice and what they guarantee beyond the standard (or how they differ from it).
> C/C++ isn't a language.
It isn't, but it is a family of languages that share a lot of syntax and semantics.
List them. I am not aware of any well defined parts of the C standard where GCC and Clang disagree in implementation. Only in areas where things are too vague (and are effectively either unspecified or undefined), or understandably in areas where they're "implementation defined".
If there are behaviours where a compiler deviates from the standard it is either something you can configure (e.g. -ftrapv or -fwrapv) or it's a bug.
> Also compilers have bugs.
Nothing you do can defend against compiler bugs outside of extensively testing your results. If you determine that a compiler has a bug then the correct course of action is definitely not: "note it down and incorporate the understanding into your future programs"
> So a proficient C/C++ programmer does have to learn what compilers actually do in practice and what they guarantee beyond the standard (or how they differ from it).
There are situations where it's important to know what the compiler is doing. But these situations are limited to performance optimisation, the knowledge gained through these situations should only be applied to the single version of the compiler you observed it in, and you should not use the knowledge to feed back to your understanding of C or the implementation.
It's almost impossible to decipher how modern C compilers work exactly and trying to determine what an implementation does based on the results of compilation is therefore extremely unreliable. If you need to rely on implementation defined behaviour (unavoidable in any real program) then you should be relying solely on documentation, and if the observed behaviour deviates from the documentation then that is, again, a bug bug.
> It isn't, but it is a family of languages that share a lot of syntax and semantics.
I am not a C/C++/C#/ObjectiveC/JavaScript/Java programmer.
C++ and C might share a lot of syntax but that's basically where the similarities end in any modern implementation. People who know C thinking they know enough C to write reliable and conformant C++ and people who know C++ thinking they know enough C++ to write reliable and conformant C are one of the groups of people who produce the most subtle mistakes in these languages.
I think you could get away with these kinds of things in the 80s but that has definitely not been the case for quite a while.
Perhaps it's not "well defined" enough for you, but one example I've been stamping out recently is whether compilers will combine subexpressions across expression boundaries. For example, if you have z = x + y; a = b * z; will the compiler optimize across the semicolon to produce an fma? GCC does it aggressively, while Clang broadly will not (though it can happen in the LLVM backend).
I'm aware of some efforts to bring deterministic floating point operations into the C++ standard, but AFAIK there are no publicly available papers yet.
If the end result of the calculation differ (and remember that implementations may not always use ieee floats) then you can call it a bug in whatever compiler has that difference.
well, the part of the standard that are vague and/or underspecified is a very large "Here be dragons" territory.
Time-traveling UB, pointer provenance, aliasing of aggregated types, partially overlapping lifetimes. When writing low level codes, it makes sense to know how exactly the compilers implement these rules.
In particular, regarding aliasing, GCC has a very specific conservative definition (stores can always change the underlying type, reads must read the last written type) that doesn't necessarily match what other compilers do.
>> It isn't, but it is a family of languages that share a lot of syntax and semantics. > I am not a C/C++/C#/ObjectiveC/JavaScript/Java programmer.
C#, Java, JS share a bit of syntax, but certainly not semantics. ObjectiveC/C++ definitely belong. There is a trivial mapping from most C++ constructs to the corresponding C ones.
Sure, but the answer as I said earlier is: don't touch those parts of C.
The subset which _is_ well defined is still perfectly powerful enough to write highly performant software.
It's not like I'm advocating for you to use the brainfuck subset of C.
> When writing low level codes, it makes sense to know how exactly the compilers implement these rules.
Almost nobody is writing C low level enough for this and I've written embedded code which didn't need to worry about strict aliasing.
This is again just a misconception, almost no real programs need to delve this deeply into the details.
> In particular, regarding aliasing, GCC has a very specific conservative definition (stores can always change the underlying type, reads must read the last written type) that doesn't necessarily match what other compilers do.
It doesn't matter what other compilers do as long as in terms of the abstract machine these differences do not break the rules set out in the standard. Again, you do not need to know these details for 99.99% of program code.
> C#, Java, JS share a bit of syntax, but certainly not semantics. ObjectiveC/C++ definitely belong. There is a trivial mapping from most C++ constructs to the corresponding C ones.
There's a mapping from any of these languages to any other one, in some cases also quite trivial, the amount of overlap is immense, but C and C++ have heavily deviated.
I am a C expert, I do not claim to be a C++ expert, every time I look at C++ I am increasingly surprised at just how it redefines something core about C. Something I just learned in this very thread is https://en.cppreference.com/w/cpp/memory/start_lifetime_as which doesn't exist in C because apparently C and C++ define object lifetimes completely differently.
It's dangerous to keep pushing this notion that C and C++ are very similar because it leads to constantly leads to expert C++ programmers confidently writing subtly broken C code and vice versa.
