Re: RFC: Building temporary char** property arrays

From: Ben Martin <monkeyiq_at_users.sourceforge.net>
Date: Wed Dec 15 2010 - 13:05:23 CET

On Tue, 2010-12-14 at 19:15 +0100, Ingo Brueckl wrote:
> Hi,
>
> Ben Martin wrote on Sat, 11 Dec 2010 09:51:23 +1000:
>
> > somethingThatWantsArrayOfCharPointers(ppAtts);
>
> > Where ppAtts is a NULL terminated list of pointers to char* which are
> > not duplicated/freed. ie, const strings or std::string::c_str() where
> > the string object lasts beyond the scope that ppAtts is required for.
>
> I'm not that C++ whizz so I was wondering why? Won't be all freed when the
> function the somethingThatWantsArrayOfCharPointers(ppAtts); is in ends?

Well, the ppAtts array itself will be. The gchar* you set in the array
will not. Which is normally what you want as you are doing
a[0] = ID_FOO;
a[1] = "some data";
a[2] = ID_BAR;
a[3] = mystring.c_str();
a[4] = 0;

So you don't want to free() any of these gchar* values that are in the
array a[]. The function somethingThatWantsArrayOfCharPointers(ppAtts)
will have made copies for itself and not want/need to know about ppAtts
after returning.

I also had a look at UT_GenericVector and it's subclass UT_PropVector
for this use case. Using UT_PropVector means that strings are copied
when inserted and freed when removed. Though if you are only wanting an
array of strings that you know are going to be in scope for the life of
the array, copying the strings seems like wasted overhead here.

As an aside, I'm still looking into how a UT_PropVector handles RAII for
it's string copies. With no destructor it seems that any properties you
leave in the UT_PropVector at destruction time might leak without an
explicit UT_VECTOR_FREEALL() ?

There is also the issue that to use UT_PropVector or a subclass for
these temporary char** arrays, you would need access to m_pEntries to
get a data() method so you have the expected char** to pass to
somethingThatWantsArrayOfCharPointers. Not a huge issue, but m_pEntries
is currently private rather than protected.

Received on Wed Dec 15 13:05:43 2010

This archive was generated by hypermail 2.1.8 : Wed Dec 15 2010 - 13:05:43 CET