‘numeric_limits’ is not a member of ‘std’ - c++

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.

Related

error: strstream.h: No such file or directory

I am trying to run an old C++ code in Linux (Redhat). I am using gcc version 4.1.2.
I got the following error:
error: strstream.h: No such file or directory
/trnuser1/rmtrain/DevelopmentEnv/Generic/CoreObjects/GCVTransformationServices.cpp:41: error: âostrstreamâ was not declared in this scope
/trnuser1/rmtrain/DevelopmentEnv/Generic/CoreObjects/GCVTransformationServices.cpp:41: error: expected `;' before âstrDestXMLâ
/trnuser1/rmtrain/DevelopmentEnv/Generic/CoreObjects/GCVTransformationServices.cpp:62: error: âstrDestXMLâ was not declared in this scope
This code was running fine under Solaris with gcc version 2.95. The line pointed to by the error contains the following statement:
ostrstream strDestXML;
How do I solve this?
You can #include <strstream> (note absence of the '.h' suffix).
But if you want to properly port the code to modern C++, you should consider changing this to #include <sstream> and std::ostringstream strDestXML; as suggested in the comment.
Standard C++ headers do not have extension.
#include <sstream>
Standard classes are contained in std namespace:
std::ostringstream strDestXML;
Finally, strstream is deprecated; use stringstream instead - that's why I used it here.
And, just a note about GCC version - 4.1.2 is old, no matter what - use something newer.
The modern name for this include is <strstream>. (Although it's formally deprecated, it's still required.) The classes it defines are in namespace std, and have slightly different semantics than the classical iostream, so you may have to do a little bit of modification later anyway. (Depending on how it is being used, it might make sense to change to <sstream>, replacing [io]strstream with std::[io]stringstream.)

How to run program written for old compiler?

I'm looking for an implementation of Hybrid Tree(not important), and find an "old" one here.
The author said they have tried this code on the SUN Sparc platform (running Solaris 2.6) and with gcc-2.8.1 compiler. And my environment is gcc version 4.4.3 (Ubuntu 10.10).
The problem is:
I run "make" with the makefile he provides, but it gives me lots of error message as follows:
g++ -c Node.C
g++ -c DataNode.C
In file included from DataNode.h:18,
from DataNode.C:17:
Query.h:9:20: error: vector.h: No such file or directory
Query.h:10:19: error: stack.h: No such file or directory
Query.h:13:22: error: function.h: No such file or directory
Query.h:14:22: error: iostream.h: No such file or directory
DataNode.C:283:8: warning: extra tokens at end of #endif directive
In file included from DataNode.h:18,
from DataNode.C:17:
Query.h:29: warning: ‘typedef’ was ignored in this declaration
Query.h:44: warning: ‘typedef’ was ignored in this declaration
Query.h:86: error: expected initializer before ‘<’ token
Query.h:118: error: ISO C++ forbids declaration of ‘PQ’ with no type
Query.h:118: error: expected ‘;’ before ‘*’ token
Query.h:122: error: ISO C++ forbids declaration of ‘PQ’ with no type
Query.h:122: error: expected ‘;’ before ‘*’ token
Query.h:126: error: ISO C++ forbids declaration of ‘PQ’ with no type
Query.h:126: error: expected ‘;’ before ‘*’ token
Query.h:135: error: expected initializer before ‘<’ token
DataNode.C: In member function ‘void DataNode::DisconnectBranch(int)’:
DataNode.C:80: error: ‘memmove’ was not declared in this scope
make: *** [DataNode.o] Error 1
I know I need to modify the souce code so as to agree with the morden compiler, such as change vector.h to vector. But I find it's just endless.
So my question is: is there any convienent method to run this program, no matter automatically converting this code to "modern-style" or using a standalone "old-style" compiler ?
Any suggestions?
===Update:===
Thank you all, I installed gcc2.8.1 in a different dir using --prefix=/usr/local/gcc-2.8.1 and modify the "makefile" to use this old-version gcc(/usr/local/gcc-2.8.1/bin/gcc). But when I run "make", it still gives me errors of not finding the headers:
/usr/local/gcc-2.8.1/bin/gcc -c DataNode.C
In file included from DataNode.h:18,
from DataNode.C:17:
Query.h:9: vector.h: No such file or directory
Query.h:10: stack.h: No such file or directory
Query.h:11: deque: No such file or directory
Query.h:12: algorithm: No such file or directory
Query.h:13: function.h: No such file or directory
Query.h:14: iostream.h: No such file or directory
make: *** [DataNode.o] Error 1
Then I tried to find these heads in /usr/local/gcc-2.8.1 using find /usr/local/gcc-2.8.1 -name "*vector*", but got nothing.
So where are these heads for the old-version gcc?
You can make a vertor.h yourself which includes vector. This way you can fix the incompatibilities noninvasively.
Edit:
You may also need to add a
using namespace std;
in the header file(s). This is
generally a bad idea but this is one situation where i'd do it anyway.
Once you get it working i would reccomend rewriting it to use the new style header files and namespaces.
Debian Lenny (oldstable) has gcc 3.4. This might have a better backward compatibility. Try to make compatibility headers for the rest of the issues and include them via an extra -I directory, e.g. a vector.h header file that includes vector.
Do yourself the favor and try not to touch the old code. It is easy to break legacy code in unforeseen ways.
You could try running the program on QEMU which supports Solaris 2.6. The only problem might be hunting for the install disc/image. Also, there are people that sells old Solaris boxes on eBay for cheap, you might be able to grab one.
GCC provides download for very old versions, you might be able to get better chance if you try older version of the compiler.
gcc has -fpermissive option: try it and see whether at least some errors disappear. Also: try making a single header file that will include all requisite headers with using directives. For example, make stdinc.h containing:
#include <vector>
#include <iostream>
#include <stack>
...
using std::vector;
using std::fstream;
...
Replace all mentions of legacy C++ header files with a single include of stdinc.h. Old C++ didn't have namespaces, so even if you replace individual directives with just using namespace std;, clashes are unlikely.
If the only thing is
#include <vector.h>
to
#include <vector>
using namespace std;
Why not try sed?
grep for all includes to see if there are other includes than the c++ headers. If not your lucky.
Another thing that is more tricky is that there is old code that relies on accessing data through iterators in a non-standard way. I saw that in a Doom map editor for linux. Then you may need to do manual stuff.

Strange error when adding #include <string>

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.

size_t can not be found by g++-4.1 or others on Ubuntu 8.1

This has happened before to me, but I can't remember how I fixed it.
I can't compile some programs here on a new Ubuntu install... Something is awry with my headers.
I have tried g++-4.1 and 4.3 to no avail.
g++ -g -frepo -DIZ_LINUX -I/usr/include/linux -I/usr/include -I/include -c qlisttest.cpp
/usr/include/libio.h:332: error: ‘size_t’ does not name a type
/usr/include/libio.h:336: error: ‘size_t’ was not declared in this scope
/usr/include/libio.h:364: error: ‘size_t’ has not been declared
/usr/include/libio.h:373: error: ‘size_t’ has not been declared
/usr/include/libio.h:493: error: ‘size_t’ does not name a type
/usr/include/stdio.h:294: error: ‘size_t’ has not been declared
...
the file...
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
...
#ubuntu:~/work/zpk/src$ cat /usr/include/linux/types.h | grep size_t
typedef __kernel_size_t size_t;
typedef __kernel_ssize_t ssize_t;
types.h is definitely in the path, and is getting picked up. I verified by changing the file name and get an error its missing...
Does anyone have any ideas...? I would really appreciate the help...
Start by removing -I/usr/include/linux and -I/usr/include. Adding system directories to include paths manually either has no effect, or breaks things. Also, remove -frepo for extra safety.
Generally, you shouldn't be using C .h files for C++. While you may find an easy way to get away with it, and while a lot of this was allowed in previous versions of g++ and in other compilers, the C++ standard defines size_t to be in cstddef (see section 18.2/table 17). g++ has been only getting more strict.
Remove all the includes paths you've added to your command (they are redundant), and add to the top of your source code if not included:
#include <cstddef>
using namespace std;
It's hard to say what the issue is without seeing your complete source. The best way to debug issues like this is to use g++'s "-E" parameter to produce pre-processor output, and then look at that to figure out what's going on in your includes. Here's what the g++ info page says about "-E":
-E Stop after the preprocessing stage; do not run the compiler proper.
The output is in the form of preprocessed source code, which is
sent to the standard output.
Also, why not just include sys/types.h at the top of the file?
Addendum:
On my system, I've created a short file called foo.cc that contains only:
#include <time.h>
And then I've run:
g++ -E /tmp/foo.cc > /tmp/foo.pp
Looking at this output in much detail is very important. For example, I learned that /usr/include/bits/types.h has a typedef for __time_t, and that /usr/include/types.h then uses that typedef to say "typedef __time_t time_t". But, there are interesting other macros surrounding that definiton. Pay special attention to things like the macro "__BEGIN_NAMESPACE_STD" in /usr/include/time.h, which on my system seems to be an empty define. But, I can imagine that some other systems may have a different value for this macro, forcing the definition of time_t into some other namespace.
Read the Cpp info page, section "9 Preprocessor Output" that defines the format of the lines of the file. Of particular note is the section on:
Source file name and line number information is conveyed by lines of the form
# LINENUM FILENAME FLAGS
And then goes on to describe "FLAGS" which are of interest for this level of debugging.
Have you installed the build-essential package?
sudo apt-get install build-essential
Forgot to follow up on this. It turns out that /usr/include cannot be included with /usr/include/linux on this particular distro. size_t seems to be get wiped out by the second includes.
My includes are now merely /usr/include and it works great.
-I/usr/include -I/usr/include/ace -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0...
Pulling out all the includes and playing with them fixed it.
It should be in stddef.h or cstddef. types.h is not a standard library, and I believe it refers to types the OS needs.

C++ cwchar error

I am trying to compile the regex_search function on the vxWorks gcc platform. I was testing with an example to see if I can use it without any issues. The example file includes the following three headers.
#include <string>
#include <map>
#include <boost/regex.hpp>
The errors I get are as follows
include/c++/3.4.4/cwchar:73: error: `::mbstate_t' has not been declared
include/c++/3.4.4/cwchar:114: error: `::btowc' has not been declared
.........
.........(similar "not defined" errors)
c++/3.4.4/cwctype:20: error: `::wctrans_t' has not been declared
c++/3.4.4/cwctype:20: error: `::wctype_t' has not been declared
.........
.........(similar "not defined" errors)
I want to know what cwchar and cwtype headers do. When I open them and see, they contain lot of preprocessor #ifdefs which seems to be checking for compiler specific information.
My supervisor asks me to turn them off. How can I do it?
If your supervisor wants you to turn off the cw-support you can try to define BOOST_NO_CWCHAR and BOOST_NO_CWCTYPE in your project settings.
see http://www.boost.org/doc/libs/1_37_0/libs/config/doc/html/boost_config/boost_macro_reference.html