aaron@rruxh.UUCP (Akman) (06/08/90)
Another question: In section 5.5.7 it says you have to keep state in your objects to know if they were created on the free store or on the stack to know whether to invoke delete. Is this still the party line? Is that how it's going to be? -- ----------- Aaron Akman, 201-699-8019, bellcore!rruxh!aaron, RRC 4D-728
mat@mole-end.UUCP (Mark A Terribile) (06/10/90)
> In section 5.5.7 it says you have to keep state in your objects to > know if they were created on the free store or on the stack to know > whether to invoke delete. Is this still the party line? Is that > how it's going to be? A different request along the same line: since a class with a destructor implements the delete operator by calling the destructor and having the destructor call operator_delete() , could a way be found to get information from the destructor into the parameter list for operator_delete() ? It's possible to fake it by having the destructor store the this pointer and some other info in member statics and having the operator_delete() check whether it's deleting that region, but the technique is ugly (to say the least) and is certainly not re-entrant. An object ought to be able to record the `arena' from which it was allocated. The conceptual problem is that when operator_delete() is invoked, there is no longer an object because the type has been stripped; all that is left is a region of memory. I'm not prepared to suggest a syntax, but it ought to be possible. -- (This man's opinions are his own.) From mole-end Mark Terribile
jimad@microsoft.UUCP (Jim ADCOCK) (06/12/90)
While it would seem natural to center debates on what C++ is or isn't around Stroustrup's 1986 text "The C++ Programming Language," as it was natural to center debates on what "C" was around the K&R text, please do not do so. While "The C++ Programming Language" is still a good and useful text, as a language reference it is way out of date, and is due for an update. Until then, please base debates on what C++ is or isn't on ideally: 1) Ellis & Stroustrup "The Annotated C++ Reference Manual" or as a second choice: 2) The AT&T C++ Language System Product Reference Manual [release 2.0 or better] or as a third choice on a widely available popular reference: 3) Lippman "A C++ Primer" Using Stroustrup's 1986 text as a basis for language is/isn't arguments resurrects the last four years of notes debates. Please work from an up-to-date reference instead!