lilypond-devel
[Top][All Lists]
Advanced

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

Re: lily/freetype-error.cc: const struct #include ;


From: Wols Lists
Subject: Re: lily/freetype-error.cc: const struct #include ;
Date: Mon, 06 Sep 2010 22:30:41 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100727 Thunderbird/3.1.1

 On 06/09/10 22:19, Graham Percival wrote:
> On Mon, Sep 6, 2010 at 8:08 PM, Werner LEMBERG <address@hidden> wrote:
>> [Wearing the FreeType maintainer hat]
> :)
>
>>>> I see a really weird C++ construct in this (short) file:
>> What's the problem?
> The problem -- and I readily admit that this isn't a problem with
> freetype -- is that if we run our fixcc.py script on the file twice,
> it produces:
> ----
> } ft_errors[]
>
>   = #include <freetype/fterrors.h>;
> ----
>
> which g++ obviously doesn't like.
:-)
> Now, I totally admit that we might not want to continue using
> fixcc.py... and also that we could tweak fixcc.py to avoid this
> particular type of change... and also that fixcc.py is previously
> confused by a
> #define FT_ERROR_START_LIST {
> (it puts the { on a new line, then indents everything as if it was
> inside a function)... but since I didn't recognize the C++ construct,
> I thought it was worth asking.
>
As a C programmer, it took me about 30 seconds (or less) to twig what it
was doing.
> I mean, why _do_ we have a hanging = sign?  I could understand if it
> was any of these:
> } ft_errors = 0;
> } ft_errors = NULL;
> } ft_errors;
>
> (with the #include being higher up in the file), but it seems really
> weird to have a dangling = sign in there.
>
Because C doesn't give a monkeys about white space, but the
pre-processor does. The #include has to be the first thing on the line
otherwise the pre-processor will screw up, but once the pre-processor
has done its job, the compiler will happily ignore all the surplus new
lines.
> If you're certain that this is good usage, though, then that's ok.
> I'll figure out some other way of dealing with this problem.
Dunno about "good", but in the circumstances it's "sane" :-)
> [for the curious: other than this issue, there's only one more case
> where fixcc.py produces un-compilable code.  Once that's cleared up, I
> can begin seriously comparing different indentation programs]
>
> Cheers,
> - Graham
>
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
Cheers,
Wol



reply via email to

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