bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Assertion failed


From: Juergen Sauermann
Subject: Re: [Bug-apl] Assertion failed
Date: Tue, 8 Aug 2017 12:11:57 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

Hi Elias,

correct, except that an UCS8_string is not a string, despite of its name.
UCS8_strings 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 <address@hidden> 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 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]