autotools, c++, and g++ version differences

autotools, c++, and g++ version differences

Post by Noah Robert » Sun, 08 Jun 2003 03:11:39



On my computer I have gcc 2.95.  Gcc 3.x is diferent than this version
in that it follows the C++ standard more closely, for instance
namespaces are enforced and certain header files are different
(strstream comes to mind).  Some of these differences are compatable,
some are not.  The books and references I have show that the correct way
to shut off buffering in cin would be:

cin.rdbuf()->pubsetbuf(NULL, 0);

However on my compiler, the old version, it is:

cin.rdbuf()->setbuf(NULL, 0);

which is labeled as protected in my documentation, I don't expect it
will compile correctly with newer versions of gcc.

Is there a good, all encompasing, way of telling if I am being compiled
with the old or new version of the stdc++ library using autotools?  Or
should I just use the __GNUC__ define like:

#ifdef __GNUC__
# if __GNUC__ < 3
cin.rdbuf()->setbuf(NULL, 0);
# else
cin.rdbuf()->pubsetbuf(NULL, 0);
# endif
#endif

NR

 
 
 

autotools, c++, and g++ version differences

Post by Thomas Richte » Mon, 09 Jun 2003 05:22:54



> On my computer I have gcc 2.95.  Gcc 3.x is diferent than this version
> in that it follows the C++ standard more closely, for instance
> namespaces are enforced and certain header files are different
> (strstream comes to mind).  Some of these differences are compatable,
> some are not.  The books and references I have show that the correct way
> to shut off buffering in cin would be:

> cin.rdbuf()->pubsetbuf(NULL, 0);

> However on my compiler, the old version, it is:

> cin.rdbuf()->setbuf(NULL, 0);

> which is labeled as protected in my documentation, I don't expect it
> will compile correctly with newer versions of gcc.

> Is there a good, all encompasing, way of telling if I am being compiled
> with the old or new version of the stdc++ library using autotools?

Yes. Try to compile either version within an AC_TRY_COMPILE in the
configure.in using autoconf. To illustrate this a bit, here's a similar
test to check for another C++ standard break of the 2.95:

# Check whether private subclasses have access to private members.
# According to the C++ standard, they should, but for some compilers,
# they don't. This is a bug in g++ 2.95.4 and before, got fixed in 3.2
AC_MSG_CHECKING([whether private subclasses have access to private members])
AC_TRY_COMPILE([],[
class A {
  int a;
  class B {
   B(class A *a)
   {a->a = 0;}
  };

Quote:};

],[ac_private_access='yes';AC_DEFINE(HAS_PRIVATE_ACCESS,[1],[Define to 1
if subclasses have access to private members])],
[ac_private_access='no'])
AC_MSG_RESULT($ac_private_access)

 > Or

Quote:> should I just use the __GNUC__ define like:

> #ifdef __GNUC__
> # if __GNUC__ < 3
> cin.rdbuf()->setbuf(NULL, 0);
> # else
> cin.rdbuf()->pubsetbuf(NULL, 0);
> # endif
> #endif

It's a bit against the autoconf policy to check specifically for a
compiler version. You should check for the feature, not for the version.
This way, it would also be able to test for problems on other compilers.

Greetings,
        Thomas

 
 
 

autotools, c++, and g++ version differences

Post by Noah Robert » Mon, 09 Jun 2003 12:04:32


Quote:> # Check whether private subclasses have access to private members.
> # According to the C++ standard, they should, but for some compilers,
> # they don't. This is a bug in g++ 2.95.4 and before, got fixed in 3.2
> AC_MSG_CHECKING([whether private subclasses have access to private
> members])
> AC_TRY_COMPILE([],[
> class A {
>  int a;
>  class B {
>   B(class A *a)
>   {a->a = 0;}
>  };
> };
> ],[ac_private_access='yes';AC_DEFINE(HAS_PRIVATE_ACCESS,[1],[Define to 1
> if subclasses have access to private members])],
> [ac_private_access='no'])
> AC_MSG_RESULT($ac_private_access)

Trying something similar:

AC_LANG_CPLUSPLUS
AC_MSG_CHECKING([whether buffers have protected members])
AC_TRY_COMPILE([#include <iostream>], [
void test()
{
   using namespace std;
   cin.rdbuf()->setbuf(NULL,0);

Quote:}

],[ac_prot_mem='yes';AC_DEFINE(HAS_PROTECTED_MEM,[1], [define to 1...])],
[ac_prot_mem='no'])
AC_MSG_RESULT($ac_prot_mem)

