Re: Varargs type stringification (#50972)
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: gtk-devel-list gtk org, Havoc Pennington <hp redhat com>
- Subject: Re: Varargs type stringification (#50972)
- Date: Sun, 1 Apr 2001 00:23:34 +0200 (CEST)
On 27 Mar 2001, Owen Taylor wrote:
>
> g_strdup_value_contents() is neat, but not all that convenient to
> use since:
>
> - You have to construct a value if you don't
don't ... what?
it strngifies a value's contents, i don't quite understand why you would
want this to work for non-GValue varargs collected values... ;)
> - You have to free the results
right, because the string is newly constructed.
> Here's a patch to add:
>
> gchar* g_strdup_type (GType type,
> ...);
erm, "type" appears really odd to me, probably better called
g_strdup_typed_value(), but before that i'd like to hear some
rationale for that function.
> G_CONST_RETURN char * g_stringify_type (GType type,
> ...);
>
> Which do the same thing but with GType + varargs. g_stringfy_type()
> uses a small ring buffer of static results to make it real easy
> to use in debug printfs.
urg, this is a rather cruel hack. while i understand the need for the
added convenience, we have the same problem (inconvenience) in a couple
other places as well (the most prominent probably being g_strdup_printf()).
i'd rather avoid having ring-buffer variants sprang up for all of them
during future development and provide something more suitable and scalable
for long-term use. on why i consider ring-buffer backends not-scalable,
if functions with ring-buffer backends are called more than ring_size
times from a function, presumably "constant" strings suddenly become
invalid. you might want to say that with ring size of e.g. 16, this is
unlikely to be triggered by code that uses those functions only for
debugging output, but:
people don't use your code only for purposes you had in mind, or, more
conretely, you can't assure g_stringify_typed_value() is only being used
for debugging output, or only for printfs with less than ring-size
arguments. especially with setups like:
strvalue = g_stringify_typed_value (&my_value);
third_party_library_call_that_might_use_g_stringify_typed_value_also ();
printf ("%s\n", strvalue);
users will have to be aware that g_stringify_typed_value() uses a
ring-buffer backend, i.e. that it doesn't really return a
G_CONST_RETURN string, and how big the ring buffer is. as soon as
we add more "convenience" functions to our API that also uses ring buffers,
preferrable with different sizes even ;) we'll be right on track to win
the most-confusing-API award.
a good while back i already spent a couple thoughts on getting around
the need to free certain temporary values (mostly strings) and how to
provide a suitable g_alloca() implementation for systems where we can't
use native alloca() for whatever reasons.
i think the best approach for both is a stack-level dependant allocator
that's undergoing frequent release cycles triggered by the main loop.
i'd like to defer discussion about such allocators a bit though, say
untill next week, where we hopefully have a chance to dicuss that in person.
>
> Regards,
> Owen
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]