strtoull,strtof,strtold,vsnprintf,wcstoll,wcstoull,wcstof, and wcstold are not members of 'std.' The problem is I don't use any of these functions. I didn't even know they existed. they are in file basic_string.h, which I also didn't know I was using. I'm using VS2015 so I assume I am compiling using the VSC++ 14.0 compiler.
I see that there over a dozen similar questions but I can only find two common errors: not using the C++11 flag and not #includeing . I have had the C++11 flag set and #include <algorithm> changes nothing. this question makes me curious,though. I thought the order of #includes didn't matter. I tried system libraries <> first and 3rd party libraries second "" and also vice-versa and observed no difference.
I also tried #include "stdafx.h" as some other answers indicated, but no such file exists.
not sure what to include here because I finally got to the point where the IDE identifies no errors in my code. again, all the issues are in "basic_string.h." here are my includes:
#include <iostrream>
#include <string>
#include <cstring>
#include <sstream>
#include <map>
#include "curl/curl.h"
#include "curl/easy.h"
this may be a continuation of my other question here, which I will update now.
edit 1: I have included <cstdlib>,<cstdio>,and<cwchar> and I see no difference. I'm curious why it's having issues with functions I've never used in files I've never touched.
I totally forgot I ran a repair on VS2015 yesterday and here are the results. I'm not sure if these are optional modules or core issues or what. "Windows Software Development Kit" sounds important but I am not developing for a windows machine(though I am developing on Win7).
edit 2: someone asked for minimal reproducible code. here is the whole file sans comments:
#include <iostream>
#include <string>
#include <cstring>
#include <cstdlib>
#include <sstream>
#include <map>
#include <cstdio>
#include <cwchar>
int main(int argc, char *argv[])
{
return 0;
}
just realized I don't need all the includes for nothing(because i commented all functional code out) so I will now see which one is causing the issue.
edit 3 : cstring,cstdlib,cstdio, cwchar, and the two curl headers are the only headers that will not cause this issue. I can include all six of them at once without issue. any other #include that was mentioned in the OP or the previous edit will cause the same ...is not a member of 'std'error. However, I don't think I had any of the <c...>included before I started having this issue.iostream,string,sstream,map each (individually even) cause this issue. are we still looking at a complete VS2015 reinstall?
edit 4: As one user suggested, I tried to make a new project but this is what happened. I was really hoping we wouldnt get to this point because I'm not sure how much you all will be able to help. Basically,we have some complicated build setup which I don't understand. The other guy who works here also does not understand the setup. The one person who knows is out on paternity leave. I'm developing on one machine and building/debugging on a server. However, I was poking around the settings and I saw a different diagram that has a second server in the mix and I'm not sure how that plays into it. After that, it is deployed to a different machine. Anyway I selected the same options as the current project but I can't even create a blank one. I'm not sure if this failure is because of this complicated system or because my VS2015 is messed up. Either way I can't fix this as it is so I think I will work on repairing VS2015 (which already had issues once) while monitoring this thread to see if this new project error reveals something important. thanks a lot to all who helped so far
edit 5: I'm taking next week off. I won't be able to give any updates till the 3rd for anybody who still cares. I'm going to repair and then reinstall
Those functions are in the namespace std if you include the correct standard headers, which are <cstdlib>, <cstdio> and <cwchar>. "basic_string.h" is not a standard header; it is probably some implementation specific header. "stdafx.h" is what Visual Studio uses for precompiled headers (it's not in the standard either) and the order in which you include headers can matter although it usually shouldn't.
I see that there over a dozen similar questions but I can only find... not #includeing
That appears to be the problem.
In order to use standard functions, the header which declares those functions must be included. The listed functions cannot be used because the corresponding headers haven't been included.
For example, strtoull is declared in <cstdlib>, which has't been included according to your quoted list of includes.
The problem is I don't use any of these functions. I didn't even know they existed. they are in file basic_string.h
If the error indicates that basic_string.h uses those functions, and that's the list of headers that basic_string.h includes, then basic_string.h is buggy.
I'm curious why it's having issues with functions I've never used in files I've never touched.
You either use basic_string.h, or you use some header that in trurn uses basic_string.h. The error message should tell you how the inclusion takes place.
I have ... #include <algorithm>
Including <algorithm> lets you use the declarations from that header. It doesn't let you use declarations from other headers.
I also tried #include "stdafx.h" as some other answers indicated, but no such file exists.
If your project is configured to use pre-compiled "stdafx.h", then you must include it. If it is not configured to use it, then you must not include it. Pre-compiled headers must be included before anything else in your file.
it was a problem with my Include directories in VisualGDB Properties-->Makefile settings. I was adding a new directory for each library I got. I reinstalled VS2015, but that did nothing because the culprit was a project option. I copied the default* include directories and that was it.
*someone on my team provided me with a list of the default include directories
Related
Mycode
Why is #include "string.h" greyed out and does it still include it even though its greyed out. This is the only CPP source file in my project and so I know I'm not including it in another file. My TA said that its probably using the CPP version of string but later in the course it'll be a problem because we need to use the "string.h" version of string so I'd like to make sure its still including "string.h" even though its grey.
It’s greyed out if clion detects that you aren’t directly using something from the referenced header.
It isn’t always correct in it’s detection process.
In this case, it is. There is a difference between string.h and <string> as an include.
I am testing with a simple test program right now. It looks like below:
#include <iostream>
using namespace std;
int main() {
string s = "a b c d ";
remove(s.begin(),s.end(),' ');
}
When i build it with visual studio, it builds correctly and does not give any error. However if i try to build it with eclipse (mingw), it complains about the functions 'remove', as it should because the corresponding header is not included.
Is there a way to configure visual studio such that it will also complain and not auto-include headers or whatever fancy thing it is doing? I have already checked by disabling the option to use pre-compiled headers in visual studio project properties, and that doesn't help.
When you write a program that fails to include the proper headers, some toolchains may still just so happen to successfully build your program, because maybe their <iostream> happens to ultimately include the header you need (like <algorithm>).
That doesn't change the fact that your code is wrong. You're getting a build by chance.
You don't configure another toolchain to do that. You fix your code to include the correct headers.
So:
#include <string>
#include <algorithm>
The C++ Standard does not define, that a certain file needs to be included for the contained definitions to be able to be used.
It only defines in which files the specific functions are defined.
So if the specific implementation which You use includes everything through a file and You don't need to include anything else, than that is still allowed by the Standard.
So in one implementation, everything will compile, while in another errors will appear.
This is not controlled by the C++ Standard.
What You can do is file a bug to the implementors, and see if they agree that it's a bug. (In this case: https://github.com/microsoft/stl/issues)
Short question
How should I deal with needing different includes on different distributions?
More details
In some C++ code, I am including ioctl like this:
#include <sys/ioctl.h>
And from that I use different things, including TCSETS2. Following the includes of sys/ioctl.h on Arch Linux, I found that TCSETS2 is defined in asm-generic/ioctls.h. So far so good.
Now, when building on Alpine Linux, it complains about TCSETS2:
error: 'TCSETS2' was not declared in this scope
Looking at the includes again, TCSETS2 is also defined in asm-generic/ioctls.h. However, this time sys/ioctl.h does not end up including generic/ioctls.h.
How should I deal with that? Should I include both, hoping that it does not break the compilation on some distributions? Something like below?
#include <asm-generic/ioctls.h>
#include <sys/ioctl.h>
Or is it bad practice?
TCSETS2 is undocumented here
suggesting that it's an implementation specific feature. From the comments, switching to TCSETS which is in the documentation resolved the issue.
It seems that the compilers usually implement #include "path/file.h" by firstly searching a path relative to the currently processed source file folder.
So the question is: how does it influence in practice the compilation time when using #include with quotes versus triangular brackets?
The question is only for the case when the "path/to/file/filename.h" is a relative path to the currently processed header, because otherwise it would behave similar to #include <…>.
It seems that the correctly set #include "…" should be faster for your own files than #include <…> in a large project (500 files or more).
Edit: Other questions about difference between #include "…" and #include <…> don't seem address compile time. Also, the standard is vague but most compilers do use "…" to search in the current folder first.
Edit2 Reworded the title and the question. I'll accept the answer for any of these C++ compilers: Visual Studio, Intel, Clang, Gcc.
I have including problems in a C++ Project. I included math.h, but there are strange problems with my vector.h and my matrix.h header files. Am I allowed to call these files vector.h and matrix.h?
Two headers cannot have the same name.
By same name, the full path name is implied, so
#inlcude "testClass.h"
#include "heders/testClass.h" // OK, distinguishable
Visual studio prevents you from adding a header having a name that already exists in the project.
You should also check that your header is actually included in your project (or through your Makefile, build system etc). A quick check would be to cause a syntactic error in that header and see if it breaks the build
So to get back to your question, do you already have headers called vector.h and matrix.h? Cause that would be the only thing preventing you from naming new headers like that.
Keep in mind that headers accessed with #include <...> require their folder to be set as an include (external) directory so qualifying up to that path won't work
In theory I don't know of anything to prohibit doing so.
I'd consider vector.h close enough to <vector> that using it would be a poor idea.
I'm not exactly excited about matrix.h either, but at least it's not nearly so obviously a poor choice.
Of course, for any header you wrote yourself (rather than one provided by the tools you're using) you want to enclose the name in quotes, not angle brackets.
The rationale why C++ chose the unusual <vector> format without suffix is because the intent was to remain compatbile with existing C code which might very well have "vector.h". So the answer is yes, by design.