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

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

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

take_list_all (GList* list);

take_list_members (GList* list);

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

And their wrappers (also commented out):

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

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

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

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