Re: Is GStringChunk still useful?



On Mon, 2006-11-06 at 12:46 -0500, Matthew Barnes wrote:

> There has been some recent discussion in evolution-hackers over the
> value of GStringChunk in GLib.  Jeff provided a pretty good analysis of
> its pitfalls [1], leaving me to wonder whether its continued use is
> still encouraged.
> 
> I'm posting to this list hoping to get comments from a broader audience.
> Is this a data-structure that is generally shunned, and can anything be
> done to improve it?  Should some kind of disclaimer about when and how
> best to use it be added to the documentation?
> 
> [1]
> http://mail.gnome.org/archives/evolution-hackers/2006-November/msg00003.html

I seriously doubt that GStringChunk is useful, because the gain from
using non-aligned memory is lost if your strings don't fit the block
size (e.g. too long strings as described by Jeff, or even just the last
block not being completely filled). I'm in favor of obsoleting
GStringChunk.

However, I think there's a way to cater to the single use case for which
people would think about using GStringChunk: The case where you have a
long-lived struct with a lot of (unchanging) string pointers in it.

Let me illustrate with an example:

typedef struct
{
  gchar *from;
  gchar *to;
  gchar *cc;
  gchar *subject;
  gchar *body;
}
Mail;

Mail *mail;

We could introduce a function:

g_pack_strings (&mail->from, &mail->to, &mail->cc, &mail->subject,
&mail->body, NULL);

Which would strlen() the strings, allocate a block which would fit the
strings perfectly, copy the strings into the block, free the original
strings and replace the passed-in pointers with the strings' new
locations in the block. The block could be freed thusly:

g_free_packed_strings (&mail->from, &mail->to, &mail->cc,
&mail->subject, &mail->body, NULL);

Since the first non-NULL pointer would point to the start of the block,
g_free_packed_strings() would just call g_free() on that and return.

I think we want what I describe above, or nothing at all.

-- 
Hans Petter




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