From: Ole L. <ol...@ha...> - 2003-02-24 22:17:15
|
Stefan Seefeld <se...@sy...> writes: > Ole Laursen wrote: > > > But I really don't see the big problem here. std::string is really > > just a fancy way of saying 'char *', right? > > No. > > > And any decent > > Unicode-aware string library will have a convenient conversion from > > std::string, right? > > No. Then they are utterly broken IMNSHO. :-) At least you should be able to do from_raw(my_string.data(), my_string.size()). [...] > While it may be true that you can (technically) use std::string to > contain utf8 data, the std::string *interface* would be completely > inappropriate (beside the 'data()' and 'length()' methods :-) > > Please don't abuse std::string in such a horrible way. You are exaggerating, really. Remember that many string algorithms can be used without any trouble if the std::string contains UTF-8. Copying, concatenation and even replacement (of ASCII characters) all work. That covers 95%-100% of the cases for typical GUI usage, I think. I do have first hand experience with this, combining Glib::ustring with legacy std::strings. Yes, it will be unsafe if you try to access certain parts of the interface. But even it is crippled std::string, it is still much more convenient than a 'char *'. > But to go along the line you seem to suggest: libxml++ may use a > 'data container' that is agnostic of the encoding or any related > interpretation of the content. That may actually not even be such > a bad idea, since it could just be a smart pointer taking over > the memory from libxml2, freeing the data in its destructor using > xmlFree(). Perhaps this idea is better. If there is an implicit conversion to char*, it will interface nicely with both std::string and Glib::ustring. -- Ole Laursen http://www.cs.auc.dk/~olau/ |