Re: RFC: Building temporary char** property arrays

Resurrecting an old thread from 2010

On 10/12/10 06:51 PM, Ben Martin wrote:
> Hi,
>   I notice a fair bit in some parts of Abiword that I'm hacking on code
> like the following:
> const gchar* ppAtts[10];
> int i=3D0;
> ppAtts[i++] =3D PT_REVISION_ATTRIBUTE_NAME;
> ppAtts[i++] =3D "foo";
> ppAtts[i++] =3D 0;
> somethingThatWantsArrayOfCharPointers(ppAtts);
>=20
> 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.
>=20
> I was thinking of replacing some / phasing in the use of boost::array
> for these. The gains being that the allocation of the array on the stac=
k
> is retained, explicit null termination becomes optional, and the "top"
> array index can be maintained by the class for you (avoiding i++ in the
> above). So the code becomes something like this:=20
>=20
> propertyArray<> ppAtts;
> ppAtts.push_back( PT_REVISION_ATTRIBUTE_NAME );
> ppAtts.push_back( "foo" );

I have a few large patches right now against trunk that do mostly this.
Note that I just found by a pure coincidence this original RFC after I
spent a few day doing it, so, great mind think alike.

This is filed as bug http://bugzilla.abisource.com/show_bug.cgi?id=3D1376=
9

I have a class PP_PropertyVector which is currently just a typedef to
std::vector<std::string>

> // optional
> ppAtts.push_back( 0 );

Given that these are std::string, you don't want to do that. nullptr
isn't valid for construct a std::string.

Also since C++11 is now the standard, you can do:

PP_PropertyVector atts =3D {
	PT_REVISION_ATTRIBUTE_NAME, "foo"
};

Take this as a heads up of what's gonna happen soon into trunk.

Several caveat, albeit not new:
Lot of places with lookup properties in these arrays. While usually they
aren't big, it still is linear.

The huge benefit:
We stop having dangling property values like in the current code. Which
mean that all these file corruption bugs might go away. At leas those
where we write garbage memory.

Cheers,

Hub