From 3674306405092542622
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,1ac63fff730e7d59
X-Google-Attributes: gidf78e5,public
From: Lisa Lippincott <lisa_lippincott@advisories.com>
Subject: Re: C++ Memory Allocation Bashing
Date: 1999/08/20
Message-ID: <190819991707306215%lisa_lippincott@advisories.com>#1/1
X-Deja-AN: 515130063
X-NNTP-Posting-Host: 38.168.253.3
Content-Transfer-Encoding: 8bit
Approved: stephen.clamage@sun.com (comp.std.c++)
References: <37b445e8.82613572@news.airmail.net> <user-1308991347430001@as1-dialup-03.io.com> <130819991418375734%lisa_lippincott@advisories.com> <37B7CC14.54D1E823@lucent.com> <170819991525097118%lisa_lippincott@advisories.com> <37BBB3FB.D69D31E2@lucent.com>
Content-Type: text/plain; charset=Macintosh
X-Trace: client 935107428 38.168.253.3 (Thu, 19 Aug 1999 20:03:48 EDT)
Organization: -
Mime-Version: 1.0
User-Agent: YA-NewsWatcher/4.2.2
NNTP-Posting-Date: Thu, 19 Aug 1999 20:03:48 EDT
Newsgroups: comp.std.c++
Originator: clamage@taumet


Fed up with the problems involved in writing operators new, I suggested
that a type storage_for<Foo>, representing uninitialized storage
suitable for Foo, would ease the difficulties.

I wrote:
> There would be implicit conversions from Foo* to storage_for<Foo>*
> and from Foo& to storage_for<Foo>&; these could be reversed with a
> static_cast.

Salters <salters@lucent.com> objected:
> Not only do the static_casts break invariants, but the implicit
> conversions would do that, too. The invariant broken is that
> Foo* may point to memory that no longer is a Foo. What happens
> with void f(storage_for<Foo> * arg1)? It could conceivably clobber
> arg1 (Imagine what happens if new(arg1) throws).

You're right; in that, for example, this code:

    void f( storage_for<Foo> *arg1 )
       {
        new (arg1) Foo(17);
       }

    void g()
       {
        Foo x( 12 );
        f( &x );
       }

The destructor of x is not called before the new-expression ends
its lifetime.  While unusual, this is defined behavior (see 3.8,
[basic.life]).

The same defined behavior happens in this function:

    void f( Foo *arg1 )
      {
       new (arg1) Foo(17);
      }

On the other hand, while this unfortunate function is legal:

    void f( Foo *arg1 )
      {
       new (arg1) int(17);
      }

under my proposal, this function would produce a compile-time error:

    void f( storage_for<Foo> *arg1 )
      {
       new (arg1) int(17);
      }

So I don't see how invariants are harmed by the introduction
of storage_for.  The language already leaves lifetime management
to the programmer when placement new and explicit destructors
are used.

                                                --Lisa Lippincott


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]