Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!ucsd!orion.oac.uci.edu!uci-ics!gateway
From: schmidt@zola.ics.uci.edu (Doug Schmidt)
Newsgroups: comp.lang.c++
Subject: a new question
Message-ID: <25744190.4753@paris.ics.uci.edu>
Date: 29 Nov 89 20:52:31 GMT
Reply-To: schmidt@zola.ics.uci.edu (Doug Schmidt)
Followup-To: comp.lang.c++
Organization: University of California, Irvine - Dept of ICS
Lines: 53

On page 19 of Stroustrup's `Exception Handling for C++' paper from the
``C++ at Work'' conference it states:

   It is possible to disallow free store allocations of objects of a
   class x by declaring x::operator new () private.

However, cfront 2.0 does not appear to enforce this, as the following example
illustrates:

----------------------------------------
#include <stdio.h>
#include <stdlib.h>

class x
{
public:
  x () { printf ("constructing x\n"); }
private:
  void *operator new (size_t size) { printf ("size = %d\n", size);
                                     return ::new char[size]; }
};

main ()
{
  x *y = new x;
}
----------------------------------------

When compiled with CC 2.0 neither an error nor a warning is given:

----------------------------------------
% CC new.c
CC  new.c:
"new.c", line 5: warning: x  has x::operator new() but no operator delete()
/usr/gnu/gcc  -L/usr/public/lib/CC   new.c -lC

% a.out
size = 1
constructing x
----------------------------------------

Therefore, I'd be interested to know whether 2.0 simply doesn't fully
implement the current semantics of operator new or whether the
statement from the article is mistaken.

thanks,

  Doug
--
Any man's death diminishes me,              | schmidt@ics.uci.edu (ARPA)
Because I am involved in Mankind;           | office: (714) 856-4043
And therefore never send to know for whom the bell tolls;
It tolls for thee        -- John Donne