Please tell me why this code is compiled with C++11 standard:
#include <iostream>
using namespace std;
int main()
{
abs(-12);
exit(1);
return 0;
}
it is without error g++ -std=++11 main.cpp
this error g++ main.cpp
if you remove #include <iostream> then get the error on exit() and abs() when the program is compiled.
Tell me why this happens, if I don't include <cstdlib>? And how to do that would compile with -std=c++11 was a warning or error?
The answer is really simple: the code compiles because under C++11 your iostream lib includes other libraries that have exit() and abs() defined. You won't get a warning or error for that. Why would you? After all cascade includes are supported.
However you should not depend on that since that's not a part of the standard and may break under different compiler. But I guess that as long as you stick to one compiler and one -std flag you're fine. Also fixing this by adding some includes should not be a big deal as well.
Related
I am trying to compile an application from source, FlyWithLua, which includes the sol2 library.
I am following the instructions but when I run cmake --build ./build I get the following error:
In file included from /home/jon/src/FlyWithLua/src/FloatingWindows
/FLWIntegration.cpp:10:
/home/jon/src/FlyWithLua/src/third_party/sol2/./upstream/sol.hpp: In lambda function:
/home/jon/src/FlyWithLua/src/third_party/sol2/./upstream/sol.hpp:7194:59:
error: ‘numeric_limits’ is not a member of ‘std’
7194 | std::size_t space = (std::numeric_limits<std::size_t>::max)();
There are several other errors on the same line after this, but I guess they might just go away if I can solve this one.
there are several similar issues with the solution to add the following includes to the .hpp file
#include <stdexcept>
#include <limits>
the sol.hpp file includes the following imports:
#include <stddef.h>
#include <limits.h>
https://sol2.readthedocs.io/en/latest/errors.html gives some hints about the why the compiler might not recognize these includes:
Compiler Errors / Warnings
A myriad of compiler errors can occur when something goes wrong. Here
is some basic advice about working with these types:
If there are a myriad of errors relating to std::index_sequence, type traits,
and other std:: members, it is likely you have not turned on your C++14 switch for
your compiler. Visual Studio 2015 turns these on by default, but g++ and clang++
do not have them as defaults and you should pass the flag --std=c++1y or
--std=c++14, or similar for your compiler.
the src/CMakeList.txt file has the following line:
set(CMAKE_CXX_STANDARD 17)
I'm only faintly familiar with C/C++ and this all seems very complicated to me, but I'm hoping that there might be an easily recognizable cause and solution to this to someone more skilled.
cat /etc/*-release gives
DISTRIB_RELEASE=21.10
DISTRIB_CODENAME=impish
DISTRIB_DESCRIPTION="Ubuntu 21.10"
$ g++ --version
g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
/home/jon/src/FlyWithLua/src/third_party/sol2/./upstream/sol.hpp:7194:59:
error: ‘numeric_limits’ is not a member of ‘std’
7194 | std::size_t space = (std::numeric_limits<std::size_t>::max)();
This error message implies that src/third_party/sol2/./upstream/sol.hpp header uses std::numeric_limits, but also that std::numeric_limits hasn't been defined. The simplest explanation for that is that the header that defines std::numeric_limits hasn't been included. In such case, the solution is to include the header that defines std::numeric_limits.
the sol.hpp file includes the following imports:
#include <stddef.h>
#include <limits.h>
This confirms the problem. Neither of those headers define std::numeric_limits.
https://sol2.readthedocs.io/en/latest/errors.html gives some hints about the why the compiler might not recognize these includes:
Those hints may apply to some other cases, but not this one. std::numeric_limits has been part of the C++ standard since the beginning, so language version has no effect on its existence.
Conclusion: According to the quoted error message, sol.hpp uses std::numeric_limits which is defined in the header <limits>, but according to you, it doesn't include that header. If this is the case, then this is a bug in the sol.hpp file. Correct solution would be to fix the sol.hpp file by including <limits> in that file before using std::numeric_limits.
This snippet can not be compiled, since std::accumulate is found in the header numeric, which is not included.
#include <algorithm>
#include <vector>
int main () {
std::vector<int> vec{ 1, 2, 3, 4 };
return std::accumulate(vec.begin(), vec.end(),0);
}
The compiler explorer gives me the correct error message
<source>(6): error: namespace "std" has no member "accumulate"
return std::accumulate(vec.begin(), vec.end(),0);
I am using RedHat 6 and the intel compiler version 18.0.3. If I compile it with this setting, I get no error and the result is fine. No warning is shown, even if -Wall is used.
My question is, why don't I get an appropriate error message?
why don't I get an appropriate error message?
Because one of the standard library headers <algorithm> or <vector> that you use for compilation do include <numeric> themselves. This is a common portability issue; your code happens to compile with a particular standard library implementation, but fails to build with another one. Library implementations are free to include standard headers in standard headers. Maybe some functionality in your <algorithm> was implemented using any of the <numeric> algorithms, and there you are.
The compiler error you encounter is the reason tools like include-what-you-use exist. Using iwyu her would add #include <numeric> to your snippet. Note also that no warning flags will influence the result of the compilation. Either you get a hard compiler error or nothing.
I want to use the std::move function in <utility>. So I put an include for this at the top of my code along with all the others. However, when I use the move function eclipse underlines it as red and it won't compile. I know I am using c++ 11 since I can declare move constructors however, this won't work. I am using GCC to compile and I used the -std=c++11 option. I also put this in my linker. Before that #include <utility> would not show up. Do I need to include something else?
Here is the basic prolbem. std::move(...) does not seem to be defined.
#include <utility>
#include <vector>
int main()
{
std::vector<int> v1;
std::vector<int> v2;
v1 = std::move(v2); // Function move could not be resolved.
return 0;
}
Also here are the options I have set on my compiler -O3 -g3 -Wall -c -fmessage-length=0 -std=c++11
Your code is OK. But you should update your gcc to newest version. Gcc 4.7.2 don't have everything implemented from c++11 standard.
Are you sure is not defined? Perhaps your error is at linking time cause the linker cannot find the library?
Whether the case, you have to add library paths to your eclipse project settings as well as include paths.
I've compiled your example and after executing ldd on the generated binary I can see there are linking dependences, I hope this help:
Say you've got the following simple main.cpp file:
#include <cstdlib>
#include <iostream>
#include <fstream>
using namespace std;
int main() {
const string FILENAME = "foo.txt";
ifstream somefile(FILENAME);
populations.close();
return 0;
}
This compiles fine via Visual Studio C++ 2010.
However, on a Linux-based system, if I execute make main and compile, we get an expected error since we didn't call c_str() on the string constant, like so:
ifstream somefile(FILENAME.c_str());
As is commonly known, and described in this SO thread.
How can I get VS to behave like gcc/g++ and raise a compilation error for the code above? Or, how can I get gcc/g++ to behave like VS and compile the above without error? (Is it a simple matter of upgrading my gnu compiler?)
(I don't believe disabling compiler extensions is a solution, as I've done this and it still compiles without error.)
Visual Studio behaves correctly in this case with respect to the C++11 standard (it works on g++ now, too). I'm not sure why would you want to do this, but you'll probably need to edit MSVC's headers (not advisable and rather drastic).
Strange thing is though, that they don't write it in their documentation. Can you check which constructor is actually being called?
It is available as part of the newer c++ standard.
To disable, add
#define _HAS_CPP0X 0
at the top before your includes.
I have the following very simple application that compiles and runs fine:
EDIT: changed the example to be simpilar to end confusion of the real issue
int main() {
return 0;
}
As soon as I add #include <string> (and not even reference std::string), it fails to compile and I get the following error:
/usr/include/c++/4.1.2/bits/allocator.h:82 error: expected template-name before '<' token
Along with about 456 other, similar errors.
Any ideas? Thanks!
UPDATE:
Line 82 of /usr/include/c++/4.1.2/bits/allocator.h references the template __glibcxx_base_allocator at the location of the error. That template is defined in bits/c++allocator.h. When I search the system for that file, I get 3 hits, but none of them are in /usr/include/c++/4.1.2/bits/ as one would expect.
I have version 3.1.6, 4.1.1, and 4.3.2, but not 4.1.2 as the rest of the includes I am using. I am not sure which one is being used (if any, however, I don't get any error for an unknown file), but it seems the problem may stem from this.
The problem appears to be the installed development packages are not correct or incomplete (not to be confused with corrupt). Forcing g++ to use different include versions corrects that:
g++ -nostdic++ hello.cc -o hello -I/usr/include/c++/3.4.6
All the alternative directories (4.1.1, 4.1.2 and 4.3.2) are incomplete causing inappropriate files to be included causing the unusually errors. For example:
/usr/include/c++/4.1.2/bits/allocator.h requires __glibcxx_base_allocator located in bits/c++allocator.h which is being included from either /usr/include/c++/4.1.1 or /usr/include/c++/4.3.2 and appear to be incompatible. Forcing the compiler to use the only complete set of includes rectifies this.
Almost certainly g++ is detecting .cc as a C source file, not C++ and passes it through to gcc instead of compiling as C++. You can easily test by renaming your file to hello.C. There's also a language parameter to g++ you can use.
EDIT: This seems to work fine in g++ 4.2 with a .cc extension so that might not be it. Do you have any other headers included you aren't showing us? They could be interfering with <string>.
EDIT2: Alternatively your headers might not be set up right. Does this work:
#include <string>
int main()
{
return 0;
}
Errors like this have been heard of to occur when the C++ standard library headers are corrupted/not fully installed – maybe there is even a message referring to a missing include among your 456 other errors.
In any case, make sure that libstdc++-devel, resp. the package containing the C++ standard library header files of your distribution, is properly installed.
Check your include path. The paths can be specified as environment variables or specified on the command line. You could be using an include file from a different compiler or different version of the same compiler.
Also, try using <cstdio> rather than <stdio.h>.
Another suggestion: change <> to "".
This could be error caused at preprocess stage. Just preprocess your cpp file by passing flag -E to gcc and Look at the place the compiler complains.