Mark E. Pennell (mpennell@jetstream.com) wrote:
|> I am looking for a method of implementing a pointer variable that will
|> automatically delete itself as it goes out of scope to allow for safer
|> function exits.

|> For instance,

|> void foo()
|> {
|>    CMe* myself = new CMe;
|>    .
|>    .
|>    .
|>    .
|>    .
|>    // t is automatically deleted at function exit
|> }

This sounds exactly like the standard auto_ptr class.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

Mark E. Pennell (mpennell@jetstream.com) writes:
> I am looking for a method of implementing a pointer variable that will
> automatically delete itself as it goes out of scope to allow for safer
> function exits.
>
> For instance,
>
> void foo()
> {
>    CMe* myself = new CMe;
>    .
>    .
>    .
>    .
>    .
>    // t is automatically deleted at function exit
> }
>
> Here is my first idea:
>
> (1) Derive all of my objects from a common base class, such as
> CObject.
> (2) Create a template-based class taking the specific pointer
> (3) Have a member that returns the specific pointer
> (4) Delete the associated pointer when on destruction
>
> The use would appear as follows:
>
> void foo()
> {
>    // constructor stores CObject pointer
>    CRefObject<CMe*> myself (new CMe);
>    .
>    .
>    myself.p->Employ();
>    .
>    .
>    // when myself destructs, it calls delete on the CMe*
> }
>
> Am I on the right track?  Any better, easier or more elegant
> solutions?
>
> Thanks,
> mark
>

   The Borland C++4.5 compiler implements a TPointer<PtrTYPE *>
class that deletes the ptrTYPE instance when the template type is assigned to
NULL. It still can't be used for arrays though so it may introduce more errors
than it fixes.
--
Bill Royds           az915@freenet.carleton.ca     CLBRR
Ottawa, Ontario      ROYDSW@EM.agr.ca          Scientific Software Support
                              C.L.B.R.R. Ag Canada has no opinion on this

I am looking for a method of implementing a pointer variable that will
automatically delete itself as it goes out of scope to allow for safer
function exits.

For instance,

void foo()
{
   CMe* myself = new CMe;
   .
   .
   .
   .
   .
   // t is automatically deleted at function exit
}

Here is my first idea:

(1) Derive all of my objects from a common base class, such as
CObject.
(2) Create a template-based class taking the specific pointer
(3) Have a member that returns the specific pointer
(4) Delete the associated pointer when on destruction

The use would appear as follows:

void foo()
{
   // constructor stores CObject pointer
   CRefObject<CMe*> myself (new CMe);
   .
   .
   myself.p->Employ();
   .
   .
   // when myself destructs, it calls delete on the CMe*
}

Am I on the right track?  Any better, easier or more elegant
solutions?

Thanks,
mark

Mark E. Pennell (mpennell@jetstream.com) wrote:
: I am looking for a method of implementing a pointer variable that will
: automatically delete itself as it goes out of scope to allow for safer
: function exits.
[...]

Here is something I would try:

template <class T> class Pointer
{
private:
  T *ptr;
  bool own;
public:
  Pointer(): ptr(new T), own(true)   {}
  Pointer(T *p): ptr(p), own(true)   {}
  Pointer(Pointer const &p): ptr(p.ptr), own(false) {}
  ~Pointer()   { if (own) delete ptr; }

  Pointer &operator= (Pointer const &p)
  {
    if (this != &p)
    {
      if (own) delete ptr;
      ptr = p.ptr;
      own = false;
    }
    return *this;
  }

  T *operator-> () const { return ptr; }
  T &operator*  () const { return *ptr; }
};

Notes:
1. a default constructor is assumed for T
2. it is assumed that 'ptr' is allocated with 'new T(..)' or 'new T'
   but not with 'new T[...]' or something like this.
3. Obviously pointer arthmetic is not supported.
4. if assignment and copy construction is not needed the additional
   bool can be dropped. In this case the assignment operator and the
   copy construction should be made private.

dk
--
http://www.informatik.uni-konstanz.de/~kuehl
dietmar.kuehl@uni-konstanz.de
I am a realistic optimist - that's why I appear to be slightly pessimistic