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

[Douglas Gregor]

On Oct 13, 2011, at 10:52 PM, Chandler Carruth wrote:

> On Thu, Oct 13, 2011 at 5:32 PM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> 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.
> 
> Just to clarify why I think this is relevant even though libc++ avoided the problem: I would like to preserve the ability to use Clang productively in C++11 mode with libstdc++; doing so appears to require a codebase-wide switch due to ABIs.

I fully understand them wanting to use C++11 as a reason to break the libstdc++ ABI (and switch to more efficient data structures), but it's rather unfortunate that they didn't make it easy to use the new ABI with C++98/03 code. Oh, well; it's this way now and we'll have to deal with it.

> 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.
> 
> Emphatically agree on the last sentence here. If that's were this ends up, it doesn't belong.
> 
> 
> Ok, so why don't I think this is a style issue? First, let's separate two aspects of the discussion which may simplify things.
> 
> Consider just a single warning flag: "-Wc++98-compat", designed for use in "-std=c++11" mode. The goal is to warn about obvious code patterns that break backwards compatibility. Why is this flag useful from a strictly functional perspective? Because developers may need to have non-trivial amounts of code compiled in both C++98 and C++11 contexts. Imagine some libraries are expected to work with projects whose compilers do not yet support C++11, *and* projects which actively use C++11. Because of libstdc++ issues, all of the code may need to be compiled as C++11 in the latter case. Even without this, headers will leak across the TU boundary and thus be compiled in both modes.
> 
> I think getting into this situation is inevitable for both open source and corporate codebases. That's one of the primary reasons developers will use "-Wc++11-compat" when in "-std=c++98" mode. Not offerring the complementary set of warnings means that those developers or users working with C++11 builds must (if they modify the library) constantly build twice to ensure they haven't introduced an incompatibility. Sure, "-Wc++98-compat" may never be perfect (any more than "-Wc++11-compat" is perfect), but it simplifies the developer experience when there is some external need or pressure to have a body of code which is valid in both modes.

I guess I have always viewed building as C++98/03 with  -Wc++11-compat as the "proper" way to develop dual C++98/11 code bases, because you're certain that it compiles as C++98/03 and you get a rap on the knuckles if you stray into C++11. It says, "I know I'm targeting C++98/03, but I want to be ready for the future."

Having things the other way---build as C++11 but don't use its features at all---seems strange to me. It's saying "I'm targeting C++11 but I can't use any of the features of C++11". But, I understand better now why this comes up with libstdc++… and I can see how others will hit it.

> Now, a somewhat separate issue is the detailed warnings for individual features of C++11. I have some vague ideas as to why these may be functionally necessary for codebases migrating from C++98 -> C++11, or ways that they might ease such a migration. But I'll be the first (ok, the second?) to say that they both introduce a lot more concerning questions (does C++11 make sense sans features X, Y, and Z? I don't know...) and are much closer to style issues, so maybe we can start by discussing nothing more than a single "-Wc++98-compat" flag. No selection, no preferences, just a compatibility warning.


You've convinced me that -Wc++98-compat is necessary and makes sense; that's it's not an issue of style, but is an important use case. Thanks for clarifying.

I'm much more dubious of the detailed warning flags for individual features, because that's leaning toward letting users pick their own subset of the language, and (to me) that's far more of a coding convention issue.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111014/3d0b98cb/attachment.html>