SGI STL slist Design

[MikeP]

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?

 

[Victor Bazarov]

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

 

[MikeP]

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.


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.


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.

 

[Marcel Müller]

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

 

[MikeP]

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++.

 

[MikeP]

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.