Re: [gtkmm] Glib::ustring bug?

["Marcelo E. Magallon" <marcelo magallon bigfoot com>]

>> Joe Yandle <jwy divisionbyzero com> writes:

 > I think you've missed the point about ustring::raw().  It does *not*
 > return a C style string, so the fact that your code snippet worked
 > under gcc-RH is simply an accident.

 I don't understand what you are trying to say here...

 std::cout << std::string("123") << std::endl;

 works, and so should

 std::cout << Glib::ustring("123").raw() << std::endl;

 since the documentation says it returns a const std::string & (which it
 does).

 The fact that Glib::ustring is *not* a template is noteworthy.  In
 particular, Glib::ustring::ustring(const char*) is a compiled function.
 I suspect the problem is that the internal std::string of ustring is not
 compatible with STLPort's std::string (which is perfectly ok).  Fact is
 Glib::ustring::raw()'s return value is not the same std::string as the
 one used by operator<<(std::ostream &, const std::string &).

 > Outputting an unterminated char* to a C++ iostream is as likely to
 > cause a segfault as anything else, since the stream will keep
 > outputting characters until it reaches a null.

 That's correct, but it has nothing to do with this case.  I think you
 people are confusing Glib::ustring::raw() with std::string::data(),
 which returns a sequence of characters which may or may not be NULL
 terminated.  IIRC some STL implementation out there (Sun's?) has a raw
 member function in the string class.

-- 
Marcelo