On Wed, 2009-11-25 at 10:24 +0000, Chris Vine wrote: > On Wed, 25 Nov 2009 01:04:06 -0500 > José Alburquerque <[email protected]> wrote: > > On Tue, 2009-11-24 at 17:05 -0500, José Alburquerque wrote: > > > The problem is that your trying to initialize a Glib::RefPtr<>& > > > from a Glib::RefPtr<> (which the std::list<> contains). A > > > std::list<> is not designed to store references. > > > > It doesn't seem clear what I was trying to say about lists not > > "storing" references. I guess what I was trying to say is that I > > think trying to extract a reference by dereferencing a > > list<>::iterator is not doable. I was also trying to suggest another > > way get at the contents of the list. > > You would expect std::list<T>::iterator::operator*() to return a > reference rather than a value type (it does on my version of libstdc++), > so it shouldn't fall foul of the preclusion of binding a temporary to a > non-const reference. > > Isn't the explanation simply that Glib::RefPtr<Gst::MixerTrack> and > Glib::RefPtr<Gst::MixerTrack const> are different types (as they are)? > > Glib::RefPtr<Gst::MixerTrack const> track = *iter (ie instantiating a > new RefPtr object rather than a reference) should work because it will > cause the templated version of the RefPtr's copy constructor to be > invoked, which will allow implicit conversion of the RefPtr's value > type.
Ah yes, that's right. I don't know why I didn't see it in my testing of the code the OP posted. It is possible to do: Glib::RefPtr<...>& var = *iter; in the loop as long as the types aren't mixed. So as you say dereferencing an iterator does in fact give back a reference. -- José _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
