Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!emory!att!dptg!pegasus!hansen From: hansen@pegasus.ATT.COM (Tony L. Hansen) Newsgroups: comp.lang.c++ Subject: Re: delete [] Keywords: heap management and arrays Message-ID: <4961@pegasus.ATT.COM> Date: 7 Aug 90 15:18:10 GMT References: <641@atcmpe.atcmp.nl> <1990Jul27.231220.8396@cerc.utexas.edu> <4937@pegasus.ATT.COM> <4942@pegasus.ATT.COM> <4956@pegasus.ATT.COM> hansen@pegasus.ATT.COM (Tony L. Hansen) writes: <<< 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? << << 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"! < < You didn't answer the question !-) Perhaps you missed the point of the < question (nah! ;-). Obviously, by the current definition of the language, < there are some gotchas with the scenario above, but the question is should < those gotchas exist? Why? There really are two ways of looking at the original question above: from the point of view of someone who wishes to use a particular language feature and needs to know the ins and outs for doing so, and from the point of view of someone who wishes to pick on the language itself. Since this discussion started out in the context of the first set of people, my response above was aimed at that set. YES, it is reasonable to consider enhancements to the current definition such that allocation of arrays could be better managed for use in "special memory segments". Start up a discussion in comp.std.c++ if you wish to discuss such extensions. << 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 a trick to deal with the above? Should a language consider a < special trick for not too-special cases a language "feature"? Wait a sec < (looking at above a little more cross-eyed), how would the explicit call < to X::~X() work for this case?? The availability of X::~X() permits a function to destruct an object without it invoking X::delete() or ::delete(). This is particularly useful for a class whose objects have been allocated using "alternate" allocation schemes, such as when using X::new() with extra arguments. <<< There must be plusses and minusses with either way. <<< [of tracking array sizes] << 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. < < Why SOME arrays? The information is there at compile time for all arrays, < isn't it? (NOTE: I didn't say pointers to arrays.) I think the "quality" < belongs more in the definition of the language than the implementation. No, the information is NOT there at compile time for all arrays that get passed to ::delete(). When you use ::new() to allocate an array, you get a pointer back. If you pass that pointer on to another function which winds up doing the delete[], HOW is that function going to know the number of elements to delete? For this case you HAVE to have run time information. Whether that size information is passed via a tagged pointer, or the size info is kept in a separate table, or the size info is kept in the heap arena next to the object itself, or wherever, the info can only be accessed at run time in order to delete the array. Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com