Den 2018-02-23 kl. 15:36, skrev Pavlo Solntsev:
>>> Your concern is justified. The Glib::ustring must be returned by
value. The _MEMBER_GET should be
It is interesting. getter must return by value....
>>> 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*)
from https://github.com/GNOME/glibmm/blob/master/tools/m4/member.m4
My understanding that the generated type will be const T& if T is
provided to the macros.
dnl Creates accessors for simple types:
define(`_MEMBER_SET',`dnl
ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_START ')dnl
void set_$1(const $3`'& value);
ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_END ')dnl
_PUSH(SECTION_CC)
ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_START ')dnl
void __CPPNAME__::set_$1(const $3`'& value)
{
gobj()->$2 = _CONVERT($3,$4,`value');
}
ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_END ')dnl
_POP()')
Sorry, I was wrong. _MEMBER_SET(name, name, Glib::ustring, gchar*)
does generate the code you showed.
>> 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?
Basically once again, return by value. What would be the correct wrap
for the simple struct? Wrap struct and manually wrap set/get method?
I will investigate how private members are stored and how they related
to the original C struct. Thanks
In Glib::OptionEntry, _MEMBER_SET is not used for strings. Those methods
are hand-coded to avoid a memory leak. Example:
void OptionEntry::set_long_name(const Glib::ustring& value)
{
if (gobject_->long_name)
{
g_free((gchar*)(gobject_->long_name));
gobject_->long_name = nullptr;
}
gobj()->long_name = (value).c_str() ? g_strdup((value).c_str()) :
nullptr;
}
Don't ask me why value.c_str() is tested for nullptr. I don't
understand. I don't think it can ever be a nullptr. And even if it is,
g_strdup() can handle that.
-Pavlo Solntsev
_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
