Re: Controlling the hardware volume

[José Alburquerque <jaalburquerque cox net>]

On Wed, 2009-11-25 at 10:24 +0000, Chris Vine wrote: 
> On Wed, 25 Nov 2009 01:04:06 -0500
> José Alburquerque <jaalburquerque cox net> 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é