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: Hans Åberg
Subject: Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 359770043 by address@hidden)
Date: Sat, 7 Jul 2018 12:45:39 +0200

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

> We had some fallout when I used C++08 overload resolution rules for
> dealing with inherited acknowledgers

I thought just try to compile without introducing any new features with later 
compilers and later C++ version flags. The stuff that does not work with C++17 
could be removed, then use an earlier version flag for the distribution to 
ensure newer language features are not there.

> and it turned out Clang++ was buggy
> in that regard.  

It took long time to get C++11 right, so it is best to avoid older compilers I 
think. 

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

I got tired at the outdated clang that comes with MacOS, so I downloaded clang6 
at their site and copied into /usr/local/clang so it is easy to remove. Then 
setting Automake to use it in a separate build worked fine, also with the Xcode 
debugger.





reply via email to

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