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

[Marcus Kool]

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.

Are you referring here to building squid 3.5 or 3.6 ?
Do you think that changing to C++11 is ok for both versions?

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

Admins do not want "the latest", they want "the latest proven".
For me that is 3.4.9 and when 3.5.5 comes out, it is time to evaluate
upgrading.  Depends also on the number and nature of complaints
on the mailing list.

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

The man page of gcc 4.8 explains the -std=c11 like this:
ISO C11, the 2011 revision of the ISO C standard.  Support is incomplete and experimental.

The man page of gcc 4.9.1 has a new text:
ISO C11, the 2011 revision of the ISO C standard.  This
standard is substantially completely supported, modulo bugs,
extended identifiers (supported except for corner cases when
-fextended-identifiers is used), floating-point issues (mainly
but not entirely relating to optional C11 features from Annexes
F and G) and the optional Annexes K (Bounds-checking
interfaces) and L (Analyzability).

Not sure if we can rely on man pages; it seems that gcc 4.9 is a safer 'minimal requirement'.

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

Suse 11 SP3 does not have gcc 4.8 either (only 4.7)
Suse 12 is also not mature, so it has the same problem as Redhat 7.

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

Most likely the systems with Redhat 6 stay on Redhat 6 for 18+ months
before upgrading to Redhat 7.  So until they upgrade, they have gcc 4.4.
Although I have no numbers on installed packages, it is very likely
that Eliezers' packages indeed help.  I bet that if the packages would be
downloadable from squid-cache.org their popularity will increase.

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

I understand.

Marcus

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