Am 2003.03.06 07:41 schrieb(en) "N. Lundblad, Peter":
> OK. I am working through the comp8le errors, and I am getting element.cc to
> build now. As an aside, the most interresting line was
> } /* namespace Element_Helpers
> which took some time to spot. (Note the missing */) Gave some interresting
> errors later...
> OK, you asked me to ask questions. So, could someone please clarify the
> plans regarding the use of smart pointers? When is the included RefPtr
> supposed to be used and when could we use Glib::RefPtr? (I know there is a
> FAQ, but I don't read German very well:-(
> Also, I noticed that many wrapped classes use
> so they will be represented by raw pointers in many cases? On the other
> hand, Element::get_element_factory() returns Glib::RefPtr<Elementfactory>,
> so I modified the ElementFactory class so it uses _CLASS_GOBJECT instead.
> Shouldn't we change, among others, Element to use the same? Then our wrapped
> gst_element_factory_make (and others) could sink the object before returning
> a GLib::RefPtr<Element>.
This is a difficult issue. There was quite some argument between Murray,
the maintainer of gtkmm, and myself about this. My point of view used
to be that as opposed to gtk+, gstreamer has quite a clean reference
counting system that allows for more flexibility in the language bindings:
Like in gtkmm it is technically possible for gstmm to leave it a user's
choice whether gstmm objects should
a) reside on the stack,
b) be allocated on the heap and destroyed manually (using delete),
c) be allocated on the heap and managed by a reference counting
system, i.e. destroyed automatically when their reference count
Unlike in gtkmm there is also the possibility to reference an object that
is marked for auto-destruction (option c) ) meaning that some gstmm
container referencing the object won't force the destruction of the object
as long as there are still other references. Handling these additional
references would be the point of Gst::RefPtr<elem>. Glib::RefPtr<elem>
can't be used for this approach because our functions would need to take
"elem*" while Glib::RefPtr<elem> only allows for "const Glib::RefPtr<elem>&"
(because Glib::RefPtr<elem> doesn't have operator*()).
Murray's argument is that it is
- simpler to code
- easier to understand for the user
using Glib::RefPtr<elem> throughout gstmm (which would only allow for c) ).
In fact he pointed out that he would do the same in gtkmm if it where not
for the fact that during destruction gtk+ containers _force_ destruction of
their children disregarding their reference count. gtkmm users knowing this
should be able to expect the same from gtkmm when they tell it to manage
the life time of their objects. (This behaviour is of course not compatible
with Glib::RefPtr<elem> which expects that the reference counter is used).
It is still not decided which approach ( a) + b) + c) or only c) ) we should
choose. Christian, who is our maintainer, had quite some work to
understand our different points (it took me some time to work them out,
too :) ) and therefore doesn't seem to have come to his own opinion, yet.
Probably we should sort this out before doing a lot of extra work in the end