Re: Plans for 1.3/1.4

[Jeff Garzik <jgarzik pobox com>]

On Sun, 28 Feb 1999, Elliot Lee wrote:
> On Sat, 27 Feb 1999, Jeff Garzik wrote:
> 
> > * alloca-based convenience macros, counterparts to:
> > 	g_new, g_new0, g_strdup, g_strndup, g_strconcat, ???
> 
> I think we've already been through this. No no no :-)

And of course I still disagree :)

There is a lot of GNOME code that does stuff like

	s = g_strconcat(s1,s2,s3,..); # typically 2-4 args
	do_something(s);
	g_free(s);

Several hand coded versions of strdup_a (a few coded by you in fact :))
can also be found by grepping GNOME and popt source for alloca.

That stuff is ripe for alloca use, but without a convenience macro you
have to hand code the string copies and NULL tests.  Suddenly two lines
of code (g_strconcat...g_free) becomes several, increasing the chance
for error and bugs.  That kills all incentive to use alloca in the
first place for those situations.

For me at least a lot of alloca's utility comes from fast temp
string and temp struct allocation.  And if you're going to use alloca
with strings, you are going to write these methods over and over again.



> > * GStack, opaque ADT with interface:
> > 
> > 	{ see code in GLIB_1_3_HACKS branch }
> > 
> > * GQueue, opaque ADT with interface:
> > 
> > 	{ see code in GLIB_1_3_HACKS branch }
> 
> <nit>Please make these convenience wrappers around GList or GSList, which
> already do 99% of the functionality.</nit>

That's pretty much what they are.  GQueue is basically
a GList that caches tail and size as well as root ptr, and GStack could
probably be implemented entirely in macros.  Havoc Pennington had a good
suggestion - make the queue a wrapper around a list... or a dynamic
array.  The STL's deque code has a lot of good methods to look at too.

	Jeff