Re: get/set wrap methods.

Your concern is justified. The Glib::ustring must be returned by value. The _MEMBER_GET should be

  _MEMBER_GET(name, name, Glib::ustring, const gchar*)

Your _MEMBER_SET macro doesn't seem to fit the generated code that you show. I would think that
  _MEMBER_SET(name, name, const Glib::ustring&, gchar*)
would generate that code. In this case a reference is OK, but it looks like the generated code can cause a memory leak. Who owns the duplicated string? Who deallocates it? What if gobj()->name contains a pointer to a string when set_name() is called?


Den 2018-02-22 kl. 20:56, skrev Pavlo Solntsev:
Thanks for comments.  My macroses:

  _MEMBER_GET(name,name,const Glib::ustring&,const gchar*)

the generated code :
const Glib::ustring& DsnInfo::get_name() const
  return Glib::convert_const_gchar_ptr_to_ustring(gobj()->name); // This is my concern. it looks like we return ref for temp object

void DsnInfo::set_name(const Glib::ustring& value)
  gobj()->name = g_strdup((value).c_str());


-Pavlo Solntsev
Please avoid sending me Word or PowerPoint attachments.

On Thu, Feb 22, 2018 at 12:34 PM, Daniel Boles <dboles src gmail com> wrote:
On 22 February 2018 at 18:32, Daniel Boles <dboles src gmail com> wrote:
also, I don't see how RefPtr is relevant to the given example struct; it's only for Glib::Object instances, i.e. things that themselves wrap GObjects, as RefPtr is implemented via GObject refcounts. the currently stable glibmm, at least. Beyond that, in the next release, it'll be an std::shared_ptr, layering a different layer of refcounting over GObject's own.

but the point stands: what would a RefPtr to a char* or any other simple property type even mean? They should just be returned by value, not by reference.

gtkmm-list mailing list
gtkmm-list gnome org

gtkmm-list mailing list
gtkmm-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]