How to migrate codebase to C++11

How to migrate codebase to C++11

[Tamás Kiss]

Hi,

I'd like to ask some questions about codebase migration to C++11. In
the company I work, we have a large C++ codebase, currently C++98. We
recently upgraded GCC to 4.8.3, so at last using C++11 became a
possibility. Our product is built on-, and runs on x86_64 Linux
platform only, so no cross-platform considerations are needed. We also
make use of some third party C++ libraries, that are also C++98. We
build everything from sources (including the 3PPs), so recompilation
is not an issue, and we always deploy all of our built code together
(i.e. no partial upgrades), so backwards compatibility between our
components is also not a problem.

We plan to recompile our own codebase with the -std=c++11 flag, and if
there are any problems, we can rewrite the necessary code parts. And
here comes my question at last :) Do we need to use the -std=c++11
flag also while recompiling the 3PP libraries, or is it enough to use
the same build environment with the same GCC version as used for our
own code? Or more simply put: can we use C++11 code and C++98
libraries together, given that they are compiled with the same
compiler on the same environment, just with different language version
flags?

This is important because unlike our own code, we can't just rewrite
things in 3PP libraries in case there are C++11 compilation issues,
and even if we could, we don't know those libraries well enough to do
so.

Some supplementary info: as far as I remember, we only use dynamically
linked 3PP libraries, but I'm not sure - anyway, I'm interested in
both dynamically- and statically linked cases. I did some research,
but only found info on some ABI incompatibilities in the C++ Standard
Library, and some ABI changes in GCC 3.7.X. And countless similar
topics on various websites, with roughly 50-50% distribution between
"yes it works, no worries" and "lol u mad bro forget it" answers.

Best Regards,
Tamas

Re: How to migrate codebase to C++11

[Jonathan Wakely]

On 22 August 2016 at 14:15, Tamás Kiss wrote:
> Hi,
>
> I'd like to ask some questions about codebase migration to C++11. In
> the company I work, we have a large C++ codebase, currently C++98. We
> recently upgraded GCC to 4.8.3, so at last using C++11 became a
> possibility. Our product is built on-, and runs on x86_64 Linux
> platform only, so no cross-platform considerations are needed. We also
> make use of some third party C++ libraries, that are also C++98. We
> build everything from sources (including the 3PPs), so recompilation
> is not an issue, and we always deploy all of our built code together
> (i.e. no partial upgrades), so backwards compatibility between our
> components is also not a problem.
>
> We plan to recompile our own codebase with the -std=c++11 flag, and if
> there are any problems, we can rewrite the necessary code parts. And
> here comes my question at last :) Do we need to use the -std=c++11
> flag also while recompiling the 3PP libraries, or is it enough to use
> the same build environment with the same GCC version as used for our
> own code? Or more simply put: can we use C++11 code and C++98
> libraries together, given that they are compiled with the same
> compiler on the same environment, just with different language version
> flags?

Yes.

There are some rare corner cases that can cause problems, see
https://gcc.gnu.org/wiki/Cxx11AbiCompatibility

With GCC 4.8.3 you should be OK.

Be aware that the ABI for the new C++11 components was not stable
until GCC 5.1, so if you upgrade to GCC 4.9.x you'll need to rebuild
everything again, and similarly if you upgrade to GCC 5.x

Since GCC 5.1 the C++11 support is stable and provides the same level
of ABI compatibility between releases as has long been available for
C++98 support.

See https://gcc.gnu.org/gcc-6/porting_to.html for some common problems
encountered when switching to C++11.

Re: How to migrate codebase to C++11

[Tamás Kiss]

Hi Jonathan,

Thanks for the answer! I also found the GCC ABI compatibility wiki
page you mentioned, that's why I had concerns. At least these seem to
be real issues for us:
* `vector::data()`'s return type changes from `pointer` to `_Tp*`
[gcc-4.6 - ...]
* `std::operator-(reverse_iterator)` and
`std::operator-(__normal_iterator)` [gcc-4.4 - ...]
* `istreambuf_iterator::reference` changes from `_CharT&` to `_CharT`
[gcc-4.7 - ...]

This also, but at least it would cause compilation error:
* Types with node allocators, like `deque` and lists, maps and sets
[... - gcc-5]

Based on the wiki page, I'm not sure how we could pinpoint the root
cause if any of the above issues would be triggered in our program,
especially if they would manifest in some runtime fault. On the other
hand, they all seem to be very "esoteric" issues, and luckily most of
our 3PP libraries focus on using as few C++ language features as
possible. I hope this "mixed C++ versions" approach will turn out to
be usable.

Thanks,
Tamas

