Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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

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?
We have IScannerExtensionConfiguration, ICParserExtensionConfiguration, ICPPParserExtensionConfiguration and few different implementations of these interfaces. GPPScannerExtensionConfiguration, for example distinguishes between four different versions of GCC.



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.
>cdt-dev mailing list

cdt-dev mailing list

Back to the top