Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: Variable sized objects
Message-ID: <9515@microsoft.UUCP>
Date: 13 Dec 89 17:27:15 GMT
References: <1262@amethyst.math.arizona.edu> <2240@dataio.Data-IO.COM> <6987@chaph.usc.edu>
Reply-To: jimad@microsoft.UUCP (Jim Adcock)
Organization: Microsoft Corp., Redmond WA
Lines: 25


In article <2240@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes:
>Variable sized objects are quite useful and work fine. The only thing
>you cannot do is derive from a variable size class.
>Does anyone know how to *prevent* a derivation from a particular class
>(i.e. cause a compile-time error if you try it)?

 Either make the constructor private or make a pure virtual destructor.
(Either approach "does the right thing" in the case of variable sized
 objects)

 IMHO variable-sized objects are a hack, and a very bad hack.  They only
 work for objects made on the heap, and compilers don't really know how
 to correctly handle them in non-trivial cases.  Even if a user manages
 to correctly declare all variable-sized objects on the heap, the compiler
 could decide to generate a temporary of the class *not* on the heap,
 leading to incorrect behavior or at best a run-time crash.  No guarantee
 any of this is going to work on a given present compiler port, or future
 compiler, in any case.  C compilers are free to generate code that
 traps, crashes, or just doesn't do what you expect when you index off
 the end of a structure or an array.  One could expect variable sized
 objects to conflict with future compilers and/or memory management
 schemes.

 [standard disclaimer]