2016-08-22 15:31 GMT+02:00 Jonathan Wakely <jwakely.gcc@gmail.com>:
> On 22 August 2016 at 14:15, Tamás Kiss wrote:
>> Hi,
>>
>> I'd like to ask some questions about codebase migration to C++11. In
>> the company I work, we have a large C++ codebase, currently C++98. We
>> recently upgraded GCC to 4.8.3, so at last using C++11 became a
>> possibility. Our product is built on-, and runs on x86_64 Linux
>> platform only, so no cross-platform considerations are needed. We also
>> make use of some third party C++ libraries, that are also C++98. We
>> build everything from sources (including the 3PPs), so recompilation
>> is not an issue, and we always deploy all of our built code together
>> (i.e. no partial upgrades), so backwards compatibility between our
>> components is also not a problem.
>>
>> We plan to recompile our own codebase with the -std=c++11 flag, and if
>> there are any problems, we can rewrite the necessary code parts. And
>> here comes my question at last :) Do we need to use the -std=c++11
>> flag also while recompiling the 3PP libraries, or is it enough to use
>> the same build environment with the same GCC version as used for our
>> own code? Or more simply put: can we use C++11 code and C++98
>> libraries together, given that they are compiled with the same
>> compiler on the same environment, just with different language version
>> flags?
>
> Yes.
>
> There are some rare corner cases that can cause problems, see
> https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
>
> With GCC 4.8.3 you should be OK.
>
> Be aware that the ABI for the new C++11 components was not stable
> until GCC 5.1, so if you upgrade to GCC 4.9.x you'll need to rebuild
> everything again, and similarly if you upgrade to GCC 5.x
>
> Since GCC 5.1 the C++11 support is stable and provides the same level
> of ABI compatibility between releases as has long been available for
> C++98 support.
>
> See https://gcc.gnu.org/gcc-6/porting_to.html for some common problems
> encountered when switching to C++11.

Re: How to migrate codebase to C++11

[Jonathan Wakely]

On 22 August 2016 at 17:16, Tamás Kiss wrote:
> Hi Jonathan,
>
> Thanks for the answer! I also found the GCC ABI compatibility wiki
> page you mentioned, that's why I had concerns. At least these seem to
> be real issues for us:

Based on what, just the GCC versions?

> * `vector::data()`'s return type changes from `pointer` to `_Tp*`
> [gcc-4.6 - ...]

For this to be an issue you need to be using the non-standard
vector::data() member (which is not part of C++03) with custom
allocators that use custom pointers. If you're not doing hat it's not
an issue.

> * `std::operator-(reverse_iterator)` and
> `std::operator-(__normal_iterator)` [gcc-4.4 - ...]
> * `istreambuf_iterator::reference` changes from `_CharT&` to `_CharT`
> [gcc-4.7 - ...]

These are even more unlikely to be real issues in practice.

> This also, but at least it would cause compilation error:
> * Types with node allocators, like `deque` and lists, maps and sets
> [... - gcc-5]
>
> Based on the wiki page, I'm not sure how we could pinpoint the root
> cause if any of the above issues would be triggered in our program,
> especially if they would manifest in some runtime fault.

As the top of the page says, you can check the symbols in your objects
and libraries to see if any problematic ones are present.

Re: How to migrate codebase to C++11

[Tamás Kiss]

2016-08-22 18:25 GMT+02:00 Jonathan Wakely <jwakely.gcc@gmail.com>:
> On 22 August 2016 at 17:16, Tamás Kiss wrote:
>> Hi Jonathan,
>>
>> Thanks for the answer! I also found the GCC ABI compatibility wiki
>> page you mentioned, that's why I had concerns. At least these seem to
>> be real issues for us:
>
> Based on what, just the GCC versions?

Yes, as the others are not present in 4.8.3. By "real issues" I only
meant "real issues to check", not that they are in fact present in the
code.

>> * `vector::data()`'s return type changes from `pointer` to `_Tp*`
>> [gcc-4.6 - ...]
>
> For this to be an issue you need to be using the non-standard
> vector::data() member (which is not part of C++03) with custom
> allocators that use custom pointers. If you're not doing hat it's not
> an issue.

You're right, I was thinking about string::data(), I did not realize
it is actually vector::data().

>> * `std::operator-(reverse_iterator)` and
>> `std::operator-(__normal_iterator)` [gcc-4.4 - ...]
>> * `istreambuf_iterator::reference` changes from `_CharT&` to `_CharT`
>> [gcc-4.7 - ...]
>
> These are even more unlikely to be real issues in practice.

Right again: I was thinking that we use the Boost 3PP with streams
extensively, but of course we'll recompile Boost to C++11 anyway, so
it's also not an issue. Boost is one of the libraries that I expect to
work in C++11 without issues.

>> This also, but at least it would cause compilation error:
>> * Types with node allocators, like `deque` and lists, maps and sets
>> [... - gcc-5]
>>
>> Based on the wiki page, I'm not sure how we could pinpoint the root
>> cause if any of the above issues would be triggered in our program,
>> especially if they would manifest in some runtime fault.
>
> As the top of the page says, you can check the symbols in your objects
> and libraries to see if any problematic ones are present.

We'll definitely do that. It's just that I still have the feeling that
we're doing some black magic with all these compatibility checks.
Anyway: if it's stupid but it works, it ain't stupid. :)