NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/pascal/6687

Internet Message Format | 1992-11-18 | 3.2 KB

Path: sparky!uunet!news.tek.com!vice!bobbe
From: [e-mail] (Robert Beauchaine)
Newsgroups: comp.lang.pascal
Subject: Re: BP/TP OOP is missing something...
Message-ID: <[e-mail]>
Date: 18 Nov 92 17:43:18 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 69

In article <[e-mail]> [e-mail] (Duncan Murdoch) writes:

>On the other hand, it seems that it would be rather inefficient in lots of
>code.  For example, I often write routines that need to do calculations
>before they can call the constructor for an object; if it had already been
>constructed, would I have to destroy it before changing it?  A simple
>example would be reading a matrix from a file:  I might read a line to get
>the matrix dimensions, construct an appropriate matrix, and then read the
>data into it.  How are situations like that handled with automatic
>constructors?  Or is the automatic construction optional?  If so, that just
>leads to code equivalent to the TP code.
>

  Constructors come in many flavors in C++.  There are default
  constructors, copy constructors, and explicit constructors.

  Default constructors are called when you don't initialize an
  object at its declaration:

     anobject x;  /* The default constructor is called here */

  For your matrix example, the default constructor would initialize
  you dynamic memory pointers to NULL, set your dimenension(s) to 0,
  and whatever else is required when you don't know the size of your
  matrix.

  Copy constructors are used to create an object from an already
  existing ojbect:

    anobject x;
    anobject y = x;  /* Copy constructor called here */

  This is preferable to a bitwise copy, especially for classes like
  a matrix where you want to copy the information from y, but don't
  want to create two pointer references to the same memory.

  And finally, there are explicit constructors:

    anobject x(3,column1,column2,column3)

  Here, you are calling a (previously defined) constructor that
  accepts a dimension and a list of the column vectors out of which
  to build the matrix.

  In all of these examples, if the objects were allocated on the
  stack as in a function, they would automatically be destroyed when
  you fell off the end of the function code; no fuss, no muss, no
  objects accidentally left over gobbling up memory.

  Your matrix example is a poor one to use as an example of automatic
  construction, since a generic matrix class doesn't have a size
  until you exlicitly give it one (what's a default matrix?) .
  Many other objects don't have this problem, and automatic
  construction would alleviate the programmer of the task of creating
  and destroying them.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Bob Beauchaine [e-mail]

"Look, I tried the cat experiment.  On the third trial, the cat was
dead.  On each of the subsequent 413 trials, it remained dead.  Am I
doing something wrong?"
            James Nicoll

Q.  How many Heisenbergs does it take to screw in a light bulb?
A.  If you know the number, you don't know where the light bulb is!