From 4551582436636851347 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,1ac63fff730e7d59 X-Google-Attributes: gidf78e5,public From: postmast.root.admi.gov@iname.com (blargg) Subject: Re: C++ Memory Allocation Bashing Date: 1999/08/13 Message-ID: #1/1 X-Deja-AN: 512360871 X-NNTP-Posting-Host: as1-dialup-03.io.com Approved: stephen.clamage@sun.com (comp.std.c++) References: <37b445e8.82613572@news.airmail.net> X-UID: 0000000001 X-Status: $$$T X-Complaints-To: abuse@io.com X-Trace: hiram.io.com 934569794 9877 206.224.82.3 (13 Aug 1999 18:43:14 GMT) Organization: e-mail address IS valid - but fools the spammers NNTP-Posting-Date: 13 Aug 1999 18:43:14 GMT Newsgroups: comp.std.c++ Originator: clamage@taumet In article <37b445e8.82613572@news.airmail.net>, whbloodworth@usa.net wrote: > Hello, > > Would anyone (Bjarne preferably) care to comment the information presented on C++ memory > allocation at this location: http://www.pdos.lcs.mit.edu/~dm/c++-new.html ? I think it's best summed up at the end: > Moral of the story > > When a programing language doesn't support some necessary operation, one > shouldn't simply add new syntax for that specific operation. Instead, one > should ask, "How can I ammend the language to make this operation > implementable in a standard library?" The answer may be a much simpler, > cleaner, and more powerful set of mechanisms than the one tailored for a > specific problem. And when one is criticizing a feature of a language, they shouldn't ask "What would have been the ideal choice, given no constraints?". Instead, they should study its history and learn from it. > C++ needed a way to perform type-safe memory allocation. Such a scheme > could have been implemented entirely as a library function, given the > right support. Such support might have included ways to infer whether > classes have destructors at compile time, support for calling constructors > directly and even taking their addresses, and more. These features might > even have been useful in more contexts than memory allocation. I think new and delete were added very early in the language. At that time, I don't think there were the funds (people, money) to add these ambitious features. Would you rather have had that attempted on C++ then and have it not exist today (because it was too complex, and lead to more complexities that killed the language)? > Instead, Stroustrup introduced operator new, a disgusting piece of syntax > inadequate for the job. After many complaints, new's functionality was > finally extended to include per-class operator new[] and placement new, > still an imperfect solution. How I see it, this all centers around a feature that was added to the language for type-safety: constructors (and destructors). Technically it was also needed for setting up the vtable, but that isn't the main issue. 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. If you don't want to use this feature, then you don't have to (except for correctly placing objects to insure their vtable is set up). Perhaps it could have been done better if templates and exceptions existed at the time, but there are lots of things in C++ that could be done better. It would be nice if we had all the time in the world (and then some) for every decision, had all the funds we needed to try all possible choices, and didn't have to worry about compatibility (responsibility). I admire C++ for finding a good balance between this idealistic place and practical programming. [ 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 ]