__cplusplus implied?

[decimad]

I'm facing an issue with headers which would put typedefs into some namespace in case the header is compiled withing a c++ compilation unit. Now I'm working with C-Code which uses those typedefs, but the parset cannot locate them, since it parsed the header as C-Code.
Is there a way to suppress __cplusplus while parsing?

[sean-mcmanus]

What parser are you referring to? The Default IntelliSense engine, the Tag Parser, or the parser you use for compiling? Does #undef work?

[decimad]

Im using the "Default" parser which I understand to be the IntelliSense engine as opposed to the Tag parser.
I did not try to put an #undef there, since I figured removing the namespace-stuff temporarily was the safe bet.

[sean-mcmanus]

Is the translation unit C or C++? You should not have __cplusplus defined if your file type is .c (or registered as a "c" language file in files.associations). The IntelliSense parser has a C and C++ mode, so if __cplusplus is defined, it sounds like it's using the wrong mode. I think we need more info for a repro.

[decimad]

Well, all the CUs are .c, the types are defined in headers though. So if it is as you say, it might be that the connection is somehow not made to deduce parsing those headers as plain c - which could mean that I'm setting something up incorrectly? I will try to come up with more details after investigation during the weekend.

[sean-mcmanus]

I'm still confused as to what error you're experiencing. If you cannot locate the typedefs in namespaces in C code, then that sounds correct, because C doesn't have namespaces. If you open a .c file, then __cplusplus shouldn't be defined, but it's possible if you open the .h file, the IntelliSense engine will compile the header into a C++ translation unit (if it fails to match it up with the .c file, i.e. if it chose another .cpp file that included the header or fell back to a dummy C++ translation unit).

[decimad]

The .c file includes a header whose typedefs are declared inside a namespace iff __cplusplus is defined. In this situation type references inside .c file are squiggled. When I then remove the namespace-stuff from the header, the .c file doesn't show squiggles anymore. During all that time the CMake-Build works perfectly (like in the other issue)
Just answering your question quickly, I will still investigate this further to give more "educated" informations.

[sean-mcmanus]

It shows "C" and not "C++" in the bottom right corner when you open the .c file, right? If you use class c {}; and get `identifier "class" is undefined" then it means the translation unit is correctly treated as C code by our IntelliSense engine, and some external file is #defining the __cplusplus (Go to Definition might work to find the culprit); otherwise, if no errors occur, the code is incorrectly being processed as C++ and we'd want to find a repro.

[decimad]

Okay, I cannot come up with a real explanation, but sometimes .c source files get classified as c++ even though I did nothing related to setting up/overriding the extension defaults. More often it happens regularly that headers are classified as being c++. But this all rather seems to come from a "bad" interaction between the c++ tools, the cmake integration as well as the cmake-helper which serves as the gluing. Bad things happen most of the times at the time when the cmake-integration falls back to the "all" target (I could not yet find a reason why it does that all the time), at which point the cmake-helper can't deduce include paths anymore etc.. So I don't really think that it is a problem of the cpptools per se.

[sean-mcmanus]

We have seen the bug were a .c file gets added as a "cpp" file (seems to happen only in special situations), so we'll try to find a repro (and/or review the code) and fix it.

[sean-mcmanus]

The bug where .c/cpp files can get associated with the wrong "cpp"/"c" language has been fixed for the next update.

[decimad]

Great! Sorry I could not come up with a reliable repro :( Is there maybe something I can do to circumvent this beheviour until then?