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 variables.
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.
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. (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 diacritics.)
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.
pjrm.