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

[Doug Schaefer <dschaefer@xxxxxxx>]

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.

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?

Thanks,
Doug.

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