On Wed, 2005-06-29 at 21:13 +1000, Peter Moulder wrote:
> On Wed, Jun 29, 2005 at 04:19:09AM -0500, David Yip wrote:
> > To mitigate overflow issues with fixed-size buffers in the Inkboard code for
> > message transmission, I'm going to convert the Inkboard messaging code to use
> > strings. However, I'm not really sure what string implementation would be
> > preferred by the Inkscape team. As a lot of Inkboard and Inkscape code use
> > glib facilities, the GString has that advantage, but since we're using C++...
> > I don't see this explicitly touched on in the Developer's Manual or the
> > InkscapeJanitor wiki pages, so I'm guessing it hasn't been brought up before,
> > but if it's listed somewhere, I apologize for the duplicate message.
> Using std::string or Glib::ustring has the advantage of doing garbage
> collection on destruction, which is convenient for "automatic"/stack
> Using Glib::ustring has disadvantage that its operator runs in linear
> time in its argument, rather than constant time as one might expect.
> Similarly, I believe even its length() method takes linear time.
That's a problem with utf8, not ustring. GString doesn't offer any
linear way to iterate through utf8 characters in linear time either.
> I'm inclined to say that Glib::ustring is misdesigned: that it should
> have provided iterator functions for convenient gunichar-at-a-time
> iteration for the rare cases when that's better than byte-at-a-time.
Feel free to submit a patch, though I'm not sure when that's useful. You
can also convert to std::string if that's useful.
> (Note that gunichar-at-a-time isn't the same as character-at-a-time
> anyway, once you accept the unicode spec's interpretation of combining
> That said, using Glib::ustring does at least give the advantage of
> runtime-checked documentation that the string is valid utf8.
> GString can be useful for interfacing with non-gtkmm gtk stuff.
Is there any part of the GTK+ API that takes/provides a GString?
Glib::ustring::c_str() is usually all you need.