If that's the case, then you are indeed right. It's possible that the std::string constructor will work, but that would be more out of luck than anything else.
Regards, Elias On 8 August 2017 at 18:11, Juergen Sauermann <[email protected]> wrote: > Hi Elias, > > correct, except that an *UCS8_string* is not a string, despite of its > name. > *UCS8_string*s have no terminating 0 byte; the 0-byte is only appended if > the *UCS8_string* is converted to a C string with function *c_str()*. > > /// Jürgen > > > On 08/08/2017 09:28 AM, Elias Mårtenson wrote: > > Sorry for not replying earlier, I forgot about this message. > > ucs[0] should be OK for an empty string, as that will still refer to the > terminating NUL byte at the end of the string. Note that an empty string is > differetn from a NULL pointer (the former is a valid string, and the other > is not). > > Regards, > Elias > > On 1 August 2017 at 19:04, Juergen Sauermann < > [email protected]> wrote: > >> Hi Elias, >> >> I don't know what Ala'a did. However, looking at: >> >> */// return a UTF8 encoded std:string* >> *inline std::string to_string(const UCS_string & ucs)* >> *{* >> * const UTF8_string utf(ucs);* >> * return string((const char *)&utf[0], utf.size());* >> *}* >> >> I am not sure what happens if string *ucs* is empty (in that case *ucs[0] >> *does not >> exist and may be makes *&**ucs[0]* also 0. The std::string constructor >> then looks >> for the terminating 0 character in a 0-pointer. Using >> *UTF8:string::c_str**()* might >> be better. >> >> Also converting a UCS or UTF8 string to *std::string* just for >> outputting it with << may be >> an overkill, since *ostream << *often (read: after *#include >> "PrintOperator.hh*") understands >> UCF and UCS strings directly. >> >> /// Jürgen >> >> >> On 07/31/2017 02:31 AM, Elias Mårtenson wrote: >> >> Can you tell me exactly what you are doing in order to reproduce the >> problem? >> >> Regards, >> Elias >> >> >> > >
