<Insert Picture Here> GCC and C++, again Paolo Carlini PhD
Outline 23 years of GCC! http://www.youtube.com/watch?v=zealhvoz8qq Since the last Summit, GCC 4.7.0 is out and C++11 is also out! A lot happened over the last year to implement more C++11 features And shake bugs affecting the existing ones Non-trivial projects are already globally enabling -std=c++11 (or -std=c++0x) in the builds.
Outline (2) Important GCC 4.7 features outside the C++ front-end are not discussed in the following, eg: General optimizer improvements (eg, LTO much improved for large programs, like Firefox; string length optimization) Back-end changes (AVX2 support for x86, Sparc improvements) Improvements for other OSes besides Linux (eg, <thread> is now supported for most Posix targets) OpenMP 3.1
Outline (3) Diagnostic improvements New C++11 features Torvald Riegel will cover the C++11 memory model, TM, new features in the concurrency area
-Wunused-local-typedefs Resolving libstdc++/33084 boiled down to fixing a library (ie, <valarrray>) function with this body: typedef _BinClos<_Name, _Constant, _ValArray, _Tp, _Tp> _Closure; typedef typename fun<_name, _Tp>::result_type _Rt; return _Expr<_Closure, _Tp>(_Closure( t, v)); Note the pointless typedef...
-Wunused-local-typedefs (2) indeed we had a trivial typo: _Rt _Tp In PR33255 I wondered if we could do something about this! In 4.7, the new -Wunused-local-typedefs warning (implemented by Dodji Seketeli) detects such sort of very suspect unused typedef. In 4.8, will be enabled by default as part of -Wunused have to make sure we don't give spurious warnings in some special cases unrelated to the typedef case proper
-Wzero-as-null-pointer-constant In C++11 there is a proper type for null pointer constants, std::nullptr_t, with value nullptr (*), eg: int* p = nullptr; preferably replaces: int* p = 0; Likewise in conditionals, everywhere. (*) http://en.wikipedia.org/wiki/c++11#null_pointer_constant
-Wzero-as-null-pointer-constant (2) The new -Wzero-as-null-pointer-constant, available in c++98 mode too, detects such uses of the legacy 0 literal to mean null pointer and helps moving code to C++11. First blush, it seems a trivial thing I did the work mostly to answer a PR and while doing that learning more about the C++ front-end but apparently quite a few users are finding it useful... because we got many PRs when the features was still buggy, and one for 4.7.0 too! The latter fixed for 4.7.1, was about 0 in default arguments.
-ftrack-macro-expansion Consider this simple example (provided by Dodji in the audit of PR7263) involving a buggy macro: #define OPERATE(OPRD1, OPRT, OPRD2) OPRD1 OPRT OPRD2 #define SHIFTL(A,B) OPERATE (A,<<,B) #define MULT2(A) SHIFTL (A,1) void g () { MULT2 (1.0); /* 1.0 << 1; */ }
-ftrack-macro-expansion (2) In 4.6, or without -ftrack-macro-expansion, the user only gets an error message about line #8, where the macro is actually expanded, has no clue that in fact the problem happens in the OPERATE macro, much earlier in the code. Isn't the default behavior (just yet) because a little more memory is used. Help testing it! This is useful for C too, of course. And this is also catching up with Clang++ ;) Likewise for -Wdelete-non-virtual-destructor Likewise for PR48934, about errors with SFINAE overloads
New C++11 features For a general summary, always refer to: http://gcc.gnu.org/gcc-4.7/cxx0x_status.html besides the release notes: http://gcc.gnu.org/gcc-4.7/changes.html
New C++11 features (2) Here only a couple of examples In my blog: https://blogs.oracle.com/pcarlini/ I'm posting concise introductions to many C++11 features, those delivered in GCC 4.7 included, for instance: Template aliases User-defined literals Non-static data-member initializers Explicit overrides and final
First example: explicit overrides and final In C++11 the identifiers final and override acquire a special meaning in some contexts: struct B1 final { }; struct D1 : B1 { }; // "cannot derive from 'final' base" struct B2 { virtual void f() final {} // "overriding final function" }; struct D2 : B2 { virtual void f() {} // "error" };
Explicit overrides and final (2) In both cases the code is rejected. Dually, this is also rejected: struct B3 { virtual void g(int) {} }; struct D3 : B3 { virtual void g(double) override {} // "does not // override" };
Explicit overrides and final (3) Thus a whole class of nasty bugs is easily avoided, like, in the case of D3::g, a new function inadvertently declared, instead of overriding an existing one. But, interestingly, this isn't just about avoiding bugs! In GCC 4.7, thanks to a nifty patch provided by Roberto Vitillo, calls of a virtual function marked final, like B2::f above, are devirtualized, thus optimized to more efficient assembly. Likewise for any virtual function declared in a class decorated with final as a whole, like B1 above.
Explicit overrides and final (4) Unfortunately, in order to deal correctly with final classes like B1 above, the entire C++ library has to be adjusted to carefully avoid in such cases the widespread Empty Base Optimization. A lot of work went into GCC 4.7 to handle correctly all these situations. But it seems that something better could be done in terms of C++11 specs... naively, it doesn't really make sense to renounce to the space saving advantages provided by EBO simply because a class is final!
noexcept and the library (2) The testcase (simplified): struct Stuff { Stuff( ) { } Stuff(Stuff&&) /* noexcept */ { /*... */ } Stuff(const Stuff&) { /*... */ } }; int main() { std::vector< Stuff > stuff; stuff.push_back( Stuff() ); stuff.push_back( Stuff() ); /*... */ }
noexcept and the library (3) In C++11, as released: no noexcept on the moveconstructor no safe vs exceptions move-semantics no move-semantics at all! Summarizing: If you are writing your own move-constructor, do your best to have it not throwing exceptions and, as such, explicitly decorate it with noexcept. Much more generally: noexcept is the future, old-style throw() exception specifications are deprecated in C++11, and 4.8 will likely warn for those.
Conclusions (for Paolo's talk) Please also send your ideas, observations, etc, to: gcc@gcc.gnu.org libstdc++@gcc.gnu.org... or simply to me ;) paolo.carlini@oracle.com
Thanks!
Random bibliography Some recent C++11 books: http://www.manning.com/williams/ http://www.cppstdlib.com/