Constructor Inheritance

[Rajesh1978]

How we conclude that the constructors are not inherited??

Because I can call the base class constructors like below which means that the the constructor is accissible .

class Base{
public:
Base(int x,int y){}
};
class Derived : public Base{

public:
Derived(int a,int b):Base(a,b) //I am calling the Base constructor
{
}
};

Thanks

[Russco]

make the base constructor private

[Lindley]

The base constructor is accessible, yes, but it is not inherited because this will not work:

class Base{
public:
    Base(int x,int y){}
};
class Derived : public Base{
    // no constructor, so the default one will be generated
};

int main()
{
    Derived(5,6);// compile error, no such constructor for Derived.
}

[Zlatomir]

How we conclude that the constructors are not inherited??

Because I can call the base class constructors like below which means that the the constructor is accissible .

class Base{
public:
Base(int x,int y){}
};
class Derived : public Base{

public:
Derived(int a,int b):Base(a,b) //I am calling the Base constructor
{
}
};

Thanks

The commented line should be: i am passing constructor's arguments

I'm sure that is called: "Passing constructor's arguments" (or something similar), that's not a actual function call of the constructor, if you need to explicit call the constructor you have a bigger problem with the design of class or class hierarchy.

The constructor of base class is called even if you don't pass parameters (the default c-tor or with default parameters), so you can write: Derived(int a,int b){} // and do something in the c-tor body, of course you need default base c-tor for that.

LE: That line actually says: When construct the "Base part" of Derived object run the Base constructor with the two parameters of the Derived constructor.

[Ajay Vijay]

In a similar line, I can give another example:

class Base
{
public:
   void ConstructorMethod(int);
};
 
class Derived:public Base
{
public:
   void ConstructorMethod(int,int);
};
 
int main()
{
   Derived d;
   d.ConstructorMethod(2,4);
 
   // this is NOT possible
   d.ConstructorMethod(2);
}

The second definition of ConstructorMethod hides the original definition. Same thing happen with CTORs - they are always defined, implicitly or explicitly. The derived definition hides the base' version. To call the base class' you can:

d.Base::ConstructorMethod(2);

And this is also possible!

class Base {
public: Base(int = 0); // Default just for brevity
};
 
class Derived{};
...
Derived d;
d.Base::Base(10); // YES - you can call.

This way you can say that constructors are inherited, but just hidden!

[Russco]

Sorry Ajay, you are wrong. The standard says constructors cannot be called like that. Comeau rejects this code correctly, tho MSVC10 compiles it without a problem (compiler bug?)...

struct Base
{
	Base( int x ) : X( x )
	{}

	int X;
};

struct Derived : Base
{
	Derived() : Base( 5 )
	{}
};

int main()
{
	Derived can_do;
	can_do.Base::Base(10);
	return 0;
}

Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions

"ComeauTest.c", line 18: error: a constructor or destructor may not have its address
taken
can_do.Base::Base(10);
^

1 error detected in the compilation of "ComeauTest.c".

Constructors are not hidden, nor inherited. Constructors, destructor and copy assignment operators are never inherited. To do so would imo go against the whole concept of type-safety.

[laserlight]

Constructors, destructor and copy assignment operators are never inherited. To do so would imo go against the whole concept of type-safety.

hmm... a search for "not inherited" only brings up a sentence in C++03 that confirms that destructors are not inherited. Where does the standard state this more specifically? In particular, does it really state that copy assignment operators are not inherited?

[Russco]

The standard states that constructors do not have a name, so therefore cannot be explicitly called by name. I'm not sure if it mentions that they are not inherited, but for sure TCPPPL does and we know who wrote that . It would go totally against type safety for constructors, destructors or copy assignment to be inherited. They must be accessible to the derived class but they are not members of the derived class which they would be had they been inherited.

[Russco]

Actually I may be wrong about copy assignment. I checked TCPPPL and cant find the info, so I checked Thinking in C++ and thats where this info was stated but I think its wrong because assignment can be virtual so assignment must be inherited and hidden though virtual copy assignment doesn't make much sense to me, but constructors on the other hand I dont think are inherited at all, all they need to be is accessible to the derived class in the same way destructors are.

[Lindley]

Sorry Ajay, you are wrong. The standard says constructors cannot be called like that.

Look closer: He's not calling constructors. Just normal methods called ConstructorMethod(). Slightly confusing, perhaps, but perfectly fine.

[monarch_dodra]

Look closer: He's not calling constructors. Just normal methods called ConstructorMethod(). Slightly confusing, perhaps, but perfectly fine.

Not necessarily confusing. It's called the named constructor idiom. It is almost completely free from a performance point of view, and can be quite useful when constuctor arguments are not quite enough to set the constructors apart, or to really convey the nuances between the different constructors.

[Russco]

Look closer: He's not calling constructors. Just normal methods called ConstructorMethod(). Slightly confusing, perhaps, but perfectly fine.

Oh really?

d.Base::Base(10); // YES - you can call.

This is what I was talking about specifically. This is not allowed. When constructors are called by a programmer, its implicitly or as part of a type conversion which is still an implicit call. Explicitly calling a constructor is what compilers do, not programmers.

[Ajay Vijay]

Sorry Ajay, you are wrong. The standard says constructors cannot be called like that. Comeau rejects this code correctly, tho MSVC10 compiles it without a problem (compiler bug?)...

Not a bug. It compiles in VC6, VC7, VC7.1, VC8, VC9 and VC10 as well. I do not know about standard as such, and never used Comeau compiler.

Constructors are not hidden, nor inherited. Constructors, destructor and copy assignment operators are never inherited. To do so would imo go against the whole concept of type-safety.

I can take that only for CTOR. Destructor ARE inherited, otherwise virtual destructor wouldn't make sense. Also destructors can be called explicitly using X::~X() syntax.
Also, assignment operator are inherited as you mentioned.
Again I don't know about your compiler.


Anyway, my point was not about standard - but basic concept behind CTOR inheritance!

[monarch_dodra]

In a similar line, I can give another example:

class Base
{
public:
   void ConstructorMethod(int);
};
 
class Derived:public Base
{
public:
   using Base::ConstructorMethod; //monarch_dodra: add this line here
   void ConstructorMethod(int,int);
};
 
int main()
{
   Derived d;
   d.ConstructorMethod(2,4);
 
   // this is NOT possible
   d.ConstructorMethod(2);
}

The second definition of ConstructorMethod hides the original definition. Same thing happen with CTORs - they are always defined, implicitly or explicitly. The derived definition hides the base' version.

If you add "using Base::ConstructorMethod" inside Derived allows you to not hide the original definition, and write

   // this is NOW possible
   d.ConstructorMethod(2);

The whole hiding thing is there more as a "safety mechanism" than a real feature anyways. This is because it is usually not really recommended to re-define a function in a derived class, and forcing the user to write the using declaration is like forcing him to say "Yes, I know what I am doing, and I take full responsabilty"

[laserlight]

I can take that only for CTOR. Destructor ARE inherited, otherwise virtual destructor wouldn't make sense. Also destructors can be called explicitly using X::~X() syntax.

As I mentioned earlier:

Even though destructors are not inherited, a destructor in a derived class overrides a base class destructor declared virtual; see 12.4 and 12.5.