>>>  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()')



>> 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



-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 4:02 AM, Kjell Ahlstedt <kjellahlst...@gmail.com>
wrote:

> 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?
>
> Kjell
>
>
> Den 2018-02-22 kl. 20:56, skrev Pavlo Solntsev:
>
> Thanks for comments.  My macroses:
>
>   _MEMBER_GET(name,name,const Glib::ustring&,const gchar*)
>   _MEMBER_SET(name,name,Glib::ustring,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());
> }
>
> Thanks.
>
> -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 Thu, Feb 22, 2018 at 12:34 PM, Daniel Boles <dboles....@gmail.com>
> wrote:
>
>> On 22 February 2018 at 18:32, Daniel Boles <dboles....@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.
>>>
>>
>> ...in 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
>> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>>
>>
>
>
> _______________________________________________
> gtkmm-list mailing 
> listgtkmm-list@gnome.orghttps://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