Daniel,

now it is clear. I didn't and still don't understand exactly how internal
data members are represented in the generated class (I have no access to my
code now) but the situation I have by returning a reference is clear. BTW
does it make sense to think about shared_ptr as returned value for getter?

-Pavlo Solntsev
---------------------------------------------------------------------------------------------

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
<http://www.gnu.org/philosophy/no-word-attachments.html>*

On Fri, Feb 23, 2018 at 8:42 AM, Daniel Boles <dboles....@gmail.com> wrote:

> > Basically, this is glibmm limitation for now.
>
> I can see no way that this is any fault or limitation of glibmm's. It is
> rather a simple fact of any language supporting reference semantics: You
> can't (safely, usefully) have a reference of a given type unless you have
> an instance of that type, with at least the same lifetime as that of the
> reference.
>
> You have a char* but want to return a Glib::ustring&; these are not
> compatible facts. So, the Glib::ustring must be created whenever requested,
> and returned by value. If you want to return a Glib::ustring&, keep a
> Glib::ustring somewhere, and use a reference to that.
>
>
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Reply via email to