Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!van-bc!ubc-cs!alberta!alberta!cpsc.ucalgary.ca!news
From: gintera@fsd.cpsc.ucalgary.ca (Andrew Ginter)
Newsgroups: comp.lang.c++
Subject: Re: Smart Pointers - Another Proposal
Message-ID: <1991Feb11.155122.22472@cpsc.ucalgary.ca>
Date: 11 Feb 91 15:51:22 GMT
References: <1991Feb5.021414.22979@cpsc.ucalgary.ca> <3783@lupine.NCD.COM> <1991Feb8.212951.6212@cpsc.ucalgary.ca> <3813@lupine.NCD.COM>
Sender: gintera@cpsc.ucalgary.ca
Organization: U. of Calgary Computer Science
Lines: 25
Nntp-Posting-Host: fsd

In article <3813@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>In current examples of C++ code using "smart pointers" (such as those in
>some of Stroustrup's papers on the subject) each smart pointer class does
>define an operator* and an operator-> and these operators typically return
>values of type `T&' (where `T' is the controlled class).  That however would
>constitute a serious leakage of `dumb' reference values under my proposed
>scheme.  Under my scheme, you would want to AVOID defining any public member
>functions which yield dumb pointer values or dumb reference values.

This sounds workable.  You should note that while this approach does
not require most datae members of a "smart" class to be private, those
members may as well all be private, because they cannot be directly
accessed by saying something like "X -> a = 3".

My biggest remaining complaint with the proposal is that there is a
fair amount of work to be done on the part of smart class/smart
pointer designers.  Member functions must be implemented for the smart
class and a calling interface must be provided in the smart pointer
class.  Smart pointers must implement conversion operators so that
pointers to derived classes can be converted to pointers to base
classes.  And implementors of smart class member functions must code
very carefully to avoid creating dumb pointers which might survive a
garbage collection.

Andrew Ginter, 403-220-6320, gintera@cpsc.ucalgary.ca