home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!usc!news.cerf.net!nic.cerf.net!hlf
- From: hlf@nic.cerf.net (Howard Ferguson)
- Newsgroups: comp.lang.c++
- Subject: Re: Preventing inheritance
- Date: 12 Jan 1993 02:07:54 GMT
- Organization: CERFnet Dial n' CERF Customer Group
- Lines: 65
- Message-ID: <1it95qINN55t@news.cerf.net>
- References: <1iqtnpINN283@news.cerf.net> <1993Jan11.195503.6255@athena.mit.edu>
- NNTP-Posting-Host: nic.cerf.net
-
- In article <1993Jan11.195503.6255@athena.mit.edu> berczuk@space.mit.edu (Steve Berczuk) writes:
- >In article <1iqtnpINN283@news.cerf.net>, hlf@nic.cerf.net (Howard Ferguson) writes:
- >|>
- >|> If I create a class which I am supplying to other users, how do I
- >|> make sure that they do not inherit from it ever. I could overload new
- >|> and check the size of the object that is being allocated, but there
- >|> are two catchs. The first minor one is that this is a run-time check,
- >|> and it would be far preferable to catch this sort of thing at compile
- >|> time. More seriously, they could over-ride the new operator and by-pass
- >|> the check.
- >|> yours totally paranoid,
- >|> hlf
- >Umm, why would you want to do this?
- >
- >It seems like soing this sort of thing defeats the purpose fo using c++; I can
- >understand not wanting to "support" other users who inherit the class, but that
- >might be best approached by some sort of documentation (eg comments in the header
- >to the effect of "this class supports some wierd protocols that subclasses need to
- >enforce, subclass at your own risk").
- >
- >It is probably better to just ensure that instances of the class are always in a
- >consistent state.
- >
- >Is there are really valid reason (aside from paranoia) that one would want to write
- >a class that could not be subclassed?
- >
- >
- >
-
- A lot of people reacted in horror when I posted this question. Here is
- my reason. I am (hypothetically) writting a class library. I am
- allowing my users pass me some data of set size but arbitrary type
- (pointers would be a good example - you can usually depend on them
- to stay the same size). However I do not wish to ask my users to do
- nasty casts as they pass data to me and get data from me.
-
- So I give them a template, and get them to encapsulate the data in the
- template. All of the templated classes inherit from a (effectively
- empty) parent class so the user is able to pass the objects
- created from the templates to the library.
-
- I could get the user to new the objects and pass them to me and I
- would later delete them. Or he could delete them, or he might not
- realise that I am going to delete them and delete them also (boom)
- or he could pass them to me twice and I might then delete them
- twice (boom).
-
- So instead I get the user to declare the objects locally and I do a
- bitwise copy of it when I receive it. If I am going to do something
- as dangerous as a bitwise copy, I want to be very sure that the
- sucker has not changed size on me without my permisson.
-
- You may argue that if he has inherited from my templated object and
- then passed it to me the bitwise copy will simply leave out the
- extra piece and everyone is happy. But what if he has multiply
- inherited and the organisation in memory has completely different
- organisation. The library might then copy the wrong parent. Also
- a wierd compiler might give things a strange arrangement in memory
-
- I am sure there are plenty of other examples where a library
- is supplying a class for a particular -- and possibly hacky --
- purpose and the coder does not want his hack broken by an
- over ambitious user.
-
- hlf
-