[LLVMdev] Using C++'11 language features in LLVM itself

Karen Shaeffer shaeffer at neuralscape.com
Tue Jan 8 19:21:05 PST 2013

On Tue, Jan 08, 2013 at 06:30:42PM -0800, Chris Lattner wrote:
> On Jan 8, 2013, at 4:24 PM, dag at cray.com wrote:
> > I am personally very much in favor of this.  C++11 really is a huge leap
> > from C++03 in terms of readability, maintainability and safety.
> I agree completely.

> > 
> > As for gcc version, it looks like 4.7.2 is in Debian Wheezy and that's
> > usually the most common distribution to lag behind in these kinds of
> > things.  I think that's sufficiently new for Linux but someone correct
> > me if that's wrong.
> Wow, requiring GCC 4.7 would be really aggressive, it was just released in March 2012.  Call me conservative, but I was thinking that a reasonable GCC baseline would be GCC 4.4 or something (which is ~3.5 years old).

I was running Ubuntu 12.4, but I bumped up to 12.10. This was because 12.10 runs
gcc-4.7.2. I have a reasonable code base that compiled fine in upgrading from
 4.6(-std=c++0x) to 4.7.2(-std=c++11).

IMO, with linux based systems, it is always safest to stay just a little off the
bleeding edge. Bugs tend to get fixed very quickly, once identified. And then you
have the advantage of the latest features. All things considered, I suspect all the
energy is in 4.7.2 and forward in the context of C++ on linux for new implementations.

I am also aware of the way too common problem of folks stuck in a time warp, because
they have dependencies on old libraries that they cannot upgrade. IMO, a development
effort should not slow the pace of feature adoption to support folks who have not
planned for future upgrades in an intelligent manner. Rather than make everyone pay
the price for such groups, there ought to be a way for them to use an older release
of llvm until they figure out how to upgrade.

I recommend targeting 4.7.2 or later, because all new C++ code on linux is surely
going down that path. You can inconvenience the laggards, or you can turn away the
folks leading the way with new implementations. But you can't satisfy both.

Karen Shaeffer
Neuralscape, Mountain View, CA 94040

More information about the llvm-dev mailing list