Xref: utzoo comp.lang.c++:11160 comp.std.c++:533 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!lupine.ncd.com From: rfg@lupine.ncd.com (Ron Guilmette) Newsgroups: comp.lang.c++,comp.std.c++ Subject: Smart pointers and Stupid people (SUMMARY) Message-ID: <3347@lupine.NCD.COM> Date: 13 Jan 91 03:36:32 GMT Sender: rfg@NCD.COM Followup-To: comp.lang.c++ Organization: Network Computing Devices, Inc., Mt. View, CA Lines: 96 Well, I'm gratified that there has been so much discussion on this question of how to deal with the "smart pointer problem". At the very least this should indicate to all concerned that this is an important issue and is worthy of careful consideration (in particular by x3j16). To recap (for those of you who were sleeping) the "smart pointer problem" is just this: If you have a class type T and another class type smart_pointer_to_T there is currently no way in C++ to force all "pointers" to type T objects (except those within some limited contexts) to be smart_pointer_to_T type values rather than T* type values. It may somtimes be important to enforce such a restriction on T*, either because your garbage collection scheme requires it or for some other reason. The basic problem is to prevent values of type T* from "leaking" out of a certain region of your source code. Here is a (perhaps biased) summary of the highlights of the discuss so far. In a separate and subsequent message, I offer my own (definitely biased) analysis of the state of the discussion and consider yet another solution. --------------------------------- Marshall Cline really started this thread by mentioning a programming problem in which it would be useful to "ban" the use of stupid pointers (perhaps not entirely, but at least over some part of the code in a given program). I proposed a combination of new syntax/semantics to allow the programmer to say (in effect) that the use of values of type T* was restricted to only some certain limited lexical contexts. The idea rested on what I called "protected" class types. Subsequently I amended this proposal. After that, Marshall Cline (cline@cheetah.ece.clarkson.edu) proposed that the solution to this problem was already available within the current definitions of the C++ language, via the judicious use of nested classes. (More on this later). Then Robert C. (Bob) Martin (rmartin@clear.com) proposed an alternative to my proposal in which pointer types themselves would be allowed to be treated as classes, thus allowing class definitions like: class T* { ... } ; where the '...' could be replaced with constructors, destructors, type convertors, and all sorts of other data members, member functions, operators (including operator=) and what-not. Later on, Bob amended his proposal and cross-posted it to comp.std.c++ for additional comments. Henry J. Cobb (hcobb@ccwf.cc.utexas.edu) proposed simply making all of the constructors for the type T private so that they would be difficult to create at ramdom (unrestricted) places. (I assume that he also would suggest making the class smart_pointer_to_T a friend of type T so that at least smart_pointer_to_T could create T's.) Jeremy Grodberg (jgro@lia.com) also independently proposed the same thing that Bob Martin proposed (i.e. allowing T* to be declared as its own class type and to have operators and what-not defined for it. Jeremy Grodberg (jgro@lia.com) also noted that there is an important (and currently uncontrolable) source of "leakage" of regular pointers built-in to the current definition of the C++ language, i.e. doing a new() on an array of T's always returns a T* because the language rules say that new() for an array always uses the global new() rather than any class-specific new() operator. Andrew Ginter (gintera@cpsc.ucalgary.ca) suggested that any solution would have to take into account issues relating to pointers returned from functions, references (to pointers?), the `this' pointer, and temporaries generated during expression evaluation (even where their ordering of creation & destruction may not be known). Furthermore, he suggested that data members of class objects (which he refered to as "instance variables" in the Smalltalk tradition of nomenclature) could be a cause for concern if people were allowed to randomly take their addresses. It is apparent from this that Andrew G. is not aware of the (relatively new) C++ features with respect to "pointer-to-members". Tim Atkins (tma@osc.UUCP) seemed to feel that if you could not control *all* of the pointers to T everywhere in the program (and make them all the smart kind) then you would still have a problem. He also alluded to some (unspecified) problems which he believed might arise in the generated C code (because it might make use of T* values in uncontrolled ways behind the back of the C++ programmer). In particular, he seemed to feel that T* values might end up in registers, and that this could cause problems when and if a garbage collector needed to relocate the pointer at object(s). Piercarlo Grandi (pcg@cs.aber.ac.uk) said that the solution to this problem required a "capability" language and that C++ was not such a language. Jim ADCOCK (jimad@microsoft.UUCP) said that the solution to this problem required a new set of features relating to "metaclasses".