Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!asuvax!noao!amethyst!zeus.opt-sci.arizona.edu!mat
From: mat@zeus.opt-sci.arizona.edu (Mat Watson)
Newsgroups: comp.lang.c++
Subject: Variable sized objects
Message-ID: <1262@amethyst.math.arizona.edu>
Date: 8 Dec 89 18:41:25 GMT
Sender: news@amethyst.math.arizona.edu
Organization: Optical Sciences Center, Tucson, AZ
Lines: 34

In article <4798@blake.acs.washington.edu> keffer@blake.acs.washington.edu (Thomas Keffer) writes:

   In article <10213@alice.UUCP> shopiro@alice.UUCP (Jonathan Shopiro) writes:
   >In article <1020@dutrun.UUCP>, ben@duttnph.tudelft.nl (Ben Verwer) writes:
   >> How do you implement variable sized objects in 2.0
   >
   >Operator new is supplied to support controlling where memory is
   >allocated for objects, not how much memory is allocated.  The trick
   >described in ``the book'' is non-portable, implementation-dependent,
   >and generally a bad idea.  Objects in C++ are always fixed-size.

   Is this now the official "party line"?  I.e., the "trick" in The Book
   is just that, and there will be no upwards compatibility from it?

   Variable sized objects are used extensively in the Rogue Wave Vector
   and Matrix Clases --- if they're an evolutionary dead-end I'll take
   them out.

   -tk

I too am using variable sized objects in my own vector and matrix
classes, and I'd be very disappointed if I couldn't use them.
But I don't see where, in what Jonathan Shopiro wrote, one is kept
from using variable sized objects.  He points out that the assignment
to "this" is non-portable, but he also gives an alternate method.
I just don't see how this implies that variable sized objects
are dead.  If they are I'll just go back to writing code in C.

--Mat

Mat Watson
mat@zeus.opt-sci.arizona.edu [128.196.128.219]
..{allegra,cmcl2,hao!noao}!arizona!zeus.opt-sci.arizona.edu!mat
Optical Sciences Center, Univ. of Arizona, Tucson, AZ 85721, USA