[Geany-Devel] C++11 Bug discussion (transferred from bug tracker)

Colomban Wendling lists.ban at herbesfolles.org
Wed Oct 24 09:56:49 UTC 2012

Le 23/10/2012 04:58, Lex Trotman a écrit :
> OOps previous post sent before completion.
> On 23 October 2012 12:42, Lex Trotman <elextr at gmail.com
> <mailto:elextr at gmail.com>> wrote:
> [...]
>         c: ok, complete parsing of numbers may help, but it probably
>         would just not
>         highlight the non-numeric suffix (as the string suffixes, your
>         "d" point).
>         Though, note that the current highlighting of numeric constant
>         is perfectly
>         exact from the C preprocessor point of view (last point of
>         http://gcc.gnu.org/onlinedocs/gcc/Incompatibilities.html). BTW,
>         I have a
>         patch for "proper" number parsing I did for the Vala number
>         methods bug.
>      Yes, for C, the definition of "preprocessor token" for C++11 has
>     been extended to include user defined literals.  Scintilla may need
>     to be fixed to distinguish standard numbers from user numbers so we
>     can highlight them differently, same for string user literals below.

I attached the patch I was talking about,

I'll discuss it on the Scintilla ML or BT soon too.

>         d: this is not really fixable, how would you differentiate a
>         "string"MACRO_OR_DEFINE from those C++11 user literals?
>     As I read C++11 standard thats a user defined literal token, not a
>     string token and an identifier token, rather like the number-number
>     example (in the gcc doc you referenced above) isn't two numbers
>     subtracted.  Its something that may be different between C and C++
>     and c.c and Lexcpp.cxx may need changing to reflect that.

OK, GCC agrees with you.  So C++11 is incompatible with earlier versions
of C++, wow.  Wonderful.  This probably means we'll need a new filetype,
lexer and parser for this new C++11 language :)

>         f: ok, quite easy to fix, but having declarations (so without the
>         definition) in the type list may confuse the scope completion
>         code (since
>         the declaration is a perfect match, simply with no children).
> Yeah, I guess completion has to be taught to ignore tags with no content
> in favour of ones with content.

Well, for C it'd be OK since empty structures (and probably others) are
invalid, but that's probably not the case for other languages, so simply
skipping empty containers would only give *more* suggestions, not
*better* ones.

Anyway, patch
0001-Create-tags-of-the-appropriate-type-for-forward-type.patch attached
-- though again I'm not sure it's good.

>         [...]
>         n: I don't understand this one.
> Ok, I did say being picky, but it affects autocomplete.  In C++11 you
> can delete inherited functions (at least the special member functions,
> and I think any one) using a function declaration = delete; syntax.
>  These functions are unavailable and shouldn't be in autocomplete, but
> because they look like declarations, at the moment, they are in the
> symbols looking like normal functions and they are in autocomplete.

OK, so any "= delete" declaration should simply be ignored?

>         v: nor do I get this one.
> I was just saying "I know its documented as a limitation, but the fact
> that local declarations are not parsed is still a deficiency".  As
> mentioned on IRC I have been trying various fixes for this but have
> gotten nowhere.

OK, so that's more a feature request than a bug ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-LexCPP-really-parse-numeric-constants.patch
Type: text/x-patch
Size: 3994 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20121024/e5f5098f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Create-tags-of-the-appropriate-type-for-forward-type.patch
Type: text/x-patch
Size: 1799 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20121024/e5f5098f/attachment-0001.bin>

More information about the Devel mailing list