Hi Enrico,
At Mon, 20 Feb 2012 13:08:05 +0100,
Enrico Weigelt wrote:
[...]
> and the call now would be
>
> create_foo(G_CSTR_STATIC("hello world"));
>
> in case we dont have an "static" string, but something with
> limited lifetime, it could look like this:
>
> create_foo(G_CSTR_DYNAMIC(bar));
>
> Inside create_foo() we'll then replace g_strdup() by some
> G_CSTR_COPY() and g_free() by G_CSTR_FREE(). These functions
> will know whether the string has to be copied/free'd.
with all the complication above, what's the benefit of having
G_CSTR_STATIC compared to:
/* create_foo will hold the passing pointer. do not free() after
* you passed. just pass a literal string will do good.
*/
create_foo("hello world");
or
create_foo_with_literal_string("hello world");
or
#define G_CSTR_STATIC(x) x
:
create_foo(G_CSTR_STATIC("hello world"));
/* and remove all g_free() and g_strdup in create_foo() because
* create_foo will _not_ accept a pointer to dynamic memory
* location anyway.
*/
?
it sounds, at least to me, more like a convention than new APIs or a
new class. how many bytes or how many CPU clocks are we waisting in
real world application?
did you have a copy-on-write string class, like std::string in C++, in
your mind? having a copy-on-write string class in glib might be a
good idea.
I apologize in advance if I'm way off.
with all my respect,
--
yashi
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
