Why make a class 'sealed'?

[Julie]

What would be the primary motivation to make a class 'sealed' (meaning that you
can't derive from it) in C++? (I understand that there is currently no sealed
keyword in C++, but that there are techniques to accomplish this. From what
I've heard, sealed may be added to the language in the future?)

I understand that there are compiler and efficiency reasons (optimizing away
virtual function calls, etc.) that justify it in other languages, but I'm not
interested in that. I'm asking strictly from an design standpoint (where minor
efficiency gains are not important).

I've briefly search Google/Google Groups, but didn't find anything that really
answered my question. Links, books, or other authoritive resources would be
appreciated, as well as personal (objective) responses.

Thanks -- Julie

[Leor Zolman]

On Tue, 02 Mar 2004 16:57:04 -0800, Julie <ju***@aol.com> wrote:

What would be the primary motivation to make a class 'sealed' (meaning that you
can't derive from it) in C++? (I understand that there is currently no sealed
keyword in C++, but that there are techniques to accomplish this. From what
I've heard, sealed may be added to the language in the future?)

I understand that there are compiler and efficiency reasons (optimizing away
virtual function calls, etc.) that justify it in other languages, but I'm not
interested in that. I'm asking strictly from an design standpoint (where minor
efficiency gains are not important).

I've briefly search Google/Google Groups, but didn't find anything that really
answered my question. Links, books, or other authoritive resources would be
appreciated, as well as personal (objective) responses.

Thanks -- Julie

One reason I can think of off the top of my head: Prevent a user ("client")
of classes in an inheritance hierarchy--where "protected" access control is
employed--from deriving their own class for no purpose other than to gain
access to protected members of the base class. I've seen this used as an
argument against the wisdom of ever using "protected" at all as an access
control specifier for members.

Of course, C++'s access control mechanism really is meant to convey design
guidelines, not offer bullet-proof firewalling between classes by itself; a
client could simply edit a .h file to make everything public in the
hierarchy s/he wants access to, and get that access without having even to
create another class. To create truly robust separation typically costs you
in terms of code size and speed (for forwarding or proxy classes).

Those same issues would probably need to be considered if anything such as
"sealed" was to be up for consideration for addition to C++. Would it be a
symbolic thing, like "protected", or should it be given teeth?

Just my personal response (somewhere in the spectrum between objective and
subjective...)
-leor
Leor Zolman
BD Software
le**@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

[Tom Plunket]

Julie wrote:

What would be the primary motivation to make a class 'sealed'... ?

Try comp.object, maybe?

-tom!

[Sharad Kala]

"Julie" <ju***@aol.com> wrote in message news:40***************@aol.com...

What would be the primary motivation to make a class 'sealed' (meaning that you can't derive from it) in C++? (I understand that there is currently no sealed
keyword in C++, but that there are techniques to accomplish this. From what
I've heard, sealed may be added to the language in the future?)

I understand that there are compiler and efficiency reasons (optimizing away
virtual function calls, etc.) that justify it in other languages, but I'm not
interested in that. I'm asking strictly from an design standpoint (where minor efficiency gains are not important).

Take the case of STL containers. It's usually advised not to derive from them.
Reason being that there is no virtual destructor. I have seen people still
derive from
STL containers due to various reasons.
IMO, if the class is designed to be used as it is, with no intentions of being
derived from
then probably "sealing" in such a case is fine. You ensure this way that users
of your class
do not inadvertently try deleting through base class pointers.

--
Sharad

[Victor Bazarov]

"Sharad Kala" <no*****************@yahoo.com> wrote...

"Julie" <ju***@aol.com> wrote in message news:40***************@aol.com...

What would be the primary motivation to make a class 'sealed' (meaning that

you

can't derive from it) in C++? (I understand that there is currently no

sealed keyword in C++, but that there are techniques to accomplish this. From what I've heard, sealed may be added to the language in the future?)

I understand that there are compiler and efficiency reasons (optimizing away virtual function calls, etc.) that justify it in other languages, but I'm not interested in that. I'm asking strictly from an design standpoint

(where minor

efficiency gains are not important).
Take the case of STL containers. It's usually advised not to derive from

them. Reason being that there is no virtual destructor.
Absense of a virtual destructor is NOT a valid reason not to derive from
the class. The only limitation is that the derived object allocated from
freestore must not be deleted through a pointer to the base class. BFD!
I have seen people still
derive from
STL containers due to various reasons.
And I take it you never do it. Why? Just because, I suppose. Because
you read somewhere that "it's usually advised not to derive from them",
right?
IMO, if the class is designed to be used as it is, with no intentions of being derived from
then probably "sealing" in such a case is fine. You ensure this way that users of your class
do not inadvertently try deleting through base class pointers.

How do you ensure that users do not inadvertently write 'a[i]=i++' or use
reinterpret_cast when they shouldn't?

If there ought to be some mechanism for holding an idiot's hand, then why
should it only be in such narrow area as derived classes?

V

[Sharad Kala]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:7me1c.167372$jk2.616040@attbi_s53...

"Sharad Kala" <no*****************@yahoo.com> wrote...

Absense of a virtual destructor is NOT a valid reason not to derive from
the class. The only limitation is that the derived object allocated from
freestore must not be deleted through a pointer to the base class. BFD!
True (except for BFD ;-))

I have seen people still
derive from
STL containers due to various reasons.

And I take it you never do it. Why? Just because, I suppose. Because
you read somewhere that "it's usually advised not to derive from them",
right?

Ofcourse not.
If your business logic requires that you do not want the whole vector interface
as it is or may be want to change some behavior then one has to inherit from it.

IMO, if the class is designed to be used as it is, with no intentions of

being

derived from
then probably "sealing" in such a case is fine. You ensure this way that

users

of your class
do not inadvertently try deleting through base class pointers.

How do you ensure that users do not inadvertently write 'a[i]=i++' or use
reinterpret_cast when they shouldn't?

Agreed that a user should know the lack of a sequence point or that the cast
is unsafe.
If there ought to be some mechanism for holding an idiot's hand, then why
should it only be in such narrow area as derived classes?

ok..so your point is that an ignorant user can do any kind of silly mistake and
where all you can stop him. OK, fine. I was saying that probably there would
be lesser mistakes if you didn't allow him to do so in the first place.

Best wishes,
Sharad

[Claudio Puviani]

"Sharad Kala" <no*****************@yahoo.com> wrote

Take the case of STL containers. It's usually advised not to derive from them.
Reason being that there is no virtual destructor. I have seen people still
derive from
STL containers due to various reasons.
IMO, if the class is designed to be used as it is, with no intentions of being
derived from

Think of deriving from Standard Library containers as evolution in action. ;-)

Claudio Puviani