Hi, On Wed, Aug 20, 2008 at 8:47 PM, Yu Feng <[EMAIL PROTECTED]> wrote: > First, it is very difficult to manage a string without a reference > count. The current vala implementation is to assume that strings are > immutable, and to copy the strings almost everywhere where increasing > the ref-count should be used. The copying mechanism produces workable > code, but doesn't work in a efficient way. This is where it hurts. > > Secondly, vala doesn't introduce any additional dependency other than > GLib, to implement it in VALA level, the only way is to embed it in the > compiler. A compiler with embeded code to do a ref-counted string > doesn't sound nice. This is why I think it should be done at GLib level. >
If we think of GLib features as either for C, or for language bindings in general, or for vala, this particular feature seems like it would be *only* for vala - refcounted strings would be pretty strange in plain C, and just overhead for other language bindings that already have native string types they have to convert gchar* to. Putting only-useful-for-vala features in GLib would seem odd to me. Just one opinion, though. Can't vala do the same optimizations a C programmer would do by hand in most cases - avoiding a copy for a const char* that is only stored temporarily in local scope, for example? For other cases, a plain C program would have the same inefficiencies as vala it seems like, and they are not fatal inefficiencies... What about a libvala? I guess vala is supposed to have this property that it doesn't create dependencies in distributed tarballs, but that design goal has brought us autoconf and libtool in the past... not sure I'm sold on it. Or then, embedding it in the compiler does not seem like a very big deal - it's just two operations ref and unref, both of which are trivial and can just be inlined... Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
