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

[Douglas Gregor]

On Oct 5, 2011, at 3:35 PM, Jeffrey Yasskin wrote:

> 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.

Summarizing side discussion: libstdc++ has a different ABI in C++98 vs. in C++11, libc++ does not.

> * 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.

And you can't tell libstdc++ to use the C++0x ABI even in C++98 mode? 

> * 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?


This seems more like you're enforcing a coding style ("use only the C++11 features that we like") rather than providing a generally useful feature. I don't think we should be using the warning mechanism to enforce a coding style, for a number of reasons:

	- There are many coding styles in the world. Which ones do we pick? Just those that we as a community like (how do we decide that?), or all of those for which people submit patches? Is either of these sustainable in the long term?

	- Experience has shown that warnings that don't default to "on" tend to be broken over time. Yes, of these warnings are particularly are easy to implement, but that doesn't mean that they won't get broken or missed.

Style checking belongs in a plug-in. That way, different organizations can provide their own style checkers that run along with their builds without forcing the union of all styles into the mainline Clang front-end. Better yet, maybe someone will build a configurable style checker as a plugin, to save the effort of everyone having to implement their own plugin separately.

I'd like to hear more opinions on whether others consider the proposed warnings to be coding style enforcement, or whether they are generally useful. It's clearly not as obvious as if we were proposing -Wbraces-on-new-line or -Wmethods-names-start-with-a-verb.

	- Doug