[cfe-dev] How to control C++0x adoption in a large codebase?

[Jeffrey Yasskin]

Hi clang folks,

I'm working on migrating a certain large codebase to C++0x, and we're
looking for a way to turn on C++0x mode but make sure people don't use
C++0x features before we're ready for them.

* We need to turn on -std=gnu++0x for the whole codebase at once
because C++98 and C++0x have different ABIs.
* Some of our code needs to be portable to a bunch of compilers we
don't control, so it needs to be as C++98-compatible as we can make
it.
* Other parts of the codebase can adopt C++0x features as we make sure
they work with our compilers and don't have hidden pitfalls.


I've attached a patch as one possible way to do this, but I'm
certainly not wedded to this particular strategy. The patch adds a
-Wc++98-compat flag, and demonstrates a plan to add individual
-Wc++98-compat-some-feature flags for each discrete C++0x feature or
change.

There are pros and cons to this strategy:
* This makes it easy to control the use of C++0x at a per-file
granularity. Files that need to be completely C++98-compatible can
pass -Wc++98-compat, while files that just need to use tested features
can turn individual ones back on with
-Wno-c++98-compat-initializer-lists.
* If every single mention of LangOpts.CPlusPlus0x in the codebase
triggers a need for an additional warning, that's about 200 extra
warnings (`git grep CPlusPlus0x|wc`). It'll probably be somewhat less
given that the attached patch covers 3 uses of CPlusPlus0x with one
new warning, but there are still features to implement that may
increase the number.
* For features that are also extensions to C++98, it's either a
duplicate warning, or with some extra work, maybe comes along for the
ride.


Clearly we'll never be able to do this perfectly, but if we can get
close, that'd dramatically reduce the build breaks that someone has to
track down and fix.

Thoughts? Suggestions? Alternatives?

Jeffrey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cxx98compat.patch
Type: application/octet-stream
Size: 4297 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111005/21efc76e/attachment.obj>