Re: Lacking of a ref-counted string.

["Lieven van der Heide" <lievenvanderheide gmail com>]

The concept of a copy-on-write string really only makes sense in a
language like C++, where classes are copied implicitely all the time.

In a reference counted language, the kinds of copies that make naive
std::string implementations so suboptimal, are already solved by the
structure of the language.

Btw, I believe most stl implementations moved away from the copy on
write model, because it was really hard to do in a thread safe way,
while still supporting the full std::string interface.

On 8/21/08, Hubert Figuiere <hfiguiere teaser fr> wrote:
> On Wed, 2008-08-20 at 20:47 -0400, Yu Feng 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.
>
>
> Maybe having a copy-on-write implementation (in Vala) of the string type
>  is what you want. That way, when you need mutability, you copy. That's
>  the choice made by std::string and Glib::ustring (in glibmm that is
>  incidentaly implemented using std::string) in C++ and transcribe pretty
>  well the usage case.
>
>
>
>  > 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.
>
>
> That's a design choice, but it seem to be unavoidable to have a runtime
>  library at one point. All the other language have one, more or less.
>  Pascal, Java (libcj), Objective-C, Fortran, C++ and even C. I guess it
>  is no exception for Vala.
>
>
>
>  Hub
>
>
>  _______________________________________________
>  gtk-devel-list mailing list
>  gtk-devel-list gnome org
>  http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>