Intellisense squiggles with C++-compliant code

1

I seem to not to be alone with this annoying Intellisense “feature”, but found no solution yet:

This class definition

class PushClient
{
protected:
  struct {
    uint8_t _slaveID;  
    uint16_t _addr;     
    uint16_t _wrds;    
    uint8_t *_data; 
    uint8_t _result; 
  } _comp[PCOMPONENTS];       // up to PCOMPONENTS single requests are possible
...
(the rest is unimportant)

is forcing Intellisense to complain wherever a line using the _comp struct is found, like

_comp[inx]._result = 0xE5; // DATA error

resulting in

no operator "[]" matches these operands -- operand types are: struct PushClient::<unnamed> [ uint8_t ]

This effect does vanish occasionally, but most of the time the squiggles and problem messages are there. The code is C+±compliant, of course and compiles just fine. I got some dozens of these lines, so the problem message task window is flooded with the silly messages.

What can I do?

2

In which C++ version? The .vscode/c_cpp_properties.json of your project should say by default

"cppStandard": "c++11",

If your code is C++11 compliant but fails to be recognized errorless in VSCode, please open an issue at the makers of the C++ Intellisense plugin for VSCode, at GitHub - microsoft/vscode-cpptools: Official repository for the Microsoft C/C++ extension for VS Code., with a reproducable minimal example.

3

Yes, the default is set as required:

           "cStandard": "c99",
            "cppStandard": "c++11",

I dug the C++11 references to find a clue and happened to find one:

17.4.3.1.2 Global names [lib.global.names]

Certain sets of names and function signatures are always reserved to the implementation:

  • Each name that contains a double underscore ( __ ) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
  • Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.165
  1. Such names are also reserved in namespace ::std (17.4.3.1).

And indeed when renaming the _comp to just comp the issue seems to be gone.