I just wrote a simple C++ program in Visual Studio 2010 and I use ceil function. But I forgot to include the <cmath> and only included the <iostream>. Surprisingly my code compiled successfully and ran without any error. I read a C++ book and it clearly says that to use ceil function you must include <cmath> or <math.h>. Why this happens? Can anyone explain me? Thanks!
The header is indirectly included from some other (indirectly) included header.
To find out which one, enable 'keep preprocessed source' (/P) from the project options and inspect the resulting (*.i) file
Update Just found out that VS2010 has renamed the related option:
Technically speaking, implementations are allowed to automatically include any header in the system headers. But this is implementation defined.
In some cases, <cmath> is already included, in other cases, it isn't - same applies to all the other standard headers.
This issue came up on this question: https://stackoverflow.com/questions/7632926/is-this-a-c-program-or-c-program-how-to-decide
That aside, it's possible that it could be indirectly included by other includes.
Related
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)
I am trying to build my code using the Intel C++ Compiler, but for some reason it fails with this error:
catastrophic error: cannot open source file "stdio.h"
In this line #include <stdio.h>.
Any ideas?
stdio.h is a standard header file; it's a bad idea to have a local file of the same name. If you meant to include the standard header, it should be on your include path, and you should include it with
#include <stdio.h>
You should also consider whether you might get more benefit from including <iostream> or including <cstdio> (like including <stdio.h>, but puts the symbols safely into the std namespace).
If you're running on Windows, then installing Visual Studio, then invoking "psxevars.bat" might solve your problem, it solved it for me.
I want to take a peek inside of namespace std but, i'm not able to actually find the file on my computer where it is defined. I tried googling this but, i haven't had much luck.
On most Unix systems, the C++ headers are usually stored in /usr/include/c++/<version>/, where <version> is the GCC/libstdc++ version (i.e. 4.9 or 4.9.2), or else the libc++ version i.e. v1.
Within that directory are all (or just most?) of the standard-mandated headers, which are mostly just ordinary C++ code. For libstdc++, note in particular that most of the older headers just include something in bits/; few of the C++11-specific headers do this.
A list of every thing included in namespace std can be found here.
If you are using Visual Studio you can find it locally here :
~\Microsoft Visual Studio\VC\crt\src
There is also an online representation here.
NOTE : Edit the src files at your own risk, I'd recommend not editing them at all.
Many of the things implemented in the std namespace are templated, which means their entire implementation will be in the header files. For example, std::vector should be in the vector header file. Simply look at the options for your compiler to find out where those header files are located.
There may be some non-templated parent classes and free standing functions, which will not be in the headers. Again, look at the compiler documentation to see if the source files are included somewhere and where they would be.
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.
I'm compiling a project in XCode where MySQL++ in included and linked to. For some reason, I keep getting the following compiler error:
'assert’ was not declared in this scope
originating from cpool.h, a header file that's part of MySQL++. Does anyone know why this is being triggered?
EDIT: For reference, MySQL++ was installed via Macports.
The most obvious answer would be that "assert.h" is not being included or is not being found in your include path. Another explanation is that the assert macro has been undefined at some point after the header was included.
Edit: Since you say that assert.h is included, and we'll assume for the moment that it's being found since it's a standard header, then that leaves us with the last possibility I stated above i.e. that the macro has been undefined.
Since cpool.h itself will not be doing this it must be the case that assert.h is included earlier either by yourself or indirectly by another 3rd party header and the undefining happening between this and your inclusion of cpool.h. This can easily be tested by moving your cpool.h include to the top of your file.
In c++ adding cassert header should fix your problem.
#include <cassert>
It could be that another library in your include path has a different "assert.h" file, and you are unknowingly including that one instead of the system's standard <assert.h>.
I ran into this issue when writing an application that uses gstreamer on Mac OSX. It turns out that gstreamer's include directory (/Library/Frameworks/GStreamer.framework/Headers) includes a file "assert.h", which is non-standard and an unsuitable replacement for the real assert.h. When I added -I/Library/Frameworks/GStreamer.frameworks/Headers to my compilation command, suddenly my sources, which just said "#include <assert.h>" where including the gstreamer version. This caused my compilation to fail with the same error you were getting.