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

[Ahmed Charles]

On Thu, Oct 13, 2011 at 11:55 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Thu, Oct 13, 2011 at 11:13 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>> 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)
>
> I don't think your conclusion follows from your statement of my use case...
> Let me try to more concretely describe the practices and patterns I'm
> seeing, and would like to support:
> Project X develops some utility code. Eventually it becomes useful, and so
> it gets factored into a library. I've seen lots of OSS compression,
> protocol, and toolkit libraries start this way here at Google (Snappy,
> Protobuf, Omaha, ...). The project that initially used it is still the
> primary maintainer and consumer, but they grow additional users. Now if that
> project starts using C++11 actively, they face (in my view) an unfortunate
> choice of maintenance burdens:
> a) Separate development of features in the library from the development of
> consuming use cases s.t. the library development activity can use a
> different build / test / release model, or
> b) Develop the library in C++11, but for each release, run it through C++98
> builds to make sure it still works for other consumers of the library.
> In case (a), essentially they have to double their builds. I think that's
> really unfortunate and an undue burden to impose, but maybe others disagree.
> In case (b), they have a really slow feedback cycle in learning about issues
> in the code they've written. I think that's also bad.
> How do we solve it? My proposal is the same way we have solved it for
> projects in the reversed position, with some consumers using C++11 but not
> the primary maintainers: we give them a compatibility warning flag.
> Perhaps this is just an edge use case, but I'd like to point out that
> I foresee Clang itself getting into this situation. Imagine if the static
> analyzer becomes a nicely separated project, and begins using C++11 features
> heavily. Many Clang developers, actively contributing to both the core and
> the analyzer, would likely choose to build in C++11 mode. How frustrating
> would it be to catch in the build bots when we accidentally used 'auto' in
> the wrong file?

We already have this today, though on a small scale. People using MSVC
(I use it and clang/linux) have breaks in both directions (llvm::next
vs std::next, which breaks MSVC and someone checking in auto would
break c++98). I basically end up building both and testing both. So, I
suppose I'm already voting with my feet, even if my case isn't
typical.

In any case, the warning won't solve library issues, like using
next(std::vector) in the clang namespace without qualifying llvm::,
because it's found using adl. There are likely to be lots of issues
that the warnings couldn't hope to cover. I'm not against the
warnings, but ultimately, if you aren't building with C++98, you can't
be sure that it works there.