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.
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.
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
Related
Reviewing material for an optimized C++ course next quarter. The professor for this course is enforcing /WALL and /WX for our project properties. The problem I'm having is that including the Iostream library produces over 800 warnings. Here's the code I'm attempting to run:
#include "pch.h"
#include <iostream>
int main() {
std::cout << "Hello World";
return(0);
}
A few of the warnings that I'm receiving includes:
C4514 'abs': unreferenced inline function has been removed
C4774 'sprintf_s': format string in argument 3 is not a string literal
C4820 'std::basic_ios ...': '7' bytes of padding added after...
Before asking Stack I emailed the Prof to ask about the warnings and was told:
You should be including iostream
If you get 100 warnings you included a header that's not needed
Is there something I'm missing? I know I wouldn't be able to edit source files for iostream as that's not portable coding. I looked around to see if I could explicitly include functions such as cout, cin, etc. Yet, I don't feel like this is the correct solution.
Edit:
A user requested an example of a more explicit warning message in case there was something missing in there. Here are a few:
C415 'abs': referenced inline function has been removed (Project: Hello World) (File: stdlib.h)
C4710 'int sprintf_s(char *const....: function not inlined. (Project: Hello World) (File: stdio.h)
The professor is using GCC through Visual Studio and our settings are pulled from a repository as premade projects.
Your professor is, quite simply, wrong.
This has nothing to do with "including a header that's not needed" (why would that generate warnings?), but with using /WALL, which reveals some flaws in the stdlib implementation there!
This switch is not recommended; quoting James McNellis who gets it bang-on under the above referenced question:
/Wall enables many warnings that, while potentially useful sometimes, are not useful most of the time. /Wall in Visual C++ does not mean the same thing as -Wall on g++ (really, g++ "has /Wall wrong," since it doesn't actually enable all warnings). In any case, in Visual C++, all of the commonly important and useful warnings are enabled by /W4.
I would use /W4 in Visual Studio (and -Wall -Wextra in GCC).
Obviously I can't help you to persuade your professor of this, other than to suggest saying something along the lines of "I asked on Stack Overflow and found out that this is due to /Wall being too strict and generating warnings on Visual Studio's own headers. They suggest we use /W4 instead. . What do you think?"
It is true that you need to #include <iostream>, and it is true that you should never modify the provided standard headers. Also, don't forget to stream a '\n' to end your output line!
I am using clang-tidy as a "linter" tool in development. I started to integrate 3rd party software into my code and when I include their header files using:
-I/path/to/include
tons of errors are generated, I haven't even #include the headers yet.
error: too many errors emitted, stopping now [clang-diagnostic-error]
...
/path/to/include/wchar.h:81:1: error: unknown type name 'wint_t' [clang-diagnostic-error]
wint_t fgetwc(FILE *__stream);
^
/path/to/include/wchar.h:81:15: error: unknown type name 'FILE' [clang-diagnostic-error]
wint_t fgetwc(FILE *__stream);
^
...
I compile my program using:
/usr/bin/clang-tidy-4.0 /path/to/main.cpp -checks=-*,cppcoreguidelines* -- -lang-c++ -I/path/to/include -std=gnu++11 -Wall -Werror -O0 -g -D<define variables>
It seems that these "clang-diagnostic-errors" do not stop compilation, as it continues to compile and runs fine. Is there a flag to turn this error off/suppress it? I do not want to see it since I did not write these header files.
If I get rid of the argument -I/path/to/include everything compiles fine with no errors.
There is no way to ignore clang-diagnostic-error since it's basically a compiler error.
For clang-tidy to work the analyzed code needs to be compile-able by the clang backend to generate an AST(Abstract syntax tree).
The problem is you are including headers that cannot be compiled by clang (I'm guessing windows headers intended for MSVC).
I'm not sure if this would not break something later, so just at your own risk. I managed to "solve" this (because it was just a matter of having an error on the Problems list) on VSCode:
"C_Cpp.codeAnalysis.clangTidy.args": [
"--extra-arg=-ferror-limit=1"
]
This makes clang-tidy tell the compiler to throw just one error and give up. So clang-tidy will parse whatever is left.
I know was for VSCode, but the argument can be used in other IDEs.
I am using VS 2017 Community edition, Intel Compiler 17.00 update 6 and and boost 1.66, trying to learn my way around boost::multiprecision::float128. Literally taking the example code from here and putting it in a new project for VS.
Compiling gives multiple errors, in roughly two categories/files:
In float128.hpp:
three errors of "error : identifier "xxx" is undefined" for fmaq, remquoq and remainderq. Indeed I am not able to find definitions for them - a missing include?
the global scope has no "signbitq" - this again looks like missing definition (i.e. the same as above)
For GCC the above functions are found within quadmath.h, however, the boost header doesn't seem to include it when using ICC (i.e BOOST_MP_USE_QUAD is set).
In C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\xutility: an explicit template argument list is not allowed on this declaration. There are three counts
I assume that i need to remove something that has been put in by default from the VS, but I am at a loss what exactly.
Thank you for your help
EDIT: Errors #2 above are actually not against boost at all (should I move this to a separate question?).
The following code copied from here! is not being compiled in my setup:
#include <iostream>
#include <string>
int main() {
std::string str("Test string");
for (std::string::iterator it = str.begin(); it != str.end(); ++it)
std::cout << *it;
std::cout << '\n';
return 0;
}
The exact error (one of them) is:
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\xutility(680): error : an explicit template argument list is not allowed on this declaration
1> _INLINE_VAR constexpr bool _Is_iterator_v<_Ty, void_t<_Iter_cat_t<_Ty>>> = true;
1> ^
1> detected during:
1> instantiation of "const bool std::_Is_iterator_v [with _Ty=char *, <unnamed>=void]" at line 520 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"
1> instantiation of "std::basic_string<_Elem, std::char_traits<_Elem>, std::allocator<_Elem>> std::_Integral_to_string<_Elem,_Ty>(_Ty) [with _Elem=char, _Ty=int]" at line 554 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"
I found this which indicates that there could be a problem with the particular versions used (ICC- 17.0 Up6 and VS 15.6), however i cannot really move to new intel compiler and i cannot test VS 15.4
I would like to write down how I managed to deal with error #2 from the original question, as it might be useful to someone.
Just as a reminder, the second errors I was seeing were in xutility. With the help of everyone that provided suggestions, it turned out that icc was in fact failing on very simple code - the following is enough to "break" it
int main() {
std::string str("Test string");
}
I have posted the question to intel's forums, however so far I have not received answers (for the 17.0 version of the compiler). Link here if anyone is interested.
That said, I came upon this blog post from the VC++ team, showing that the base toolset shown as v141 in VC2017 actually has had several minor revisions. It is possible to change the version of the MSVC toolchain but this needs to happen via editing of project files (rather than UI parameter changes).
My testing shows that version 14.11 (which is part of VS2017 15.3 and 15.4) works for Intel 17.0 while versions 14.12 and 14.13 (the last one is the current default for VS2017 15.6.4) do not. This has been done for Update 6 of the compiler. So in order to use the intel compiler on windows with visual studio, one needs to use particular MSVC toolchain versions.
Side note: I also installed icc version 18.0 update 1 for testing -- it too was giving compiler errors (and not just for me this time). The reason there though can be linked to some internal issue for icc, per this forum post. I can confirm that removing the compiler option /permissive- from the compiler fixes the errors irrespective of the base toolchain. Using v14.11 as base toolchain also fixes this particular problem for me with or without the option. /permissive- is a new option for icc (it is not part of 17.0).
The above solves more or less the second part of my problem with the icc. The rest of the question (boost's float128) though still remains. I will add more if i hear from boost's guys.
EDIT: the errors coming from boost turned out to be an issue there -- it was fixed by the maintainers in development branch, so this is resolved as well.
For Error #1, I got the same thing. However, after commenting the code blocks in boost float128.hpp where those four functions invoked, the float128 example code can be compiled with success. The side effect is unknown. I'm looking forward a revision on boost::multiprecision::float128.
I have two short files located in the same directory. The contents of each are shown below.
File test.cpp contains:
int main()
{
#include <test.h>
}
File test.h contains:
syntax_error
Upon compiling test.cpp with either g++ or clang++, I get an error which is expected.
test.cpp:3:11: error: 'test.h' file not found with <angled> include; use
"quotes" instead
#include <test.h>
^~~~~~~~
"test.h"
However, I also get a second error which seems to contradict the first error.
In file included from test.cpp:3:
./test.h:1:1: error: use of undeclared identifier 'syntax_error'
syntax_error
^
Essentially, the first error reports that the compiler cannot find the file test.h, and the second reports a syntax error in the file that the compiler reported it could not find.
These are the only two errors generated.
I understand why the compiler reports the first error and that I should use quotes with #include in this case. Why, though, does the compiler say it cannot find the file when it clearly has found it? And, why would it continue to report errors in the "unfound" file?
This is a feature, not a bug.
The idea is that if the error is trivial (like a missing semicolon), then the compiler will try to continue compiling as if you had already fixed the error. This enables you to fix multiple errors in one go. This is especially useful when compiling your code takes a long time.
Imagine fixing a missing semicolon, recompiling for five hours, just so that the compiler finds another missing semicolon. And then you have to recompile again. That would be very frustrating, no?
Basically, the compiler will try to recover from any errors as far as it is able to, to be able to report as much errors as possible. Most compilers have a flag for this.
Why, though, does the compiler say it cannot find the file when it clearly has found it?
The compiler found the file yes, that's why it gave you a hint to use "" instead of <>. If it hadn't, it might not have given you the hint. Still, the compiler is not allowed to compile your code correctly, because your code is ill-formed.
As an analogy, just because the compiler found a missing semicolon, that doesn't mean that it can just compile the code with that missing character (if it tries to be Standards compliant). It will however recover and try to find other errors, if any.
I have download the A C++ Implementation of Hidden Markov Model written by Dekang Lin, but I caught a error when I type make in src directory.
Thanks #Michael, this problem solved.
In tables.cpp, add #include <cstdlib>.
In genseq.cpp and trainhmm.cpp, add #include <stdlib.h>.
Error info:
g++ -c -o tables.o -g tables.cpp
tables.cpp: In member function 'bool OneDTable::rand(long unsigned int&)':
tables.cpp:155:24: error: '::rand' has not been declared
tables.cpp:155:34: error: 'RAND_MAX' was not declared in this scope
make: *** [tables.o] Error 1
You shouldn't be calling your compiler yourself. That project contains a Makefile, so run make and better fix what's broken in the Makefile and sources than try to individually build .os yourself. But:
Probably that table.cpp is missing the #include line where the header would have been included where OneDTable::rand(..) would have been declared. Also, missing ::rand indicates that there are missing standard library includes. This doesn't shine a great light on the integrity of that source code. Maybe, just maybe, as a C++ beginner, you don't want to start off with broken C++ that's 12 years old.
If you're not overly set on pure C++, you can use gHMM, which is much more mature (and written in C, so works flawlessly in C++, but isn't as much object-oriented). Also, HMMlib looks pretty nice.