Re: [cdt-dev] code completion & C++11

["Corbat Thomas (tcorbat@xxxxxx)" <tcorbat@xxxxxx>]

I don't think the problem at hand needs any change to how the code is parsed, nor will it have an impact on how the AST or the Index looks like - apart from what Sergey mentioned in the ticket that we don't store the visibility for nested types yet. But C++03 and C++11 behave differently in the semantics nevertheless.

 

Example (adapted from the standard):

class Enclosing {

    int field;

    class Nested {

        void function(Enclosing * e) {

            e->field = 23;

        }

    };

}

 

While the access to Enclosing::field from Nested::function is allowed in C++11 it isn't in C++03. Thus I guess it is just a different way of interpreting the code at hand when offering a completion of "field" or not.

 

 

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sergey Prigogin
Sent: Freitag, 8. Februar 2013 19:46
To: CDT General developers list.
Subject: Re: [cdt-dev] code completion & C++11

 

We have IScannerExtensionConfiguration, ICParserExtensionConfiguration, ICPPParserExtensionConfiguration interfaces 

 

On Fri, Feb 8, 2013 at 9:21 AM, Doug Schaefer <dschaefer@xxxxxxx> wrote:

That opens up something I've been wondering about. We're adding in support
for Qt slots and signals as semantic extensions to methods, essentially a
language extension. We had a vision a long time ago to support such
extensions, but it's pretty clear we haven't achieved that, at least not
easily.

I was looking to the C++11 work to see how we were doing that and noticed
that we were simply adding it to the parser without wrapping enablement
for it. That clearly can, and as we see in this thread, cause problems for
environments that are incompatible with the extension.

 

If you are aware of problems caused by C++11 parser features in environments that are not C++11 compliant, please file bugs.

For Qt, we're currently using a nature on the project to enable our
extensions. Lots of bad things happen if we enable them on non-Qt
projects. Not sure what the right answer is for C++11 other than to ask
the build settings to see if the compiler has the extensions enabled.
Adding an indexer specific setting isn't very good since average joe user
will never find it.

Does anyone have more background on the strategy we've selected?
Markus/Sergey?

 

We have IScannerExtensionConfiguration, ICParserExtensionConfiguration, ICPPParserExtensionConfiguration and few different implementations of these interfaces. GPPScannerExtensionConfiguration, for example distinguishes between four different versions of GCC.

Thanks,
Doug.

 

-sergey 

On 13-02-08 11:56 AM, "Nathan Ridge" <zeratul976@xxxxxxxxxxx> wrote:

>
>
>> Apart from that, is there a general policy about how CDT reacts when
>>the expected behavior of different standards is contradicting? Like the
>>access to other nested classes as in the attached example?
>>
>> Regards
>> Thomas
>
>Perhaps we can introduce a C++11 flag to the indexer settings?
>
>I think this would be useful in other contexts too. For example,
>if the flag was checked, the 'extract local variable' refactoring
>could make the type of the extracted variable 'auto' in cases
>where the explicit type name is not known.
>
>Regards,
>Nate
>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev