[openbeos] Re: Pointer or reference?
- From: Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 31 Mar 2004 16:37:51 -0500
On 2004-03-31 at 16:12:36 [-0500], Scott MacMaster wrote:
> > >Unfortunately, the BeAPI adds more places where pointers must be used
> mainly
> > >because some BeAPI objects delete themselves (why anyone would make
> objects that
> > >behave like that is beyond me).
> >
> > Actually, this is a good thing. Other environments work too like this. In
> delphi, for example, objects delete themselves if they are part of a visual
> hierarchy. Otherwise you would have to keep track of all the objects
(mostly
> views) you add (or keep a pointer to them in the parent class, which isn't
> needed, since you can use FindView() instead).
>
> First, I would not want my objects to automatically be destroyed when they
> are removed from the hierarchy, because I may want to use the object
> somewhere else.
There are ways around it. Specifically removing your object from the
hierarchy before the object is destructed will do it. It is provided as a
service. It is bad enough that we have to write code to explicitly allocate
every single GUI widget. Deleting them explicitly, too, just piles code on
top of code.
> I'm not familiar with these other API's, however I still say it's a bad
> thing. For one thing it forces you C++ differently then it was intended.
> Objects you explicitly allocate memory for should be explicitly
deallocated.
> The biggest issue this introduces, is that you can't trust any pointer to
the
> object.
Not at all. People write code all of the time that hands control of an object
over to some other class.
> You would have to manually destroy objects you created dynamically. Which,
> of course could be done by using FindView() or a stored pointer. For, the
> few cases where it would be more convenient to create a object dynamically
it
> would also be more convenient to store the pointer rather then repeated use
> if FindView(). For the majority of the time your could just create objects
> on the stack and they will be implicitly destroyed when the parent is
> destroyed.
IIRC, there is a huge issue with R5 and static object creation of GUI
components. I don't think you can do it (but I am going on a vague memory and
not enough sleep). That would be a good thing to fix - it would make a lot of
stuff easier.
> The only time where automatic deletion of any kind is ok is in garbage
> collection.
Eh. I disagree.
Other related posts:
