Or the D standard, or the Java standard, or the Fortran standard, or the Golang standard...
It is the GNU compiler collection, after all. I'm actually particularly excited about a new release of gdc myself. I've been reading Alexandrescu's excellent The D Programming Language, and I think it may be just the better C++ that I always wanted, ahead of Golang and Rust.
GCC has an Ada implementation too - you might (or might not) consider that.
At least with the C standard, it's theoretically possible to learn it. I'd challenge you to find one person in your company who fully understands the C++ standard.
Stroustroup in his book claims he doesn't fully understand it.
Well, this is the language where Turing-complete template metaprogramming was "discovered" as an emergent property of the system!
Re:GCC 6.1 Released
by CyberDildonics on Wednesday April 27, 2016 @02:10PM
(#11582973)
Giant, complicated, wildly successful.
Well, just use -fsanitize=undefined and it will point out (most of) the isuses for you.
Provided that your test suite properly trigger the execution of tricky parts, in tricky situations (You do have a test suite, right?)
Re:GCC 6.1 Released
by Kristine1975 on Wednesday April 27, 2016 @09:34AM
(#11580257)
>You do have a test suite, right?
Of course I do. I call it "customers".
Ok great then, and don't forget to tell them to compile using "-fsanitize=undefined" !
We do love our customers don't we? They make the best testers.
Well, not all C compilers have it.
And I challenge you to find someone that knows all C rules about UB across all major compilers.
Undefined behaviour is the same across all compilers. The compilers aren't the things which make the behaviour undefined, its the C standard.
No it is not, if you ever tried to write portable C code you should clearly be aware that each C compiler has its own flavor of undefined behavior.
The C standard is very generous in terms of undefined behavior freedom.
By definition made in the C Standard, undefined behavior is: behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements
If you're using some other definition, then say so, otherwise your comments make no sense.
Given my-app.c, each C compiler out there will pick a different UB subset and not everything that is defined as UB in the standard.
They are free to do that and still be compliant, after all UB means anything goes.
That compilers may behave differently is exactly the point of UB, if they all had to behave the same it wouldn't be undefined, after all!
True dat. C is a smaller language and is possible to know the whole language, but not the whole spectrum of UB. C++ is a vastly larger language it is nearly impossible to know the whole language, but much more likely to understand the spectrum of UB.
Not counting true compiler bugs of course.
Edit: The release notes at https://gcc.gnu.org/gcc-6/changes.html mention three programs that apparently will break:
Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop)