SGI STL slist Design
 

SGI STL's slist derives from a base class which has a private constructor
and destructor, no doubt to enforce that the base class is not useable by
itself. slist then uses private inheritance from the base class. Would
declaring the constructor and destructor of the base class protected and
deriving slist from the base using public inheritance accomplish the same
thing? And why bother giving the other member functions (erase_after) of
the base class other access control when the constructor and destructor
are already private?

Re: SGI STL slist Design
 

On 3/14/2011 2:48 PM, MikeP wrote:
> SGI STL's slist derives from a base class which has a private constructor
> and destructor, no doubt to enforce that the base class is not useable by
> itself.

That sounds odd. If the class cannot be constructed except by itself or
a friend, then 'slist' has to be declared a friend of that class, no?
Otherwise, slist will not be able to construct the subobject of that
base class.

> slist then uses private inheritance from the base class. Would
> declaring the constructor and destructor of the base class protected and
> deriving slist from the base using public inheritance accomplish the same
> thing?

Of course not. Private inheritance prevents the implicit conversion.
Public inheritance provides implicit conversions. Exactly the opposite
if you think about it.

> And why bother giving the other member functions (erase_after) of
> the base class other access control when the constructor and destructor
> are already private?

Not sure what you're talking about here. Are we supposed to know what
"SGI STL's slist" is? If it's not a standard class/template, perhaps
you could provide some code snippets to illustrate what you mean.

V
--
I do not respond to top-posted replies, please don't ask

Re: SGI STL slist Design
 

Victor Bazarov wrote:
> On 3/14/2011 2:48 PM, MikeP wrote:
>> SGI STL's slist derives from a base class which has a private
>> constructor and destructor, no doubt to enforce that the base class
>> is not useable by itself.
>
> That sounds odd. If the class cannot be constructed except by itself
> or a friend, then 'slist' has to be declared a friend of that class,
> no?

No, because it uses private inheritance which gives access to the base
class privates including member functions?

> Otherwise, slist will not be able to construct the subobject of
> that base class.
>
>> slist then uses private inheritance from the base class. Would
>> declaring the constructor and destructor of the base class protected
>> and deriving slist from the base using public inheritance accomplish
>> the same thing?
>
> Of course not. Private inheritance prevents the implicit conversion.

Yes. Private inheritance means "is implemented in terms of". The
alternative is to do composition.

> Public inheritance provides implicit conversions.

Yes. Public inheritance means "is a". erase_after is given protected
access, so the derived slist IS-A slist_base, or so it implied. I'm sure
there are subtleties in the design, but that's what I am trying to figure
out.

Why worry about implicit conversions to a base class who's type will
never ever be used in a scenario where such a conversion could occur?
slist_base will never show up in code outside of the STL library itself.
It's internal.

> Exactly the
> opposite if you think about it.
>
>> And why bother giving the other member functions (erase_after) of
>> the base class other access control when the constructor and
>> destructor are already private?
>
> Not sure what you're talking about here. Are we supposed to know what
> "SGI STL's slist" is? If it's not a standard class/template, perhaps
> you could provide some code snippets to illustrate what you mean.

Oh, I thought it didn't need more explanation and that it was clear. If
not though, one could perusal stl_slist.h in the SGI STL code:
http://www.sgi.com/tech/stl/. I did not excerpt code from there because
it would have meant posting a bunch of extraneous information.

Re: SGI STL slist Design
 

MikeP wrote:
> SGI STL's slist derives from a base class which has a private constructor
> and destructor,

nope.

Constructor and destructor of _Slist_base are public. Note that
_Slist_base is a /struct/ rather than a class.


Marcel

Re: SGI STL slist Design
 

Marcel Müller wrote:
> MikeP wrote:
>> SGI STL's slist derives from a base class which has a private
>> constructor and destructor,
>
> nope.
>
> Constructor and destructor of _Slist_base are public. Note that
> _Slist_base is a /struct/ rather than a class.
>

Yes!! I missed that. Ah the subtleties of C++.

Re: SGI STL slist Design
 

MikeP wrote:
> SGI STL's slist derives from a base class which has a private
> constructor and destructor,

This is not correct: the base is a struct, so the constructor and
destructor are public.

> no doubt to enforce that the base class
> is not useable by itself. slist then uses private inheritance from
> the base class.

Or so I reasoned when thinking the base was a class.