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

[David Blaikie]

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

In this case, the library authors would maintain & develop in C++98,
presumably - relying on forward compatibility warnings (-Wc++11-compat) to
help guide them. Then for release they'd build both 98 and 11 versions of
their binaries. Targeting your LCD makes a fair bit of sense to me.

Is there a particular case where one would be compelled to work in C++11
when developing and maintaining a library designed for backwards
compatibility? I suppose the use case you're describing is where the library
author is actively consuming the library in a C++11 context & tweaking the
C++98 library day-to-day as they work on their C++11 consumer of that
library. Possible, if somewhat inefficient, perhaps (that their build system
is actively building both libs all the time if the C++98/11 lib is such a
commonly used/general tool - I'd expect it to be built authoritatively,
perhaps)

Not to say that I don't see your point - certainly that scenario is possible
& the developer working on a C++11 library that depended on a backwards
compatible C++98 library that was compiling as C++11 in  his/her project
could benefit from such warnings being turned on for those files.


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

Not exactly 'style', no. Perhaps, let's say, "situational", and I think
that's what Doug's getting at - if it's not on-by-default, clang developers
aren't really paying much attention to it (I'm not sure I necessarily agree
with this method - but it's possibly a reality I can't change). The idea
being that people who have particular interest in particular situational
warnings would be better off maintaining a tool designed for them so they
don't get drowned out by the larger issues of just getting the clang
compiler to do its main job. (not to mention all that extra situational
stuff adds a burden to clang developers trying to do the hard job of writing
a C++ compiler)


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

I imagine these are real issues for cross platform code. For example: I
wouldn't mind if LLVM could adopt the use of 'nullptr', possibly the
simplest of C++11 features. This would maintain portability across all
practical compilers that I know of without getting into the realm of some of
the less consistently implemented C++11 features at this time. (I don't cite
this as a totally practical example, but at least one use case)

But that's a different scenario from the previous one, yes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111013/c1497e0f/attachment.html>