Is failing all of the time.  The test code compiles on my system using
g++ -c test.cpp that contains the exact same code.  I am not sure how to
go about finding out why it is failing.

Quote:>> #ifdef __GNUC__
>> # if __GNUC__ < 3
>> cin.rdbuf()->setbuf(NULL, 0);
>> # else
>> cin.rdbuf()->pubsetbuf(NULL, 0);
>> # endif
>> #endif

> It's a bit against the autoconf policy to check specifically for a
> compiler version. You should check for the feature, not for the version.
> This way, it would also be able to test for problems on other compilers.

Yeah, I didn't like it either.

- Show quoted text -

Quote:

> Greetings,
>     Thomas

 
 
 

autotools, c++, and g++ version differences

Post by Thomas Richte » Wed, 11 Jun 2003 03:36:51


Hi,

Quote:> Trying something similar:
> AC_LANG_CPLUSPLUS
> AC_MSG_CHECKING([whether buffers have protected members])
> AC_TRY_COMPILE([#include <iostream>], [
> void test()
> {
>    using namespace std;
>    cin.rdbuf()->setbuf(NULL,0);
> }
> ],[ac_prot_mem='yes';AC_DEFINE(HAS_PROTECTED_MEM,[1], [define to 1...])],
> [ac_prot_mem='no'])
> AC_MSG_RESULT($ac_prot_mem)
> Is failing all of the time.  The test code compiles on my system using
> g++ -c test.cpp that contains the exact same code.  I am not sure how to
> go about finding out why it is failing.

"autoconf" is your friend. (-; In case it's failing all the time, check
the config.log file to see what's exactly going on and *why* the compiler
doesn't accept the code. It's likely a different problem, not the feature
you tested for.

So long,
        Thomas

 
 
 

autotools, c++, and g++ version differences

Post by Noah Robert » Wed, 11 Jun 2003 03:58:57


Quote:> "autoconf" is your friend. (-; In case it's failing all the time, check
> the config.log file to see what's exactly going on and *why* the compiler
> doesn't accept the code. It's likely a different problem, not the feature
> you tested for.

It looks like autoconf is surrounding the code within a main function.
So I stopped putting my code inside of a function and just use the two
lines:

using namespace std;
cin.rdbuf()->setbuf(NULL, 0);

and that works.  I suppose that it might be necissary at some time to
build a function inside of the AC_TRY_COMPILE macro, is there a way to
get it to not surround your code in a main()?  The documentation does
not show that this is done in the first place and I don't see anything
about telling it not to.

Anyway, thanks for your help.  I should have been able to find this
answer myself but I was looking in config.status instead of the log :P

NR

 
 
 

autotools, c++, and g++ version differences

Post by Thomas Richte » Wed, 11 Jun 2003 17:45:51


Hi,

Quote:> I suppose that it might be necissary at some time to
> build a function inside of the AC_TRY_COMPILE macro, is there a way to
> get it to not surround your code in a main()?  The documentation does
> not show that this is done in the first place and I don't see anything
> about telling it not to.

Not that I know of, but you might try the autoconf mailing list for
further instructions.

One thing you could do is the following: Don't use AC_TRY_COMPILE, but use
AC_TRY_RUN and insert a dummy main that just signals a success. This macro
will also implicitly (no wonder!) try to compile the code, and will fail if
this first step fails.

Greetings,      
        Thomas

 
 
 

1. Using intel C++ icc with autotools

Hi,
  Do the autotools support creation of shared libraries with icc? If
so what options does one pass configure to get this to happen?

I am testing with examplelib from
http://www.murrayc.com/learning/linux/building_libraries/examplelib-0...
to try to make a shared library aswell as with imlib2. So far I can
only make static libs.

examplelib-0.2.0]$ CC=icc CXX=icc ./configure --enable-shared

checking how to hardcode library paths into programs... unsupported
checking for icc option to reload object files... -r
checking dynamic linker characteristics... Linux ld.so
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes

Thanks.

2. RH7 Default Fontserver?

3. Question running C++ compiled application on newer OS version versus on older OS versions of AIX?

4. 3D TV switching box with RS6K Monitor: Info sought.

5. Matrox Mystique ands X.

6. smbfs time-stamp problems

7. make: difference c++ and c compiling

8. Want to Learn Kernel and IP packets

9. Are there any C/C++-language (syntax) differences across modern unixes

10. Difference between C and C++

11. the difference between C Set++ and Visualage C++

12. Performance differences in C and C++

13. differences between gcc/g++ and Solaris Workshop C++?