[Bug default/26021] New: Upgrade the C++ standard to C++11

[Bug default/26021] New: Upgrade the C++ standard to C++11

[maennich at android dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26021

            Bug ID: 26021
           Summary: Upgrade the C++ standard to C++11
           Product: libabigail
           Version: unspecified
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: maennich at android dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Libabigail currently follows the C++03 standard (plus TR1). The most current
released standard as of writing is C++17. I would like to suggest upgrading the
minimum C++ standard for libabigail to C++11 (I have a preference for C++14,
but I can see how that gets tricky).

C++11 introduces significant additions to the language and to the standard
library that we can and should make use of.

The most significant is likely the introduction of rvalue references. Among
others, it enables unique_ptr and would allow replacing a lot of instances of
shared_ptr use by unique_ptr. That has the potential of clarifying ownership as
well as performance improvements due to the elimination of reference counting.
In addition, we get lambdas, shorter iteration notation and range-for loops,
auto, nullptr, etc. Not to speak of various additions to the standard library
such as basic_regex. These are all features I would have liked to use in the
last couple of patches. There is much more in the C++11 standard that we can
make use of, but I am not listing everything here as a lot is written about it
elsewhere. Bumping up the standard is not just for convenience and development
velocity, but also to improve stability and performance as well as readability
of the code base. I have helped transition several projects into C++11 in the
past and that has always been a big win for the following development and for
the project.

Libabigail can be compiled in C++17 mode (even with LLVM's libcxx as a standard
library) and that configuration has been thoroughly tested in production. In
addition, whenever the default standard is chosen, libabigail lets compilers
use newer standards. For instance, GCC 6.1 and later will compile in C++14 mode
regardless. The code base as of today is also compatible to be compiled with
Clang without further modifications.

Hence, bumping up the standard would be a matter of allowing new language
features to be used, and likely to explicitly set a minimum standard in the
Makefiles.

When projects allow new standards, it often comes along with some migration
activity and tools like clang-tidy are very helpful to assist with that.
Especially towards C++11. While desired, it will likely produce review load for
(mostly) boring but useful changes. In addition, few of the new features are
controversial and the introduction of those needs to be discussed first. One
way of addressing this is to gradually allow new features to be used (as per a
continuously evolving documented coding standard). Still, some of the codebase
will remain in the former standard until touched. That is not necessarily a bad
thing, just a prediction.

A successful example for such a migration to modern C++ is CMake. The style
guide
(https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/dev/source.rst)
explicitly gives C++11 as the standard and lists additional features from
future standards that have been backported to the project to still compile as
C++11, but allow future language use.

There is one catch though: complete C++11 support requires GCC 4.8 or later.
That is a given for major Linux distributions (Debian since jessie (2015),
Ubuntu since 13.10 (2013), SLES 12+ (2014), RHEL7+ (2014)). The one platform
where libabigail is released in the latest version and that does not support
C++11 fully is (afaik) RHEL6. That was released in 2011 and is due to go into
extended support later this year.

I am not sure about the requirement for RHEL6 to still receive the latest
feature updates after so many years, but maybe it is worth considering going
towards version 2.0 and retiring some of the old platforms. 1.x could still
receive some fixes, while 2.0 continues.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [Bug default/26021] New: Upgrade the C++ standard to C++11

[Dodji Seketeli]

maennich at android dot com via Libabigail <libabigail@sourceware.org> a
écrit:

[...]

> There is one catch though: complete C++11 support requires GCC 4.8 or later.
> That is a given for major Linux distributions (Debian since jessie (2015),
> Ubuntu since 13.10 (2013), SLES 12+ (2014), RHEL7+ (2014)). The one platform
> where libabigail is released in the latest version and that does not support
> C++11 fully is (afaik) RHEL6.

That is right.

>  That was released in 2011 and is due to go into extended support
>  later this year.

I believe, so, yes:
https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel.

> I am not sure about the requirement for RHEL6 to still receive the latest
> feature updates after so many years, but maybe it is worth considering going
> towards version 2.0 and retiring some of the old platforms. 1.x could still
> receive some fixes, while 2.0 continues.

Up until now, I have always updated libabigail in all versions of Fedora
and EPEL
(https://fedoraproject.org/wiki/EPEL#What_is_Extra_Packages_for_Enterprise_Linux_.28or_EPEL.29.3F),
including EPEL 6 (compatible with RHEL6).  That makes it available in
all the "Enterprise Linux" distros like CentOS, SL, OL, etc, and RHEL,
of course.

I would think that we could move to c++11 (we can't go higher because
EPEL 7) once RHEL 6 reaches end of life and get into extended support by
end of november this year, unless I am missing something.  That would
mean that I would stop updating libabigail in EPEL6 at that point.  If a
particular bug that needs fixing and is brought to my attention, I'll
try to fix it specifically in that EPEL6 branch if that makes sense, I
guess.  At least that's my current understanding of it.

Would that work for you?

-- 
		Dodji

[Bug default/26021] Upgrade the C++ standard to C++11

[dodji at seketeli dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26021

--- Comment #1 from dodji at seketeli dot org ---
maennich at android dot com via Libabigail <libabigail@sourceware.org> a
écrit:

[...]

> There is one catch though: complete C++11 support requires GCC 4.8 or later.
> That is a given for major Linux distributions (Debian since jessie (2015),
> Ubuntu since 13.10 (2013), SLES 12+ (2014), RHEL7+ (2014)). The one platform
> where libabigail is released in the latest version and that does not support
> C++11 fully is (afaik) RHEL6.

That is right.

>  That was released in 2011 and is due to go into extended support
>  later this year.

I believe, so, yes:
https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel.

> I am not sure about the requirement for RHEL6 to still receive the latest
> feature updates after so many years, but maybe it is worth considering going
> towards version 2.0 and retiring some of the old platforms. 1.x could still
> receive some fixes, while 2.0 continues.

Up until now, I have always updated libabigail in all versions of Fedora
and EPEL
(https://fedoraproject.org/wiki/EPEL#What_is_Extra_Packages_for_Enterprise_Linux_.28or_EPEL.29.3F),
including EPEL 6 (compatible with RHEL6).  That makes it available in
all the "Enterprise Linux" distros like CentOS, SL, OL, etc, and RHEL,
of course.

I would think that we could move to c++11 (we can't go higher because
EPEL 7) once RHEL 6 reaches end of life and get into extended support by
end of november this year, unless I am missing something.  That would
mean that I would stop updating libabigail in EPEL6 at that point.  If a
particular bug that needs fixing and is brought to my attention, I'll
try to fix it specifically in that EPEL6 branch if that makes sense, I
guess.  At least that's my current understanding of it.

Would that work for you?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/26021] Upgrade the C++ standard to C++11

[maennich at android dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26021

--- Comment #2 from Matthias Maennich <maennich at android dot com> ---
That sounds good to me and seems to cover all users fairly.

Thinking out loud:

Making a 'final' 1.x feature release would make sense to me then. Maybe
let's call it 1.8 and continue 2.x with C++11? In that case we would
have to branch away into 1.x in the next months and stabilize 1.8 as
much as we can to eventually release a good last version into EPEL 6.
That also creates the future bug fix branch for 1.x.

Consequently, we could, after branching had been done, work on allowing
C++11 (docs, etc.) on the then 2.x master branch to proceed.

How do you like that?

-- 
You are receiving this mail because:
You are on the CC list for the bug.