Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!att!dptg!pegasus!hansen From: hansen@pegasus.ATT.COM (Tony L. Hansen) Newsgroups: comp.lang.c++ Subject: Re: delete [] Summary: more on delete Keywords: C++, heap management Message-ID: <4956@pegasus.ATT.COM> Date: 5 Aug 90 12:51:36 GMT References: <641@atcmpe.atcmp.nl> <1990Jul27.231220.8396@cerc.utexas.edu> <4937@pegasus.ATT.COM> <4942@pegasus.ATT.COM> Reply-To: hansen@pegasus.ATT.COM (Tony L. Hansen) Distribution: comp Organization: AT&T Bell Labs NJ USA Lines: 45 < From: cimshop!davidm@uunet.UU.NET (David S. Masterson) < Hmmmm. If someone had developed X for an embedded system such that < X.new() allocates space for X in a special memory area, then X could never < "validly" be used in an array form because "new X[m]" would cause it to be < allocated in standard memory. Does anyone see a problem with this? < < Here too, if X only points to special memory, then everything is fine, but < if X was supposed to totally reside in a special area, then X could not be < allocated as an array. Does anyone see a problem with this? If you're developing such a class, then you do indeed have to be aware of the ins and outs of arrays. Be careful when you play around with "special memory segments"! < By the way, it is true that the delete() operator (global or class < specific) is called automatically after the destructor, right? (I'm still < working with a V1.2 compiler) By this, I mean that there isn't a need to < have the destructor call delete()? (Your later example confused me < slightly on this.) Sorry, I didn't mean to cause confusion. :-) You're correct: one of operator X::delete() or ::delete() IS called automatically after the destructor (~X()) when the variable is passed to the delete operator. Just to throw in another monkey wrench, it is possible to explicitly call X::~X() for an allocated variable; this is sometimes necessary when dealing with those "special memory segments" mentioned above. (This feature was introduced in the 1989 definition of the language, a.k.a. 2.0.) < Is this "size of the array" in the compiler's environment (in other words, < determined at compile time) or in the run-time environment (in other < words, somehow tacked onto the memory that is allocated)? There must be < plusses and minusses with either way. It's "typically" implemented using a run time tracking. (How do you define "typical" when very few compilers implement the feature? :-) ) I suppose it WOULD be possible for an implementation to keep track at compile time for SOME arrays, but that would be a matter of "quality of implementation" and is not a language issue. Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com