It's seems like a quiet and peaceful day, lets stir things up a bit 
How crazy would it be for us to start using basic C++'11 language features (but not C++'11 library features) in LLVM: things like auto, rvalue-refs, lambdas, etc? I think that we can keep things well defined with a few simple requirements: language features must be supported by MSVC 2010 and later, some version of GCC and later (linux folks should pick?), some version of Clang and later (Freebsd folks?).
On the one hand, this would greatly clean up code and is definitely the path forward. On the other hand, I don't want to substantially harm adoption or use of LLVM by adding another burden to building and developing it.
If doing this would be a big problem for you, please speak up, and explain how/when the problem can be resolved. We will certainly adopt C++'11 features someday, so even if it isn't soon, it is good to have the discussion to find out what the issues are.
-Chris
How about being able to use RTTI and exceptions? (stir, stir...)
Reed
Please don't discuss RTTI/exceptions in this thread. All the
compilers which can compile LLVM already support both RTTI and
exceptions to a usable level; we don't use them for other reasons.
-Eli
Reed Kotler <rkotler@mips.com> writes:
How about being able to use RTTI and exceptions? (stir, stir...)
+1. RAII is super important.
-David
4.6 is the official compiler on Ubuntu 12.04 (released 04/2012), which
is the latest Long Term Support release (which come out every 2 years,
with 3 years desktop support and 5 years server support), so I
wouldn't push farther than that on Linux for the time being.
Another thing to bring up is that we have a lot of classes which have
method pairs `foo_begin()` and `foo_end()` (e.g.
`Function::arg_{begin,end}()`). These don't play nice with range-for
loops (we are already seeing this come up in LLD). We probably should
adopt some lightweight "range" class and a naming convention
(`foo_all()`?) that will interact well with range-for. jyasskin, you
have some standards proposals for such a class, maybe you could try
bringing that into tree?
-- Sean Silva
Chris Lattner <clattner@apple.com> writes:
It's seems like a quiet and peaceful day, lets stir things up a bit
How crazy would it be for us to start using basic C++'11 language
features (but not C++'11 library features) in LLVM: things like auto,
rvalue-refs, lambdas, etc? I think that we can keep things well
defined with a few simple requirements: language features must be
supported by MSVC 2010 and later, some version of GCC and later (linux
folks should pick?), some version of Clang and later (Freebsd folks?).
Note that this is NOT an official message from Cray in any way, shape or
form. I've passed on your note to our group for information but I don't
expect a serious problem with this given enough lead time.
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.
Why not C++11 libraries? Implementation/capatability reasons? I don't
know anything about how the various implementation compare in terms of
completeness. But the libraries use the new language features and
theoretically you get a performance boost "for free."
I'm assuming we wouldn't release an llvm with C++11 until 3.4 at least
which gives folks a good 8 months to a year to prepare. Doing it in a
3.3 release shortens that considerably but it might be ok. The biggest
issue for groups like ours is upgrading the compiler we use to build our
compiler. We have a LOT of components and they all have to work with
the new build environment. It involves a lot of testing and assurance
which is where we might bump up against a 3.3 release, not having a new
compiler in place before 3.3 is out.
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.
-David
The C++ proposal changes rapidly. While it would be great to get usage
experience from LLVM in order to inform the C++ proposal, I don't have
"what will eventually be in C++" to propose for LLVM. Well, I'd expect
some "range<IteratorType>" template with .begin() and .end() methods,
but I don't even know what name that template will have.
I'm not sure this part of the discussion is on-topic for Chris's
thread, since it's not related to a potential problem with enabling
C++ language features. (Not having a range type doesn't make
range-based for loops fail to compile on some platform, it just makes
them slightly less useful.)
Jeffrey
Sean Silva <silvas@purdue.edu> writes:
some version of GCC and later (linux folks should pick?)
4.6 is the official compiler on Ubuntu 12.04 (released 04/2012), which
is the latest Long Term Support release (which come out every 2 years,
with 3 years desktop support and 5 years server support), so I
wouldn't push farther than that on Linux for the time being.
Does 4.6 work sufficiently for C++11? I haven't used it in quite a
while.
Another thing to bring up is that we have a lot of classes which have
method pairs `foo_begin()` and `foo_end()` (e.g.
`Function::arg_{begin,end}()`). These don't play nice with range-for
loops (we are already seeing this come up in LLD). We probably should
adopt some lightweight "range" class and a naming convention
(`foo_all()`?) that will interact well with range-for. jyasskin, you
have some standards proposals for such a class, maybe you could try
bringing that into tree?
+1. I've done this in my own code and it is so very nice.
-David
compiler. Natively, that would mean supporting GCC 4.1 and 4.5,
disabling optimisation is acceptable. FreeBSD likely wants to add GCC
4.2 to that last.
Joerg
The C++ proposal changes rapidly. While it would be great to get usage
experience from LLVM in order to inform the C++ proposal, I don't have
"what will eventually be in C++" to propose for LLVM. Well, I'd expect
some "range<IteratorType>" template with .begin() and .end() methods,
but I don't even know what name that template will have.
Ah, I wasn't aware that it wasn't mostly stabilized. As you pointed
out, this isn't critical, so we don't need to rush it then.
I'm not sure this part of the discussion is on-topic for Chris's
thread, since it's not related to a potential problem with enabling
C++ language features. (Not having a range type doesn't make
range-based for loops fail to compile on some platform, it just makes
them slightly less useful.)
It's not critical. That was mostly a side note about the "code
cleanup" aspect of Chris's message. It has come up during LLD
development so I though it might be worth putting out there.
-- Sean Silva
FreeBSD 9.1 uses GCC 4.2.1 and Clang 3.0, although I have some doubts about the clang, at least on PPC32. Trunk clang compiled with the system clang crashes on code that the same trunk clang compiles fine when built with gcc. It may as well be a source problem in trunk though...
-Krzysztof
<dag@cray.com> writes:
4.6 is the official compiler on Ubuntu 12.04 (released 04/2012), which
is the latest Long Term Support release (which come out every 2 years,
with 3 years desktop support and 5 years server support), so I
wouldn't push farther than that on Linux for the time being.
Does 4.6 work sufficiently for C++11? I haven't used it in quite a
while.
I've been using gcc 4.6 on Kubuntu 12.04 until 12.10 came out, and it
dealed with the features Chris mentioned without problem.
auto alone is a huge readability aid and is supported since gcc version
4.4.
On this table compiler support for C++11 features is shown with the
respective versions:
http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
The main issue I see is for users who are stuck on ancient compilers for historical/dependency reasons. I know of build systems that still use Ubuntu 8.04 and Red Hat Enterprise 4, because the effort to convert outweighs the current benefits.
That said, I would be very much in favor of introducing C++11, provided a compiler baseline is well established. I agree with Sean that GCC 4.6 is the latest we could reasonably go.
Seeing as I’m using OS X and Debian Sid which is on GCC 4.7.2-5 which moved over to Wheezy for Debian 7 release it seems more reasonable to target that than using Ubuntu’s 4.6.x which is never more conservative than Debian on releases.
P.S. I’m more interested in actually seeing if this will improve an actual smooth installation of libc++ with llvm/clang/compiler-rt trunk so I can actually start using libc++ on Linux and not have to hack around to get it working. Get that going and I’m sure with Debian’s dual FreeBSD/Linux building of Deb packages with LLVM/Clang you’ll get plenty of community testing.
Seeing as I'm using OS X and Debian Sid which is on GCC 4.7.2-5 which
moved over to Wheezy for Debian 7 release it seems more reasonable to
target that than using Ubuntu's 4.6.x which is never more conservative than
Debian on releases.
So you're saying targetting 4.7 is more conservative than 4.6?
One other specific problem with this is that (I'm told) MSVC 2010 doesn't support range-based for loops. I don't think it is reasonable to require windows users to be on MSVC 2012. 
-Chris
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.
Why not C++11 libraries? Implementation/capatability reasons? I don't
know anything about how the various implementation compare in terms of
completeness. But the libraries use the new language features and
theoretically you get a performance boost "for free."
It's mostly about only changing one thing at a time. It's already possible to build LLVM in C++'11 mode and with a C++'11 library. Adding a dependency to *require* C++'11 compiler and/or C++'11 library are two orthogonal changes, and I'd like to tackle them one at a time.
I'm assuming we wouldn't release an llvm with C++11 until 3.4 at least
which gives folks a good 8 months to a year to prepare. Doing it in a
3.3 release shortens that considerably but it might be ok. The biggest
issue for groups like ours is upgrading the compiler we use to build our
compiler. We have a LOT of components and they all have to work with
the new build environment. It involves a lot of testing and assurance
which is where we might bump up against a 3.3 release, not having a new
compiler in place before 3.3 is out.
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).
-Chris
I suspect you're right about that, but I'd appreciate if some MSVC
users would speak up here. We shouldn't hold back on using range-based
for loops if all our MSVC users are happy to move to MSVC 2012
(assuming no problems with other platforms).
Hi,
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
One other specific problem with this is that (I'm told) MSVC 2010 doesn't support range-based for loops. I don't think it is reasonable to require windows users to be on MSVC 2012.
I suspect you're right about that, but I'd appreciate if some MSVC
users would speak up here. We shouldn't hold back on using range-based
for loops if all our MSVC users are happy to move to MSVC 2012
(assuming no problems with other platforms).
For our works project, we are still stuck on MSVC 2005 and MSVC 2010
(our software is a binary plugin to established products). Admittedly,
we are still sitting on LLVM 2.8 with patches from 2.9 (2.9 wouldn't
compile in MSVC 2010 for x64) . We want to move to current LLVM (not
least for the NVPTX and AMDIL targets), but have not yet had the
available man hours to do so.
Peter N