Strange behaviour in derived class when using -std=c++0x

Axel Freyn axel-freyn@gmx.de
Sun Feb 20 14:51:00 GMT 2011


Hi Jakob,
On Sun, Feb 20, 2011 at 03:03:35PM +0100, Jakob van Bethlehem wrote:
> Dear users,
>
> Since I'm completely new to this list, I'm not sure what type of  
> questions should be posted here, but hopefully someone can point me in a  
> better direction, if this is not the right place.
>
> So here's the thing. Consider the following relatively simple piece of code:
>
> class A {
> int d_errno;
>
> public:
> A(int errno);
> virtual ~A() {};
> };
>
> A::A(int errno)
> :
> d_errno(errno)
> {}
>
> struct B: public A {
> public:
> B()
> :
> A::A(10)
> {}
> };
>
> When compiling such code as standard c++, there is no problem. But now I  
> add the option -std=c++0x (for other pieces of code where I want to  
> experiment a bit with the new possibilities)
On my machine, it compiles fine -- both with g++ 4.6.0 (version
20101203) and with 4.4.5.  However, I believe your example-code and the
error-messages are not fully compatible: The error appears in line 24 --
but your example has only 20 lines :-) Did you really compile exactly
that file?
> If I then try to compile, I get:
>
> bool.h: In constructor ‘B::B()’:
> bool.h:24:9: error: invalid conversion from ‘int’ to ‘int* (*)()’
> bool.h:24:9: error: initializing argument 1 of ‘A::A(int* (*)())’
For me especially surprising is the fact, that gcc claims the
constructor of A wants a function pointer.  
However, a possible explanation: The parameter of "A::A()" is called
"errno" -- and as soon as I #include <errno.h>, I get exactly your error
message -- with and without c++0x. 
Searching in the header - fileѕ gives an explanation (on Debian squeeze):
errno.h includes bits/errno.h. And there, "errno" can be defined as a macro
(*__errno_location()) ==> this gives the function pointer.

What happens if you call the variable differently? Do you include
"<errno.h>" ?

Nevertheless, I haven't checked what the standards of C++ and C++0x say
about "errno", but probably the compiler is right...

Axel



More information about the Gcc-help mailing list