Re: [boost] List of C++ 11 only Boost libraries and their status?

Subject: Re: [boost] List of C++ 11 only Boost libraries and their status?
From: Dave Gomboc (dave_gomboc_at_[hidden])
Date: 2014-12-13 17:43:46

On Sat, Dec 13, 2014 at 08:37 AM, Rogerio dos Santos
<rogerio.santos.main_at_[hidden]> wrote:
>
> On Sat, Dec 13, 2014 at 8:27 AM, Nat Goodspeed <nat_at_[hidden]> wrote:
>>
>> I'm just contradicting the assumption that those who must work with
>> old compilers aren't doing any new development, or have no interest in
>> new libraries.
>>
>
> To add to this point, I would like to mention that even new developments
> trends might require support to old or limited compilers. E.g.: IoT, real
> time projects, industrial HMIs and mobile applications.
>
> Roger

Indeed.  I work on embedded, real-time industrial control systems in a
field where certain specifications (unfortunately, IMO) severely
restrict the platform choices available.  In many cases, the systems
developed must be built using pre-C++98 compiler technology.  While
that is a problem I am attempting to address, I suspect it is going to
take at least another year to do so, and I am confident that at least
one of the platforms will probably never support multi-threading even
if its vendor does end up improving or replacing its toolchain (and I
have no iron-clad guarantee from the vendor that the toolchain will
actually be improved or replaced, though I have a reasonable hope).
None of the above constraints imply that the libraries developed by
Boost are not of use for these systems, or that we are not interested
in using Boost libraries to the extent that it is possible to do so.

I think it is possible to structure compatibility code so that it
doesn't egregiously interfere with future development.  I always get
nervous when Steve posts asking to hack away the support for a few
more of the older toolchains.  While I fully appreciate that his
end-goal is well-intentioned, there's still important code out there
relying upon some of those pre-C++98 workarounds that can still
benefit from the fixes and new libraries introduced into new versions
of Boost.  Consequently, I'm much in favour of allowing Boost library
maintainers who wish to retain support for older compilers the
latitude to do so.

Dave