bug-lilypond
[Top][All Lists]
Advanced

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

Re: Source compilation errors with c++14/GCC6


From: David Kastrup
Subject: Re: Source compilation errors with c++14/GCC6
Date: Wed, 02 Mar 2016 22:49:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Jon Ciesla <address@hidden> writes:

> On Wed, Mar 2, 2016 at 3:00 PM, David Kastrup <address@hidden> wrote:
>
>> Jon Ciesla <address@hidden> writes:
>>
>> > Lilypond 2.19.36/7 fails to build with GCC6 using the c++14 std, which is
>> > the new default for GCC6, as present in Fedora 24+.  Attached is a patch
>> > allowing Lilpond 2.19.37 to build.  Please review and adopt if
>> applicable.
>> > If there are better corrections than what I've done here, please let me
>> > know and I'll update our patch, at least until a future release builds
>> > unpatched.
>>
>> The proposed changes are pretty much unilaterally horrible.
>>
>>    // code maintenance while being harder to understand and quite
>>    // trickier in its failure symptoms when things go wrong.  So we
>>    // just use a static zero as "not here" indication.
>> -  static const int type_p_name_ = 0;
>> +  static const int type_p_name_ = NULL;
>>
>> Why would a const int be set to NULL, a pointer constant?
>>
>> And since that apparently doesn't even work, you afterwards apply
>> reinterpret_casts (pretty much the worst kind of cast) on everything.
>>
>> What kind of error message are you getting for the original code?
>
> Original error messages here, i build.log:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1307746
>
> This is an additional reference:
>
> https://gcc.gnu.org/gcc-6/porting_to.html
>
> Alternative suggestions are more than welcome.

Compile as C++11.  It's quite ridiculous how the C++ standard committee
creates a completely new puzzle game for making templates work every
single time.

You are probably not happier if I cite all the passages making the
current code valid C++11, and I don't have access to the C++14 standard.

And it's bloody ridiculous anyway that GCC 5 does not yet permit using
C++11 (like std::nullptr_t) while GCC 6 does no longer permit using
C++11 (like using an integral 0 constant as null pointer constant).
I actually suspect GCC to be wrong here but without access to a C++14
standard, it's guesswork at best.

I don't think it's a reasonable expectation to be able to cater for
_three_ different standards of C++ at the same time with non-trivial
template code when the standard committee goes out of its way to make
them differ in significant details significantly.

-- 
David Kastrup



reply via email to

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