[squid-dev] FYI: the C++11 roadmap

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/11/2014 1:27 a.m., Marcus Kool wrote:
> 
> 
> On 11/05/2014 02:01 AM, Amos Jeffries wrote: On 6/05/2014 2:21
> a.m., Amos Jeffries wrote:
>>>> I have just announced the change in 3.4.5 regarding C++11
>>>> support and accompanied it with a notice that GCC verion 4.8
>>>> is likely to become the minimum version later this calendar
>>>> year.
>>>> 
>>>> As it stands (discussed earlier):
>>>> 
>>>> * Squid-3.4 needs to build with any GCC 4.0+ version with
>>>> C++03.
>>>> 
>>>> * Squid-3.6 will need to build with C++11.
>>>> 
>>>> * The Squid-3.5 situation is still in limbo and will depend
>>>> on how long we go before it branches.
> 
> Squid-3.5 retains GCC 4.0+ support shared with older versions.
> 
>>>> 
>>>> We have a growing list of items needing C++11 features for
>>>> simpler implementation. At this point I am going to throw a
>>>> peg out and say Sept or Oct for starting to use C++11
>>>> specific code features.
> 
> This "peg" has now moved to Nov. The code cleanup and polishing 
> patches now going into trunk work fine with C++11 builds but
> possibly not with compilers older than Clang 3.3 or GCC 4.8.
> 
>> It is understandable that developers want to move forward.
>> Almost everybody does. But system administrators tend to do the
>> opposite: they stay on a stable platform for as long as possible
>> while they wait for a new platform to mature. Lets look at the
>> most popular Linux server platform: Redhat 6 / CentOS 6. Redhat 6
>> has gcc 4.4 while the successor Redhat 7 has gcc 4.8. This means
>> that when Squid gets a new requirement with gcc 4.8 the new 
>> versions will not run on Redhat 6.
> 
>> Because Redhat 6 is the most popular and stable server platform
>> and Redhat 7 is not mature and does not meet my expectations of a
>> stable platform (especially systemd is still a big troublemaker),
>> this implies that choosing for C++11 effectively means that new
>> releases of Squid will not be installed any longer on the most
>> popular Linux server platform.
> 
>> So I think my opinion from the point of view of a system
>> administrator is clearly "choose for installability, choose
>> C++03".

"If an admin is so dearly wanting aged-stability. What are they doing
building the latest Squid release in its youth?"

Seriously though, these are my reasons for the timing:

* Both clang 3.3 and gcc 4.8 were released in early 2013. By the time
these Squid-3.6 builds get near a beta release these compiler versions
will already be nearing their 3rd birthdays.

* Most of C++11'isms expected to be useful are the early "C++0x"
features (atomics, auto etc.) which are supported by GCC 4.4 from
RHEL6 anyway. RHEL6 people just need to explicitly pass one of the
special C++0x flags when building. The reason for naming those
specific compilers is that they are the first to offer *full* C++11
support.
  ** if someone wants to work on auto-detecting RHEL6 / CentOS6.5 and
auto-enabling that option, great.

* It is growing more and more difficult to prevent useful C++isms
showing up.
http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3-13627.patch
took several days with clean rebuilds to even find out what the
problem was. Some like auto have now been around in the literature and
example code for 5+ years.

...regarding RHEL and CentOS specifically...

* RHEL/CentOS are the only OS family which has this problem. The
others are all on shorter or simply earlier cycles of turnover and
will be providing the compilers in their mainstream OS versions by
about the same time Squid-3.6 goes beta, if not already now.

* If RHEL7 matches the same cycle as 6 and 5 before it did then we can
expect a RHEL7.1 in a couple of months when todays trunk starts to get
early adopters, and a RHEL7.2 around the end of next year when todays
trunk becomes Squid-3.6 beta. 7.4-ish being the popular one approx. 1
year behind Squid-3.6 going stable. Squid appears to have about a year
lag in popularity anyway, though Eliezers' packages are helping things
change a bit there.


So now seems about right to introduce C++11.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUWj45AAoJELJo5wb/XPRjcuEH/1pLRCnnEpwJ7igE2+x5rFN9
6R/wUbZmnkzlYJnYMgUB1Pu8i9NQbuYWgxMqv0pW+iB6us/Pj3xYawyIZ50aOPkA
5f4nD3Bb5X5poGOUqEJ2XwouzoIqIdDeXqAgKFsdpOOKr7aICHxMFMkrzra0RSjd
jsHEhX41FtNzwvspUpYe+dZIIFiAcfoZesYR2rzry1o/O/WHQhJSeZ1vgbYS/NrC
ehZ/EdxR0gAEFSMDPIjdUYECyKq8iT6ylmyPtNj8uuaVKlL07IegdznXPKQL0ZFF
pELQo4IZtglw5A3YaIXaveVh13jfYz1oHZ79Q4R/eOZhWfZuuOH1LCXHQd7YMWw=
=mCGV
-----END PGP SIGNATURE-----