🚀 go-pugleaf

Jean-Rene Bouvier <jr@isoit109.bbn.hp.com> wrote:
>In a number of libraries, the following trick is used to denote the acquisition
>of a pointer and to make it inaccessible to callers:
>
>   void GrabPointer(Object*& object)
>   {
>       Object* obj = object;
>       object = 0;
>       // Now, work with obj ...
>   }
>
>Callers who pass pointers to GrabPointer() will not be able - upon return from
>the function - to access the object the pointer used to refer to.
>
>This nice trick is defeated in presence of inheritance; i.e. if instead of
>passing an Object*, the caller wants to pass a DerivedObject*, a compilation
>error should be issued (at least, this is my understanding, and this is also
>what Borland 4.5 and HP 3.5 compilers do).
>
>This is very unfortunate, and it also makes the use of references to pointers
>counter-intuitive: after all, if a reference hadn't been used, passing a
>DerivedObject* would have been perfectly legal.

   Nope. The conversion

   DerivedObject* --> Object*

is an RVALUE conversion. The resultant Object* is an rvalue.
You cannot bind a non-const reference (argument) to an rvalue.

Think about it -- setting the a pointer variable (lvalue) known as an

   Object*

to some value inside the function, when the caller knew it as
an DerivedObject* variable, would require an adjustment to the pointer
in the general case: the called function cannot know that and the
generated code would be a simple register store operation.
The resultant value would not be usable in the callers environment.
Basically, a DerivedObject* is NOT derived from an Object*.

Solution -- overloading:

      void GrabPointer(DerivedObject *& x) {
            Object *o = x;
            GrabPointer(o);
            if(!o) x = 0;
      }
 
[you might even try a template :-]


-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au



[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]