From -516401543573150440 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,1ac63fff730e7d59 X-Google-Attributes: gidf78e5,public From: Lisa Lippincott Subject: Re: C++ Memory Allocation Bashing Date: 1999/08/14 Message-ID: <130819991418375734%lisa_lippincott@advisories.com>#1/1 X-Deja-AN: 512556931 Content-Transfer-Encoding: 8bit Approved: Fergus Henderson References: <37b445e8.82613572@news.airmail.net> X-Original-Date: Fri, 13 Aug 1999 14:18:37 -0700 Content-Type: text/plain; charset=Macintosh X-Complaints-To: news@news.unimelb.edu.au X-Trace: izvestia.its.unimelb.edu.au 934619229 1710 128.250.29.17 (14 Aug 1999 08:27:09 GMT) Organization: - X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUAN7UoQuEDnX0m9pzZAQG3OQGAjpdnIH4LnQBESxTC9PEJh4X5fHRTh+lg hso9SxIGTggB+VD0TQ66bv3pmOyMN1Ko =HF8o Mime-Version: 1.0 User-Agent: YA-NewsWatcher/4.2.2 NNTP-Posting-Date: 14 Aug 1999 08:27:09 GMT Newsgroups: comp.std.c++ blargg wrote: > With constructors and destructors, simply allocating memory and saying > "this memory is now a Foo" with a simple cast was not enough. Also, the > type hole (void* to anything) was there. Operator new filled this hole, > and allowed a way to put an object into raw memory. Thereby triggering the following rant... While I'm quite fond of the way constructors and destructors work, C does have a facility that C++ lost in this transition. In C, we have a name for "uninitialized storage suitable for Foo" -- we call it "Foo." Whenever I've gotten down to the level of writing operators new, I've been disappointed with C++'s limitations in dealing with uninitialized storage. In particular, I've often wished for a type storage_for to fill this gap. Here's how it would work: storage_for would have the same size and alignment as Foo. It would have public default and copy constructors, a copy assignment operator, and a destructor, none of which have any effect. There would be implicit conversions from Foo* to storage_for* and from Foo& to storage_for&; these could be reversed with a static_cast. Placement and member operators new would be allowed to return storage_for* rather than void*; such operators could only be used to allocate objects of exact type Foo, and (unlike ordinary allocation functions) need only return storage suitably aligned for Foo. Placement and member operators delete would be required to take a parameter of storage_for* rather than void* if the corresponding operator new returns storage_for*. I think that all instances of using such an operator to deallocate an object that does not have exact type Foo could be caught at compile time. Finally, these function templates would be added to : template < typename T > storage_for *operator new( size_t, storage_for *p ) throw() { return p; } template < typename T > void operator delete( storage_for *, storage_for * ) throw() {} I think that this change would make working with type-specific allocation both easier and safer. For general purpose allocation, there's the thornier problem of "storage suitably aligned for any type." I'll leave that for another day. --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 ]