Re: Move from {Array,List,Slist}Handle to std::vector.

[Krzesimir Nowak <qdlacz gmail com>]

2011/1/19 Murray Cumming <murrayc murrayc com>:
> On Wed, 2011-01-19 at 12:29 +0100, Krzesimir Nowak wrote:
>> What I meant there is that functions returning a container (1st to 3rd points)
>> like the one below indeed do not pose a problem:
>
> I don't quite understand. I guess I'd need to see a real example.

I'm sorry, maybe I'm seeing a problem when there is simply none or it is not
relevant.



Sort of real example is in glibmm_vector test. I hope your eyes won't bleed when
you see this awful code... I'll refactor it, when vector stuff is settled.



Functions (now commented out):

void
take_list_all (GList* list);

void
take_list_members (GList* list);

http://git.gnome.org/browse/glibmm/tree/tests/glibmm_vector/main.cc?h=vector#n237

These functions assume that they take respectively deep and shallow
ownership of passed GList*. So, if they are taking an ownership of
data, they can do
what they want with it - here they just print some informations about
them and free them
afterwards.


And their wrappers (also commented out):

void
cxx_list_take_all (const std::vector<...>& v);

void
cxx_list_take_members (const std::vector<...>& v);

http://git.gnome.org/browse/glibmm/tree/tests/glibmm_vector/main.cc?h=vector#n484

They were trying to wrap the C functions, but they fail because when
creating a GList*
from std::vector (see: create_glist2 () in vectorutils.h), the
TypeTraits::to_c_type (const CppType& ptr) method
calls Glib::unwrap (), which does not create a new copy (or add a new
reference if it
is a GObject), so the C functions destroy the original data (or unref
the last reference).
Question is where the problem lies:
1. Are C functions badly designed because they should never take an
ownership of data
passed to them? If so, then there is no problem on our side.
2. Or is my vector handler wrong?
>
> --
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com
>
>