1

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* s also 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 #includes that 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 either.

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 #include for <string.h>and <cstring> and strlen() is in one of those.

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156
pthien
  • 23
  • 1
  • 8
  • 3
    `` is the correct header to use. If you are ever in doubt as to whether something should compile, try compiling the offending code in a clean environment like [compiler explorer](https://godbolt.org/). In this case, it seems like there may be something wrong with your setup. – Mansoor May 22 '19 at 19:12
  • To make damn sure you're using a proper include and lib path, open a visual studio command prompt via Start menu: Start/Visual Studio 2015/Developer Command Prompt. From there, inspect the INCLUDE and LIB paths; they should be properly fronted by the VC bits. From that command prompt, type `devenv` to launch the GUI, then open your project and try again. If that doesn't work, the project itself probably has overrides to include paths that are breaking your build, and lord only knows how you managed that. – WhozCraig May 22 '19 at 19:19
  • 1
    Would also be worthwhile to double check your project properties (Properties/VC++ Directories/General/Include Directories) and make sure it hasn't lost its inherited include directories (the system ones are `$(VC_Include_Path)` or similar) – ChrisD May 22 '19 at 19:25
  • @Mansoor cool, thanks for the link. I also suspect it is something to do with my setup. that's why i tagged visual-studio. i can't copy the entire file over because it's on a different machine but it seems to work fine on that site. – pthien May 22 '19 at 19:44
  • 1
    @WhozCraig cool didn't know there was a whole command prompt for VS, thanks. ```inspect``` is not recognized in the command prompt so i'm not sure what you mean by inspect their paths or by "VC bits." ```devenv``` works but the project still has issues @ChrisD Include Directories has ```$(VC_Include_Path);$(WindowsSDK_IncludePath);``` – pthien May 22 '19 at 19:49
  • "[Clang IntelliSense]" is unusual. If you have a mix of #include files, some from Clang and others from VS then you will get a lot of complaints. Project > Properties > VC++ Directories > Include Directories might be wrong. – Hans Passant May 22 '19 at 21:06
  • @HansPassant I thought IntelliSense is part of the VisualGDB debugging system that we have but I could be wrong. I typed all the #include statements myself. what do you mean "from" clang or VS? I posted the contents of Include Directoes in the comment above yours. what seems wrong about it? back to the ```include```s, here are all the ones I have: ```#include #include #include #include #include "curl/curl.h" #include "curl/easy.h"``` – pthien May 22 '19 at 21:56

2 Answers2

0

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.

  • sorry, the code is on another machine without internet access so I am not able to copy the code. the double argc is a typo on my part. do you know how I can see what compiler is actually being used? I guess not if you're unfamiliar with VS. i'm not using the command line or anything. I'm just using debugging so I never type ```g++ *.cpp``` or anything like that – pthien May 22 '19 at 20:09
  • No worries! So, when I was referring to the different compilers, it was in response to your saying that you see different compilers invoked, in which case you might've seen an error specific to a compiler. When I use `make`, for instance, I see the different compilation steps listed on the screen. Any error that follows that step, I know that error is associated with that step. Do you see anything like that? If so, that would be the compiler to fix. – madoflancashire May 23 '19 at 02:27
  • I have added part of the output to the main post. the formatting is messed up and I can't edit it for some reason but it's there – pthien May 23 '19 at 16:05
0

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

pthien
  • 23
  • 1
  • 8