Archive

Posts Tagged ‘GNU Compiler Collection’

It’s Definitely A Compiler Bug

August 26, 2013 Leave a comment

Previously, I wrote a post about a potential compiler bug with the g++ compiler in the GCC 4.7.2 collection that was driving me nutz:  “Uniform Initialization Failure?“. In that post, I flip-flopped between concluding whether the issue I stumbled upon was a bug or just another one of those C++ quirks that cause newbie programmers to flee in droves toward the easier-to-learn programming languages. D’oh!

Since I wrote that post, I’ve purchased and have been studying the fourth edition of Bjarne’s TCPPL. It’s now a slam dunk. The g++ GCC 4.7.2 compiler does indeed have a bug in its implementation of C++11’s uniform initialization feature.

First, consider this Stroustrup code snippet:

TCPPL ref brace init

Note how Bjarne “uniformly” uses braces to initialize all of class X‘s member variables – including the Club reference member variable, rc.

Next, look at the code I wrote that makes g++ 4.7.2 barf:

gcc barf

Note how the compiler spewed blasphemy when I tried to uniformly use braces to initialize the GccBug class’s foo and bar member variables.

Now, look at what I had to do to make the almighty compiler happy:

Happy GCC

As you can see, I had to destroy the elegancy of uniform initialization by employing a mix of braces and old-style parenthesis to initialize the foo and bar member variables.

It’s my understanding that GCC 4.8.2 has been released and it has been deemed C++11 feature-complete. I currently don’t have it installed, but, if one of you dear readers are using it, can you please experiment with it and determine if the bug has been squashed? I have a highly coveted BD00 T-shirt waiting in the warehouse for the first person who reports back with the result.

Range Checked Vector Access

March 13, 2012 Leave a comment

By now, C programmers who’ve made the scary but necessary leap up to C++ should’ve gotten over their unfounded performance angst of using std::vector over raw arrays. If not, then “they” (I hate people like myself who use the term “they“) should consider one more reason for choosing std::vector over an “error prone” array when the need for a container of compact objects arises.

The reason is “range checked access during runtime“; and I don’t mean using  std::vector::at() all over your code. Stick with the more natural std::vector::operator[]() member function at each point of use, but use -D_GLIBCXX in the compiler command line of your “Debug” build configuration. (Of course, I’m talking about the GCC g++ compiler here, but I assume other compilers have a similar #define symbol that achieves the same effect.)

The figure below shows:

  1. A piece of code writing into the 11th element of a std::vector that is only 5 elements long (D’oh!).
  2. A portion of the compiler command line used to build the Release (left) and Debug (right) configurations.
  3. The console output after running the code.

In contrast, here’s what you get with a bad ole array:

The unsettling aspect about the three “D’oh” result cases (unlike the sole “no D’oh” case) is that the program didn’t crash spectacularly at the point of error. It kept humming along silently; camouflaging the location of the bug and insidiously propagating the error effect further downstream in the thread of execution. Bummer, I hate when that happens.

%d bloggers like this: