🚀 go-pugleaf

Distribution:
On the second question, I received a very good reason why it shouldn't be
legal,
from Johan Wikman (thanks!). Here it is:

>My question:
> 2. what is the reason for this restriction, or rather, is there any reason to
>    keep this restriction (apart from the fact that a DerviedObject*& bears no
>    inheritance relationship to an Object*&) ?

|Johan's response:
|
|Here's one good reason.
|
|	class Object {};
|	class DerivedObject {};
|
|	void function(Object*& o)
|	{
|	   o = new Object;
|	}
|
|	void anotherFunction()
|	{
|	  DerivedObject* do;
|
|	  // If what you want would be allowed...
|
|	  function(do);
|	
|	  // ... we would here have something that would walk,
|	  // feel and look like a DerivedObject although it
|	  // only is an Object.
|	}
|

This should clarify the matter, as it answers also to question #1 and #3.
Note that there is a solution to writing the GrabPointer function,
which uses templates. Here it is:

template<class SomeDerivedObject>
void GrabPointer(SomeDerivedObject*& object)
{
   Object* obj = object;
   object = 0;
   // work with obj ...
}

Borland 4.5 compiles and executes this correctly (I know, this doesn't prove
anything, but it's much more comfortable!).

jean-rene bouvier


---
[ 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. ]