lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 3597


From: David Kastrup
Subject: Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 359770043 by address@hidden)
Date: Sat, 07 Jul 2018 13:12:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Hans Åberg <address@hidden> writes:

>> On 7 Jul 2018, at 12:14, David Kastrup <address@hidden> wrote:
>> 
>> Hans Åberg <address@hidden> writes:
>> 
>>> The first step would probably to switch to a later compiler with a
>>> flag for an older C++ version. Then one can test later C++ versions in
>>> independent builds.
>> 
>> We are not really sticking with older language versions as an
>> intellectual exercise but in order to stay with a least common
>> denominator of actually employed compilers.  Going to the bleeding edge,
>> even with compatibility flags, when the main distributions and/or our
>> users/integrators aren't there yet is not quite representative.
>> 
>> "I cannot reproduce your problem" is something I want to avoid.  I think
>> we are at a stage where C++11 is ok to demand, C++14 does not bring a
>> whole lot to the table, and C++17 is too early yet.
>
> There is a danger in using an older compiler that is not supported, as
> there might be bugs that are not going to be fixed.

Well, that's the point, isn't it?  If a significant amount of users have
no convenient choice avoiding that older compiler, we want to discover
any such bugs that are not going to be fixed in testing.  Catering to
bugs that aren't going to be fixed doesn't make less sense than catering
to bugs that are going to be fixed.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]