[cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
Joshua Cranmer 🐧
Pidgeot18 at gmail.com
Mon Oct 28 19:13:01 PDT 2013
On 10/28/2013 7:06 PM, "C. Bergström" wrote:
> Further - While c++11 is the best thing ever - Is there actually a
> driving use case where using c++11 features will significantly improve
> the quality of the codebase? implementation perspective or
> performance? Are there coding style guidelines which should be updated
> - I've seen code (ab)using auto where it was mostly author preference
> and not really necessary. You really push for this, but the underlying
> motivation still seems unclear. (Show me the c++11 code in the
> subproject which is the root cause please)
From using C++11 on other projects, here are the following beneficial
use cases I have already seen:
1. type_traits. Enough said.
2. auto helps keep line length down in statements like:
for (auto I = M.begin(), E = M.end(); I != E; ++I)
3. static_assert. Yes, you can fake it with a macro, but this doesn't
work in some extreme edge cases.
4. decltype. I've seen need for it once or twice.
5. std::atomic. Dealing with compiler-specific atomic intrinsics is a
royal pain (although dealing with broken compiler/standard library
combinations is just as bad), and std::atomic also gives you some better
speed performance if you need it.
6. char16_t. If you ever use any UTF-16, this and u"" make your life a
lot easier. Except if you have to support MingW gcc on Windows.
7. Deleted functions, override, final. Earlier diagnostics for when
someone does something stupid. You can also get away with nonvirtual
destructors if you use final.
8. Variadic templates. If you can't use them, you have to resort to
macro trickery, which gets brittle and fragile very quickly.
I haven't had a chance to use the new <random> or std::unique_ptr yet,
but those have big benefits compared to existing code (rand is broken,
and std::auto_ptr is even more broken).
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
More information about the cfe-dev
mailing list