There are many other instances of basic Intellisense errors like this so it’s not just strings that are affected - though they are the most prominent for me.
My understanding is that Intellisense is affected by the Project > Configuration Properties > VC++ Directories > Include Directories settings, which for a default MSFS project is:
Those Intellisense “errors” do not affect compilation so one can live with them, but they are very distracting.
Obviously one could switch off the squiggly lines, but that means genuine Intellisense errors would not be visible - which is not at all helpful either.
Is there some way to get Intellisense to behave more normally in a MSFS Platform, or could we flag this as an error to be resolved in future releases of the SDK?
I do not know if the std::string is usable in Clang, and most of the time, the strings for WASM APIs’ calls are, instead, of types const char[n] (PCSTRINGZ) or const w_tchar[n] (const WCHAR*). Here you can see, from part of my development:
EDIT: Until now that I am reading again on your post. So, you added the std::string vars, but no compilation error, right? And, do you get them right in the sim when you debug the WASM module (i.e., no exceptions, no issues)?
Carlos…Thanks for your reply. I’m aware that most - if not all - ‘string-like’ parameters in SimConnect / WASM use const char*, rather than string. However, I have much more experience with managed code than with Clang or C++, so like to code with what looks more familiar.
The compiler has no problem at all with constructing std::string using conventional C++ declarations. All the examples I gave above compile perfectly OK. It’s just that Intellisense shows them as an error.
I’ve used std::string extensively by preference in my WASM, which runs and behaves exactly as I expect. The only thing I need to do if passing a string to a SimConnect call is to ‘convert’ to const char* by using ‘.c_str()’ - or similar - where needed.
So the compiler is perfectly happy using std::string, but Intellisense grumbles about it, typically that ‘no suitable constructor exists to convert from const char…’.
For fun, try putting those lines of code examples I gave above into your code. You’ll get the red squiggly lines, but they’ll compile perfectly OK, and can be use as one would normally use any std::string anywhere you like in code. So this is an Intellisense problem, not a compiler problem.
So - for me - it’s a livable-with issue, but an inconvenient distraction that I would have hoped could be removed somehow.
Thank you for clarifying me about the use of const char* in the SimConnect API, because I forgot about that.
I had that curiosity and wanted to bring some assistance. Because I am not using the native IntelliSense engine for code checks/highlighting, but instead using a VS plugin called ReSharper C++ from JetBrains, results may vary. I will see if I have that same issue even with the ReSharper code check engine. Anyway, I agree with you that this issue is annoying, considering that the code was correctly written.
Thank you so much anyway for your deep explanation. I appreciate it.
I’m using VS2019 and a recent MSFS SDK and I don’t have any errors with std::string. Indeed this would be quite distracting if so.
I do have tons of Intellisense errors in the list at the bottom (mostly within STL includes like memory), but there aren’t any nuisance warnings causing squiggles, so things work well enough. Maybe there is an issue here with some tool versions and not others.
Dave…thanks for your reply. I’m also using VS 2019 and the latest SDK (0.23.1), so I’d love to know what settings you are using that allow std::string without a squiggly Intellisense error, because I really want them gone! I had the same issue with earlier SDKs too, so it’s not a recent introduction.
To start with, would you mind checking my original post above and letting me know what you’ve got in Project > Configuration Properties > VC++ Directories > Include Directories ?
Out of interest, I tried this in VS2022 (which I dislike) too, but it also flags Intellisense error there on std::string.
I really want to chase this down because it’s bugging me (pardon the pun) so I’d be grateful for any help you or anyone could give.
Visit MSFS SDK\Samples\DevmodeProjects\Misc\StandaloneModule\Sources\Code and open the sample
Open Module.cpp. At the top, add #include <string>
At about line 20 at the top of module_init, add std::string my_string("test");
Set Release configuration
Build All
Observe success (if you moved the sample it will fail on a copy command)
There is a ton of warnings in SimConnect.h because __stdcall is not valid for wasm target, that seems like a separate issue though as it pollutes the output but doesn’t cause a failure.
std::string is fine but I also observe that with this config NULL is underlined as an error even though it compiles. In my project NULL is coming from gauges.h.
Dave - I’d already tried that, but I just followed your instructions to the letter and I still get the squiggly Intellisense error.
So it’s not the project itself, per se - but my guess is that it depends on which particular Visual Studio configuration one has set for C++ in Visual Studio Installer.
I’ve examined those quite carefully, and couldn’t see any clues as to why I might be getting this strange behaviour.
BTW - not sure exactly where your 'NULL’s are getting flagged. Again they probably won’t make any difference (just Intellisense errors) but some might need to be ‘nullptr’ instead, to remove the Intellisense error? That’s definitely the case in the ‘execute_calculator_code’ call.
Carlos - I tried ReSharper some while ago, but stopped using it because it did some things I didn’t like (can’t remember what, exactly, now) and felt it wasn’t worth the monthly or annual subscription for the ‘benefits’ it gave me.
I’ve not found out what’s causing the issue directly, but I’m living with it reluctantly. I don’t understand why more people are not having the same problem, as using std::string is pretty common! I’m experiencing it on 3 separate machines, so am convinced it’s something to do with the way a MSFS project defines std::string rather than the way my setup is defined.
If you go to the ‘string’ document pointed to by a MSFS project, it’s in:
‘C:\MSFS SDK\WASM\wasi-sysroot\include\c++\v1\string’ . That file is completely different than you’d find if you created a ‘default’ C++ project.
Separately, the squiggly line under the ‘NULL’ in your call to Open SimConnect is not a string parameter (it’s a HWND), but you can get rid of it by casting ‘NULL’ to HWND like this :
I’m still digging into this, but it appears this is an issue arising from a number of factors:
It appears the wasi-sysroot (part of the WebAssembly toolchain that MSFS brings in) stopped working with the Microsoft Visual C++ tool chain a bit ago. I filed a bug in the WebAssembly repository:
Visual Studio is running the module sources through MSVC, not clang, on my machine, which then due to the aforementioned error results in red squiggles. This is the part I’m still digging into. MSFS SDK does override CLToolExe to clang-cl.exe. But maybe IntelliSense is taking another path…
Did you any of you figure out a workaround to get Intellisense to work properly with WASM? It’s not just strings, it gets many types wrong, very annoying.
The bottom line is that the LLVM C++ headers brought in by MSFS and the WASI SDK are not supported by Visual C++. And Visual Studio does not have a supported method of changing the IntelliSense mode used by native Visual C++ projects. It’s clear Microsoft and Asobo need to huddle up and figure out a better and working SDK experience moving forward.
But in the short term, here’s a workaround:
Add a header (e.g., hacks.h) to your project with the following contents:
//
// Workaround to get enough Clang-specific syntax through
// IntelliSense running in msvc mode.
// https://devsupport.flightsimulator.com/t/7995/16
//
#define __attribute__(...)
Include this file in your .cpp files where/as needed.
(We’ll probably be adding to this list over time as folks find other APIs that squiggle. Feel free to ping me if you come across any.)
I always use the latest SDK - currently 0.24.3, and the latest VS version(s) VS 2019 Version 16.11.39 or VS2022 Version 17.11.0. I prefer using VS 2019
Since I created this post originally, I had eliminated most areas of code that used std::string (there weren’t that many so it wasn’t a big problem) and I was left with only one specific declaration that still failed IntelliSense validation, but compiled and ran OK. That declaration still shows an IntelliSense error.
I have reinserted the examples that I quoted in my original post that started this thread, and those no longer display squiggles. That said, If I omit your workaround those original examples no longer display squiggles either (!) - so they might have been fixed by a SDK update after I started the thread without my noticing, since I had already removed most std::string usages from my code.
So - my reaction might have been a little hasty, for which I apologize.
However - I still have one std::string declaration that causes an IntelliSense problem that compiles and runs OK, example of which is shown in this screenshot:
Ah, thanks for the additional info. I can reproduce the squiggle with VS2019 + this particular example. In this case, MSVC and Clang have different overload resolution / argument interpretation behaviors here.
(Heads up: When debugging/testing IntelliSense, you may want to close the project and delete the .vs folder (hidden) where it keeps its cache.)
Let’s consider the two basic_string overloads in question:
const char* ptr = ...;
size_t len = 42;
std::string s = std::string(ptr + 123, len);
Clang deduces that (char*)ptr + 123 results in a char*, which matches the first constructor cleanly.
However, MSVC identifies an additional possibility: (char*)ptr + 123 can also be interpreted as a ptrdiff_t, which is a type that matches the second constructor. This leads to the ambiguity and hence the error.
(This would normally be a compile-time error but the MSFS SDK is relying on two compilers here, creating a lot of confusion.)
This one is probably harder to fix without wrappers. I’m still noodling that one.
I recommend going forward, that you make your intent a bit more explicit, as such:
@WithinRafael - thanks very much for your time and effort here. It’s much appreciated.
I suspected there probably isn’t a workaround here, and it’s fortunate that the compiler (whichever takes precedence) doesn’t mind, so runs OK.
…‘I recommend going forward, that you make your intent a bit more explicit…’ . Of course. The code snippet I cited is not anything that’s in my actual code but was only artificially created to show an instance where a squiggle will appear.
. I hope it works for others, though.
