C++ compiler about version 4.3 and an odd error of a compilation.

[Miroslaw Makowiecki]

I have yourself c++ compiler about version of 4.3 it installed in a
catalog:/usr/lib/gcc-snapshot in system Debian.
libc6 version 2.6-5
For compilation of file about conntent,this below
it appear following error:
katusis@localhost:~$ /usr/lib/gcc-snapshot/bin/c++ -Wall tytan.cpp
In file included from tytan.cpp:10:
/usr/include/limits.h:125:26: error: no include path in which to search for
limits.h
You say to me what it's not bad and whow do this error repair?
//tytan.cpp
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE "kapt"
#define VERSION "1.0"
/* end confdefs.h. */
#ifdef __STDC__
# include <limits.h>
#else
# include <assert.h>
#endif
Thanks in advice.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

I have yourself c++ compiler about version of 4.3 it installed in a
catalog:/usr/lib/gcc-snapshot in system Debian.
libc6 version 2.6-5
For compilation of file about conntent,this below
it appear following error:
katusis@localhost:~$ /usr/lib/gcc-snapshot/bin/c++ -Wall tytan.cpp
In file included from tytan.cpp:10:
/usr/include/limits.h:125:26: error: no include path in which to search for
limits.h
You say to me what it's not bad and whow do this error repair?
//tytan.cpp
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE "kapt"
#define VERSION "1.0"
/* end confdefs.h. */
#ifdef __STDC__
# include <limits.h>
#else
# include <assert.h>
#endif

First of, you know that limits.h is not a C++ include file (it's C)? The
standard C++ includes don't have a .h at the end so it would be just
<limits> if you wanted the C++ version.

As for your problem it seems that gcc is not set correctly, try asking
in gnu.gcc.help for more help on setting up gcc.

 

[Jack Klein]

First of, you know that limits.h is not a C++ include file (it's C)?

Sorry, but that is incorrect. All 18 C95 standard headers are also
standard headers in C++. Including them as one does in C, with

The
standard C++ includes don't have a .h at the end so it would be just
<limits> if you wanted the C++ version.

Again, to include a C standard header in the preferred standard C++
manner, the preferred method would be <climits> instead of <limits.h>,
but the original form is valid C++.

Also note that some standard C and standard C++ header names are
similar, so in C++:

#include <limits> includes a C++ only header, but:

#include <climits> includes the C header <limits.h>

....and

#include <string> includes a C++ only header, but:

#include <cstring> includes the C header <string.h>

The preferred method for including standard C headers in C++ is based
on <cheader> placing the C identifiers only in the std namespace,
whereas including them via <header.h> puts the identifiers in both the
global and std namespaces.

In the particular case of <limits.h> or <climits>, it makes absolutely
no difference at all, because the header only defines macros, and
macros are not scoped to namespaces.

As for your problem it seems that gcc is not set correctly, try asking
in gnu.gcc.help for more help on setting up gcc.

This, of course, is excellent advice. Another place the OP could try
is
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[James Kanze]

[...]

Also note that some standard C and standard C++ header names are
similar, so in C++:

#include <limits> includes a C++ only header, but:

And a C++ only header may include any other C++ headers.

#include <climits> includes the C header <limits.h>

Not in a conforming implementation. (Actually, in the specific

...and

#include <string> includes a C++ only header, but:

#include <cstring> includes the C header <string.h>

The preferred method for including standard C headers in C++ is based
on <cheader> placing the C identifiers only in the std namespace,
whereas including them via <header.h> puts the identifiers in both the
global and std namespaces.

That's what the standard says. In practice, conformant
implementations of the <cxxxx> forms are very rare, so I stick
pretty much to the <xxxx.h> forms. The next version of the
standard should clarify this some, and in particular, make
conformance more realistic, so I'll probably start changing.

Note, however, that which ever one you include, you can expect
to find the names in both std:: and ::.

 

[Jorgen Grahn]

I have yourself c++ compiler about version of 4.3 it installed in a
catalog:/usr/lib/gcc-snapshot in system Debian.

I think you should stick to a released version of GCC, if you cannot
debug these kinds of problems yourself (or know how to ask on the
correct mailing list).

Debian Linux 4.0 "Etch" includes gcc 4.1.2, which is a very decent C++
compiler.

/Jörgen