Just submitted a patch for a macro to generate setter for char* member in consistent way. Please review. https://bugzilla.gnome.org/show_bug.cgi?id=793778
-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 10:12 AM, Pavlo Solntsev <pavlo.solnt...@gmail.com> wrote: > Perfect! Now I understand the methodology to implement setter for a > structure. Do you think it would make sense to have a macro for this? Say, > _MEMBER_SET_CHAR. > > -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 9:43 AM, Kjell Ahlstedt <kjellahlst...@gmail.com> > wrote: > >> 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 gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
