virtual inheritance question

Why this does not compile:


class Sealed
{
friend class Fred;
Sealed() { }
};

class Fred: virtual Sealed
{};

class Fred2: public Fred {};



int main()
{
Fred2 a;
}




while this compiles?:


class Sealed
{
friend class Fred;
Sealed() { }
};

class Fred: Sealed
{};

class Fred2: public Fred {};



int main()
{
Fred2 a;
}




--
Ioannis Vranos

http://www23.brinkster.com/noicys

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote...[color=blue]
> Why this does not compile:
>
>
> class Sealed
> {
> friend class Fred;
> Sealed() { }
> };
>
> class Fred: virtual Sealed
> {};
>
> class Fred2: public Fred {};[/color]

Vitual base class ('Sealed' in this case) is always constructed
in the initialisation list (or using a default c-tor) in the
_most_derived_ class ('Fred2' in this case). But here 'Fred2'
does not have access to 'Sealed's constructor.
[color=blue]
> int main()
> {
> Fred2 a;
> }
>
>
>
>
> while this compiles?:
>
>
> class Sealed
> {
> friend class Fred;
> Sealed() { }
> };
>
> class Fred: Sealed
> {};
>
> class Fred2: public Fred {};[/color]

Here, 'Fred2' constructs 'Fred' only, and 'Fred' constructs the
'Sealed' subobject. Since 'Fred' is a friend of 'Sealed', there
is no problem. Since 'Sealed' is not virtual, 'Fred2' doesn't
have anything to do with its construction.
[color=blue]
>
>
>
> int main()
> {
> Fred2 a;
> }[/color]

V

* Ioannis Vranos:[color=blue]
> Why this does not compile:
>
>
> class Sealed
> {
> friend class Fred;
> Sealed() { }
> };
>
> class Fred: virtual Sealed
> {};
>
> class Fred2: public Fred {};
>
>
>
> int main()
> {
> Fred2 a;
> }[/color]

With virtual inheritance the most derived class must call the
constructors of virtual base classes (in the most derived class'
constructor initialization list), and here the virtual base class
constructor is not available to the most derived class.

I think this is a FAQ.

At least it is a seldom used idiom to implement a sealed
(non-derivable) class, which the name 'Sealed' indicates.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Sat, 08 Jan 2005 23:34:53 +0200, Ioannis Vranos
<ivr@remove.this.grad.com> wrote:
[color=blue]
>Why this does not compile:
>
>
>class Sealed
>{
> friend class Fred;
> Sealed() { }
>};
>
>class Fred: virtual Sealed
>{};
>
>class Fred2: public Fred {};
>
>
>
>int main()
>{
> Fred2 a;
>}
>
>
>
>
>while this compiles?:
>
>
>class Sealed
>{
> friend class Fred;
> Sealed() { }
>};
>
>class Fred: Sealed
>{};
>
>class Fred2: public Fred {};
>
>
>
>int main()
>{
> Fred2 a;
>}[/color]

I believe that with a virtual base class, its constructor must be
accessible to the most derived class; whereas with non-virtual base
classes, this is not the case.

However -- although I have a hard-copy of the C++ standard -- I was
NOT able to find the text to support this. I merely recall having seen
something on either this NG, or comp.std.c++, or the moderated version
of this NG which would support this assumption.

Apparently, assuming that my assumption stated above is true, the
friend declaration doesn't have an effect here. All I can say is that
I tried to compile the examples given here with the Comeau compiler,
and I got the same results as you did.

--
Bob Hairgrove
NoSpamPlease@Home.com

Alf P. Steinbach wrote:
[color=blue]
> With virtual inheritance the most derived class must call the
> constructors of virtual base classes (in the most derived class'
> constructor initialization list), and here the virtual base class
> constructor is not available to the most derived class.
>
> I think this is a FAQ.
>
> At least it is a seldom used idiom to implement a sealed
> (non-derivable) class, which the name 'Sealed' indicates.[/color]


Actually it came out of an attempt of mine to make an easily
implementable Sealed idiom, which was inspired from clc++ FAQ.

Since I understood this difference of behaviour, I will continue the
effort. :-)




--
Ioannis Vranos

http://www23.brinkster.com/noicys

May someone explain why does this compile?


class HiddenSealBaseClass
{
public:
HiddenSealBaseClass() { }
};

class Sealed: virtual HiddenSealBaseClass
{};

class SomeClass: Sealed
{
// Whatever
};




int main()
{
SomeClass obj;
}


Since we have virtual inheritance, the public constructor
HiddenSealBaseClass() should have become private after Sealed
derivation, and thus inaccessible to SomeClass.




--
Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:[color=blue]
>
> May someone explain why does this compile?
>
>
> class HiddenSealBaseClass
> {
> public:
> HiddenSealBaseClass() { }
> };
>
> class Sealed: virtual HiddenSealBaseClass
> {};
>
> class SomeClass: Sealed
> {
> // Whatever
> };
>
>
>
>
> int main()
> {
> SomeClass obj;
> }[/color]


Since we have virtual private inheritance, the public constructor[color=blue]
> HiddenSealBaseClass() should have become private after Sealed
> derivation, and thus inaccessible to SomeClass.[/color]




--
Ioannis Vranos

http://www23.brinkster.com/noicys

* Ioannis Vranos:[color=blue]
> May someone explain why does this compile?
>
> class HiddenSealBaseClass
> {
> public:
> HiddenSealBaseClass() { }
> };
>
> class Sealed: virtual HiddenSealBaseClass
> {};
>
> class SomeClass: Sealed
> {
> // Whatever
> };
>
> int main()
> {
> SomeClass obj;
> }
>
> Since we have [private] virtual inheritance, the public constructor
> HiddenSealBaseClass() should have become private after Sealed
> derivation, and thus inaccessible to SomeClass.[/color]

I don't know whether I agree or not; this is tricky.

On the one hand, it shouldn't matter to a derived class whatever
private things a base class has: they're private, including private
virtual bases.

On the other hand, (1) if so then the idiom shouldn't work with private
virtual inheritance, and that's how it's presented in the FAQ, and (2) I
can't find anything in the standard that makes an exception to the rule
of most derived class call of the virtual base constructor, and (3)
simply by adding an argument (no _default_ constructor) both MSVC and
g++ report that the constructor is unavailable.

So in sum I think I lean strongly towards "compiler bug".

But then it's a bug in at least three different modern compilers (Comeau
4.3.3, MingW g++ 3.4.2, and MSVC 7.1) -- so perhaps it's not... ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach wrote:
[color=blue]
> So in sum I think I lean strongly towards "compiler bug".
>
> But then it's a bug in at least three different modern compilers (Comeau
> 4.3.3, MingW g++ 3.4.2, and MSVC 7.1) -- so perhaps it's not... ;-)[/color]


:-)




--
Ioannis Vranos

http://www23.brinkster.com/noicys