Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 359770043 by address@hidden)

[David Kastrup]

Hans Åberg <address@hidden> writes:

>> On 7 Jul 2018, at 10:04, David Kastrup <address@hidden> wrote:
>> 
>> Hans Åberg <address@hidden> writes:
>> 
>>> The idea is to do it all now, then the change is automatic and the old
>>> code can just be removed at some point in time, but you would need a
>>> compiler that can do C++17, too.
>> 
>> The whole point is that we do not want to rely on C++17 now and don't
>> want to maintain a full reimplementation of a C++17 feature until we do
>> when that feature is used only once and in a minor manner.  The fallover
>> strategy for it becoming available is not really of relevance for that
>> call, but an automatic fallover would mean that we have dormant untested
>> code that becomes active at different points of time for different
>> people.
>
> 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.

We had some fallout when I used C++08 overload resolution rules for
dealing with inherited acknowledgers and it turned out Clang++ was buggy
in that regard.  In that case, I decided not to dial back the
refactoring because it would have been a lot of work and the result
would have been considerably more ugly, but if we had caught that early
on, the decision might have been different.  Also Clang++ is kind of low
priority since none of our official binaries are compiled in that manner
and it's not clear there is a two-digit number of users/integrators
working with a Clang++/LilyPond setup.

-- 
David Kastrup