variable has incomplete type std::String; string.h

Question

something is very wrong with strings. I have been using them for weeks without issue, but halfway through Monday, I started having strange issues: [Clang IntelliSense] Error: variable has incomplete type 'std::string' whenever I try to make a string. similar errors occur when I try wstring and ostringstream, but not stringstream. initializing std::string* salso works fine but s->append(...) results in"member has access into incomplete type 'std::string'"

this all came about because visual studio (VS) was all of a sudden unable to find some#includesthat i have had for weeks, including some standard libraries (don't remember which because...). I solved that by having VS search for the correct files and it found some files (unsure if they're the same as before or different) so it no longer has an issue with the#include statements but now I have this issue.

I had been using <string.h> fine for weeks. while researching this issue, i read that <string.h> is the wrong file to use so I've tried #include <string> but there is no difference. I've since tried<strings.h> and <cstring>but no difference there as well.

I checked out my external dependencies and string.h has dozens of errors, which I thought is weird because it's a standard file that I haven't touched.

I'm using VS2015, GNU make, and I see Clang IntelliSense but I also see some g++ here so i'm not sure what compiler it's actually using. also using visualGDB 5.3. let me know if I forgot anything.

#include <iostream>
#include <string>
#include <sstream>
int main(int argc, char *argv[])
{
std::string message = "uncomment";
...

message

is the part that is highlighted as having an issue (incomplete type)

std::wstring wideMessage;

also incomplete type

expected results: no problems like the past few weeks. i was able to declare, initialize, append(), whatever actual results: can't compile/debug errors: variable has incomplete type 'std::string' variable has incomplete type 'std::wstring' no matching constructor for initialization of 'std::ostringstream'

I see many similar issues here, but all the issues have to do with forward declaration and I don't see what that has to do with this. I'm not having any issues with classes, structs, or functions; even declaring a variable in main() is problematic

edit: based on this answer, it is likely using VC++ 14.0 as a compiler but I do not know how to tell for sure

edit 2: error message:

1>  VisualGDB: Sending 45 updated source files to build machine...
1>  VisualGDB: Run "make  CONFIG=Debug" in directory "/tmp/VisualGDB/c/Users/pthien/VS/Whatever/Whatever" on pthien@buildserver (SSH)
1>  /opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi -ggdb -ffunction-sections -O0 -std=c++11 -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi -ggdb -ffunction-sections -O0 -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include -I/opt/googletest-master/googletest/include -I/opt/boost_1_61_0 -I../../cereal/cereal-1.2.2/cereal-1.2.2/include -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/websocketpp-master -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/websocketpp -I/opt/curl-7.54.0 -I/opt/boost_1_61_0/boost -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/easywsclient-master -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/uWebSockets-master -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.2/experimental -I/opt/boost_1_61_0/boost/tr1/tr1 -I/opt/boost_1_61_0/tools/build/src/engine -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.2 -I/opt/curl-7.54.0/include -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/cereal -I/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/include-fixed -I/opt/boost_1_61_0/boost/compatibility/cpp_c_headers -I"../../../../../Program -IFiles -I(x86)/Microsoft -IVisual -IStudio -I10.0/VC/crt/src" -I"../../../../../Program -IFiles -I(x86)/Microsoft -IVisual -IStudio -I14.0/VC/include" -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.2/arm-poky-linux-gnueabi -DDEBUG  -c Whatever.cpp -o Debug/Whatever.o -MD -MF Debug/Whatever.dep
1>  C:\Users\pthien\AppData\Local\VisualGDB\RemoteSourceCache\buildserver\0008\include\wchar.h(459,20): note :    'wcstold'
1>   extern long double wcstold (const wchar_t *__restrict __nptr,
1>                      ^
1>  Whatever.cpp: In function 'int main(int, char**)':
1>C:\Users\pthien\VS\Whatever\Whatever\Whatever.cpp(138,47): error : 'strlen' was not declared in this scope
1>     size_t request_len = strlen(webSocketRequest);
1>                                                 ^
1>  Makefile:160: recipe for target 'Debug/Whatever.o' failed
1>  make: *** [Debug/Whatever.o] Error 1
1>  -------------------------------------------------------------
1>  Command exited with code 2
1>  Executable: make
1>  Arguments:  CONFIG=Debug
1>  Directory: /tmp/VisualGDB/c/Users/pthien/VS/Whatever/Whatever
1>VisualGDB : error : Command-line action failed
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets(37,5): error MSB3073: The command ""C:\Program Files (x86)\Sysprogs\VisualGDB\\VisualGDB.exe" /build "C:\Users\pthien\VS\Whatever\Whatever\Whatever.vcxproj" "/solution:C:\Users\pthien\VS\Whatever\Whatever.sln"  "/config:Debug" "/platform:Win32"" exited with code 1.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

this is about 10% of the output, including the beginning and the end. what's weird is the issue with strlen(). it is not underlined in the IDE so I had no idea there was an issue with it. it makes sense because i commented out the #includefor <string.h>and <cstring> and strlen() is in one of those.

Answer 1

managed to avoid this issue, but probably not solve the still-unknown underlying issue, by removing an unused library from my list of directories and then reloading all directories. I'm not convinced anything was solved because reloading directories gives random results. sometimes it fixes issues and sometimes it causes new ones. Just yesterday, I reloaded and it was then unable to find system.h and time.h (don't remember the names). I was troubleshooting that but the issue disappeared a few hours later. anyway I posted a follow-up question here

Answer 2

If you copied your code exactly from what you have, I see two declarations of argc in your definition of main. Your compiler should definitely be throwing errors about that. Perhaps your compiler delays the read error until you declare a std::string in main? (I've had a compiler throw an error several lines after the actual error for something seemingly unrelated.) So, you may have fixed the error in having a bad file path, but perhaps your bad definition of main throws your compiler off.

Now, if that didn't work, you mentioned seeing a bunch of compilers being used. If you see a particular compiler throwing that error, then you might want to separately update said compiler. The functionality of compilers is modular, so you can pick and choose which compiler you use for which step of the compilation. VS is probably doing this to get what it figures is the best result. Sometimes compilers carry with them the files they want to use, thus updating (or even un/reinstalling) the compiler should fix the files that it carries with it. (Windows likes to do everything for you, so you might actually mess something up if you try to update the parts separately. That was always my experience, anyway. But, I haven't used Windows in well over a year, so that may have changed.)

If that still doesn't fix it, you may have to un/reinstall VS. I will admit to knowing nothing about VS, as I use Emacs to edit and Makefile/g++ to compile. My guess, however, is VS may carry all the compilers and files it needs with it, so an update or un/reinstall will (hopefully) fix your issue.