Dear all,
I was reading the discussion, and I use cross-compilation on a regular
basis for embedded system. Maybe this is a simple avenue that could be
tried while using modern C++ and still provide support for systems on which
only old compilers and libraries are available for developers.
@Mark Borgerding: do you think that would be feasible in the setup you must
maintain ?

It is really not that hard anymore to cross-compile.

- all the best,

On Wed, May 6, 2020 at 5:40 PM Clifford Yapp <[email protected]> wrote:

>
> On Tue, May 5, 2020 at 11:54 PM Rob McDonald <[email protected]>
> wrote:
>
>>
>> My user who recently had problems because my app developed a dependency
>> on std::regexp -- which isn't really supported by gcc 4.8.  The problem is
>> less the compiler and more the standard libraries installed on the
>> machine.  He is not building on the big machine -- he builds on a local vm
>> on a laptop and then transfers the binary up.  They also prefer to do their
>> local setup on images that are as similar as possible to the computation
>> environment.  Perhaps they could set up local compilers and libraries, but
>> that is a much bigger hassle than using system installed standard libraries.
>>
>
> For Redhat, Developer Toolset (
> https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/7/html/7.0_release_notes/dts7.0_release)
> provides a newer compiler environment using the "scl enable devtoolset-X
> <command>" mechanism.  We've recently switched to C++11 as a minimum
> standard, and you're correct that gcc 4.8 isn't up to the job.
> Fortunately, so far devtoolset has worked fine.
>
> I certainly understand the value to large customers of stability, but even
> for them the costs of maintaining code tied to an older standard grow ever
> greater over time.  As the broader community moves on and your available
> pool of contributors trained to (and willing to!) develop in older coding
> environments shrinks, you gradually lose the synergies of community which
> are such an important part of open source (or even software development in
> general.)  We've generally been pretty conservative about upgrading
> standards, but we finally reached a point where the difficulty of
> implementation and maintaining significant user features without the
> support of modern C/C++ was so great compared to the job of setting up
> something like developer tool-set that we could no longer justify sinking
> the time and effort into accommodating the limitations of the C89/C++98
> standards.
>
> Cheers,
> CY
>
>

Reply via email to