Constructor Inheritance

[Russco]

Been playing with virtual copy assignment operators. Although in Base properties recognizes the operator as having the 'IsVirtual' property true, I cant find any signature in Derived that doesn't include the virtual keyword for which the same property is true. This is making it look like copy assignment is not inherited and virtual is all but ignored. How should a virtual copy assignment operator behave? It really doesn't make any sense to me.
As for virtual destructors as LL pointed out, the slot in the vtable is inherited but the destructor itself isn't. The base class destructor will be called implicitly by the compiler so it has to be accessible to the derived class but at no time does Base::~Base become a member of Derived. The standard allows explicitly calling destructors( basically only for placement new use) but does not allow the same latitude with constructors.

[laserlight]

Been playing with virtual copy assignment operators. Although in Base properties recognizes the operator as having the 'IsVirtual' property true, I cant find any signature in Derived that doesn't include the virtual keyword for which the same property is true. This is making it look like copy assignment is not inherited and virtual is all but ignored. How should a virtual copy assignment operator behave? It really doesn't make any sense to me.

Speaking of which, what exactly is an override of a virtual copy assignment operator? My intuition leads me to:

#include <iostream>

class X
{
public:
    virtual X& operator=(const X& other)
    {
        std::cout << "X copy assignment" << std::endl;
        return *this;
    }

    virtual ~X() {}
};

class Y : public X
{
public:
    Y& operator=(const X& other)
    {
        std::cout << "Y override of X copy assignment" << std::endl;
        return *this;
    }
};

class Z : public X
{
public:
    Z& operator=(const X& other)
    {
        std::cout << "Z override of X copy assignment" << std::endl;
        return *this;
    }
};

int main()
{
    Y y;
    Z z;
    X& r = y;
    r = z;
}

With the MinGW port of g++ 3.4.5, I get the output of "Y override of X copy assignment", which is exactly what I would expect if some other virtual member function was involved. That also makes the most sense to me concerning how a virtual copy assignment operator should behave, if we can consider them to be copy assignment operators even though the parameters are of type reference to the base class rather than reference to the current class.

[Russco]

Hmm maybe an IDE bug in msvc10. The function behaves virtually so I guess must be an inheritable member unless virtual copy assignment operates in the same way as virtual destructors, but my IDE still insists Y::operator =(const X&) is a nonvirtual but then if I add trivial destructors to Y and Z it also insists they are non-virtual.

[Speedo]

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.

I'd say it should be considered a bug. The standard states that ctors have neither names nor addresses, and that they should only be used to initialize an object. MSVC is allowing you to explicitly call a ctor and run a ctor on an object that's already been constructed.

[Ajay Vijay]

I'd say it should be considered a bug.

I would not call it as bug, but non-compliance to the standard.

[Rajesh1978]

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

Ohk I got it.
So there are things that will be accessible but not inherited like constructors.

I got another problem just related to accessibility like below

class Base{
int x;
};

class Derived : public Base{
int y;
};

if i see the sizeof (Derived) it is giving me 8. (consider int size is 4)
But I know that private variables are never inherited.

But is it like it comes to the Derived class but is not accessible and adds 4 bytes to the size.
Correct me if I am wrong

[Lindley]

But I know that private variables are never inherited.

Not quite true. Inheritance is an IS-A relationship, so a Derived IS-A Base. That means that the Derived must contain all members of Base.

However, some of those members, specifically the private ones, may not be accessible to the methods of Derived. So what good are they?

Well, keep in mind that some methods of Base may be inherited wholesale, both signature and implementation. Any public or protected method of Base which is not virtual fits this category, as well as any virtual methods which are not overridden by Derived. These methods will be exposed as part of Derived and accessible, but since they're actually Base functions, they're able to access the private members of Base just fine.

[Rajesh1978]

Whatever there in the Base will come to Derived and increase the size(if attribute) as I showed just before.
Irrespctive of whether it is private or public.

private variables of Base are not accessible directly in the child but we can access it indirectly.

Am I correct

[Ajay Vijay]

Private members are inherited, they are not accessible.
For example:

Derived d;
int* p= (int*)&d;
 
*p=10; // Sets Base::x to 10

Though, it should not be used!