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
On 8 August 2017 at 18:11, Juergen Sauermann <juergen.sauerm...@t-online.de>
> Hi Elias,
> correct, except that an *UCS8_string* is not a string, despite of its
> *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 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).
> On 1 August 2017 at 19:04, Juergen Sauermann <
> juergen.sauerm...@t-online.de> 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, utf.size());*
>> I am not sure what happens if string *ucs* is empty (in that case *ucs
>> *does not
>> exist and may be makes *&**ucs* 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