Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!sgihub!dragon!xanadu.wpd.sgi.com!pal
From: pal@xanadu.wpd.sgi.com (Anil Pal)
Newsgroups: comp.lang.c++
Subject: Re: Constructor question
Message-ID: <1991Apr18.005426.21863@dragon.wpd.sgi.com>
Date: 18 Apr 91 00:54:26 GMT
References: <1991Apr2.110623.22219@and.cs.liv.ac.uk> <20164@alice.att.com> <HAYDENS.91Apr17113619@natasha.juliet.ll.mit.edu>
Sender: news@dragon.wpd.sgi.com (CNews Account)
Reply-To: pal@wpd.sgi.com
Organization: Silicon Graphics, Inc.
Lines: 36

In article <HAYDENS.91Apr17113619@natasha.juliet.ll.mit.edu>, haydens@natasha.juliet.ll.mit.edu (Hayden Schultz) writes:
|> Why do you have to redefine the operator new? Here's a simple example
|> which does it with a parent class and a derived child class. If
|> there's no inheratance relationship, you could do the same thing if
|> you created a conversion operator from C to P.
[ example deleted ]

The example uses assignment to this, which is deprecated in C++ 2.0 and
beyond (in fact, using the +p option to cfront-based C++ translators
will not allow the assignment.

In any case, the point was to use a constructor for a class from within
another constructor for the same class.  Adding a superfluous class to
the inheritance hierarchy seems like way too much work to do.

As has been pointed out to me, I was mistaken in my reading of the ARM;
the placement syntax of operator new is part of C++ 2.0 and beyond, but
requires the inclusion of <new.h>.  Given that, I believe that my
original suggestion, calling the constructor through a placed new, is a
reasonable solution.  At least, I haven't heard any strong arguments
against it so far.

class X {
    X();	// Basic constructor
    X(int i);	// Constructor that wants to call X::X()
};

#include <new.h>
X::X(int i) {
    new (this) X;
    // Whatever additional processing is desired
}

-- 
Anil A. Pal,	Silicon Graphics, Inc.
pal@wpd.sgi.com	(415)-335-7279