Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!uunet!dlogics!jmd
From: jmd@dlogics.COM (Jens M. Dill)
Newsgroups: comp.std.c++
Subject: Re: Asymmetry: "new (placement) T"  vs. "Tptr->~T"
Summary: Sometimes I can't see what's in front of my nose.
Keywords: placement new delete constructor destructor template
Message-ID: <623@dlogics.COM>
Date: 31 Aug 90 16:40:06 GMT
References: <620@dlogics.COM>
Organization: Datalogics Inc., Chicago
Lines: 56

In article <620@dlogics.COM>, I wrote:
> Is anyone else bothered by the inherent asymmetry in the application of
> constructors and destructors to an object that is to reside in a known
> memory location?  ...

  ... many more lines ...
 
> Possible fixes:
> 
> 1.  (deleted)

> 2.  Make it legal to explicitly invoke a destructor for any type T, whether
>     or not it has one.  Invocations of the form "Tptr->~T" where T is a
>     primitive type or the name of a class without a destructor would do
>     nothing.  This solves the problem, even though it retains the asymmetry.
 
> 3.  (deleted)
 
  ...

I recieved the following answer by e-mail from Jeremy Grodberg: 
: I am unable to post to the net, you may post this or incorporate it in
: something you post, if you like.
: 
: According to E&S 12.4 (page 280):
: 
: 	Using the notation [for explicit call of a destructor] for a type that
: 	does not have a destructor has no effect.  Allowing this enables people
: 	to write code without having to know if a destructor exists for a
: 	given type.
: 	
: So I think what you need is a conforming compiler (which AT&T CFront 2.0
: does not seem to be), rather than a change to the standards.
: -- 
: 
: Jeremy Grodberg
: jgro@apldbio.com    "Beware: free advice is often overpriced!"

It turns out that I had my copy of E&S sitting ON MY DESK, open to that VERY
PAGE.  Thanks, Jeremy, for calling my attention to it.  Sometimes, free advice
is worth more than its price would have you believe.  

But what is this about CFront 2.0 being non-conforming?  2.0 predates E&S,
so I'd expect certain things in E&S to be of the implemented-in-2.1-but-not-
in-2.0 variety.  Are you trying to tell me this is one of them?  If so,
thanks again.  My only criticism of E&S so far is that it does not make it
clear which releases of Cfront support which features (I know that Cfront
is not supposed to be anything but one among many compilers for C++, but
it IS the de facto industry standard, and things like "compatible with
Cfront x.xx" have meaning in the real world: a meaning that is sometimes
rard to correlate with E&S).

*=====* TIME CANNOT BE WASTED *=====*       -- Jens M. Dill
 \ But it can be used for purposes /           jmd@dlogics.com
  \ other than what was intended. /
   *=============================*