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

[Chandler Carruth]

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.


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

I'll let Jeffrey comment here, but I believe we looked into this and it was
very non-trivial... I'd be interested in his thoughts here.

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:


I really *really* don't want to restart this discussion. I actually think
we're in agreement here. If it comes down to style, the compiler has *no*
business doing this in a warning. However, I'm not yet convinced this comes
down to style...


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

This argument may be invalid, there may be reasons why it's not worth doing
(although unless other problems / options arise, it seems to be worth our
time at Google), but I don't this is style related.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111013/7c31a431/attachment.html>