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

[Krzesimir Nowak <qdlacz gmail com>]

Hi,

I pushed to Glibmm repository my own branch called `vector' - it is just
my effort to create a vector handler which transforms C arrays, GLists
and GSLists into std::vector and vice versa. Not much new code there
really - I tried reusing already existing code as much as I could.

For now API looks something like this:

VectorType
VectorHandler::array_to_vector (const CType* array,
                                size_t array_size,
                                Glib::OwnershipType ownership);

VectorType
VectorHandler::array_to_vector (const CType* array,
                                Glib::OwnershipType ownership);

VectorType
VectorHandler::list_to_vector (GList* glist,
                               Glib::OwnershipType ownership);

VectorType
VectorHandler::slist_to_vector (GSList* gslist,
                                Glib::OwnershipType ownership);

ArrayKeeperType
VectorHandler::vector_to_array (const VectorType& vector,
                                Glib::OwnershipType ownership);

GListKeeperType
VectorHandler::vector_to_list (const VectorType& vector,
                               Glib::OwnershipType ownership);

GSListKeeperType
VectorHandler::vector_to_slist (const VectorType& vector,
                                Glib::OwnershipType ownership);

VectorHandler is a template and VectorType, CType,
{GList,GSList,Array}KeeperType are typedefs - for details look into the
code [1].

Potential use could be:

// C function returning a list of GBar* with no ownership transfer.
GList*
g_foo_get_bar (GFoo* stuff);

C++ wrapper:
std::vector<Glib::RefPtr<Bar> >
Foo::get_bar()
{
  return Glib::VectorHandler<Glib::RefPtr<Bar> >::list_to_vector
                                      (g_foo_get_bar (gobj()),
                                       Glib::OWNERSHIP_NONE);
}

The downside of current API is that methods using
{Array,List,SList}Handle could take both C++ containers and C arrays as
a parameter. Now methods can take only std::vector, so if we want to
handle also C arrays then an overload needs to be written.
Another one is probably unfriendly wrapping - more typing.

Of course - suggestions/criticisms are welcome.

But I still have some doubts. Some intro first:
Most common functions are the ones returning a container and the ones
taking container as a parameter. A function can have three types of
ownership transfer: deep, shallow and none. So in the end there are six
types:
1. function returning a container with full ownership transfer - that
means that caller owns both container and data it holds.
2. function returning a container with shallow ownership transfer- that
means that caller owns only container, data belongs to the function.
3. function returning a container with no ownership transfer - that
means that caller owns nothing.
4. function taking a container as a parameter with full ownership
transfer - that means that function takes ownership of both container
and data.
5. function taking a container as a parameter with shallow ownership
transfer - that means that function takes ownership of data only,
container still belongs to caller.
6. function taking a container as a parameter with no ownership transfer
- that means that function takes no ownership, both container and data
still belongs to caller.

There are also functions that take parameter, but treat it as a return
value - these are best wrapped by hand and are not covered here.

I am wondering if this taxonomy is alright - especially the last three
points. 4th and 5th points are a bit of trouble, because when converting
each element from C++ container to C type no copy/additional reference
is done (just look at to_c_type() method of TypeTraits struct). So if
such function frees/unrefs a C object, then C++ container potentially
holds wrappers of already destroyed objects. If so, the things will go
boom sooner or later.

Should I even care about the functions described in 4th and 5th
function? Aren't they buggy anyway? I believe the
{Array,List,SList}Handle are behaving that way too.

I'll be grateful for clarifications,
Krzesimir

[1]
http://git.gnome.org/browse/glibmm/tree/glib/glibmm/vectorutils.h?h=vector#n372