Il 25/05/20 17:40, Thiago Macieira ha scritto:
On Monday, 25 May 2020 04:37:26 PDT Edward Welbourne wrote:
The "comparisons" heading might stretch as far as using a UTF-8 key to
do a look-up in a QString-keyed hash,
Using UTF-8 data to look up in a QString-keyed hash will require conversion to
On Monday, 25 May 2020 04:37:26 PDT Edward Welbourne wrote:
> The "comparisons" heading might stretch as far as using a UTF-8 key to
> do a look-up in a QString-keyed hash,
Using UTF-8 data to look up in a QString-keyed hash will require conversion to
UTF-16 to calculate the hash. It can't be cal
On 25/05/2020 07.37, Edward Welbourne wrote:
I would just call it QUtf8View, since (see below) I don't see value in a
separate QUtf8String for it to be a view into
On the one hand...
std::string_view is not a view into a std::string. A std::string is a
*container* for text, a std::string_view
Thiago Macieira (23 May 2020 03:06) wrote:
> Update:
>
> As we're reviewing the changes Lars is making to get rid of
> QStringRef, Lars, Marc and I came to the conclusion that
> QUtf8StringView is required for Qt 6.0.
[snip]
Sounds sensible.
I would just call it QUtf8View, since (see below) I don'
On Saturday, 23 May 2020 05:39:37 PDT Giuseppe D'Angelo via Development wrote:
> To elaborate on this: does operator==(QStringView, char*) already exist
> (maybe under QT_NO_CAST...)? If yes, isn't that char* already assumed to
> be UTF-8? Do you want a QUtf8StringView to cleanly compile also under
Il 23/05/20 03:06, Thiago Macieira ha scritto:
As we're reviewing the changes Lars is making to get rid of QStringRef, Lars,
Marc and I came to the conclusion that QUtf8StringView is required for Qt 6.0.
That's because some methods that previously returned QStringRef now return
QStringView and to
Am 23.05.20 um 03:06 schrieb Thiago Macieira:
On Thursday, 14 May 2020 07:41:45 PDT Marc Mutz via Development wrote:
There's only our own lazyness which stands in the way of this better
alternative.
[snip the rest]
Update:
As we're reviewing the changes Lars is making to get rid of QStringRef
On Thursday, 14 May 2020 07:41:45 PDT Marc Mutz via Development wrote:
> There's only our own lazyness which stands in the way of this better
> alternative.
[snip the rest]
Update:
As we're reviewing the changes Lars is making to get rid of QStringRef, Lars,
Marc and I came to the conclusion tha
>
> QUtf8StringIterator can be easily added to extract Unicode codepoints from
> the UTF-8 string like QStringIterator exists for the same in UTF-16.
>
I have discovered QStringIterator in KDAB blog, it is nice, thanks!
A QUtf8StringIterator would boost Qt utf8 support like easily
splitting/filter
On 5/16/20 6:16 PM, Thiago Macieira wrote:
That opens a philosophical question. In:
QString s = u"a a\u0301"; // U+0301 COMBINING ACUTE ACCENT
s.replace('a', 'b');
Should we now have a b with accent? (b́)
It's not philosophical at all, it's a defining question: at which level
does
On 15/05/2020 14.31, Thiago Macieira wrote:
> Python's bstr still behaves string-like and has methods like
> QByteArray::indexOf(const char *). QVector has no such methods.
>
> But since we do have QListSpecialMethods, we can add inject them into
> QVector too.
Right; I was assuming that would
I facing a discussion like this every couple of months ;)
Yes, we should have a b with accent, cause it is exactly what the
programmer asked QString for; it is not our fault if b with accent is not
what he meant to get after replace.
QString (like any other tool) must not be used blindly or with z
On sábado, 16 de maio de 2020 08:52:19 PDT Arnaud Clère wrote:
> Regarding the relevance of a QUtf8String, I feel like it would not be so
> useful unless it allows to view its content as QChar instead of char (or
> char8_t) since handling multibyte characters is so error prone. At least a
> QChar h
Il 16/05/20 17:52, Arnaud Clère ha scritto:
Regarding the relevance of a QUtf8String, I feel like it would not be so
useful unless it allows to view its content as QChar instead of char (or
char8_t) since handling multibyte characters is so error prone. At least
a QChar handles most unicode cha
Hi all,
As a user, I am happy with simplifications regarding string handling and I
think the choice of utf16 for QString makes sense for most code except for
file/networking code.
I was once concerned about not being able to distinguish between QByteArray
containing utf8 text and QByteArray conta
On sexta-feira, 15 de maio de 2020 10:52:49 PDT Matthew Woehlke wrote:
> > Like that, it's just "array of bytes of an arbitrary encoding (or none)".
> > There's still a reason to have QByteArray and it'll need to exist in
> > networking and file I/O code. That means the string classes, if any, need
On 14/05/2020 21.12, Thiago Macieira wrote:
On Thursday, 14 May 2020 07:41:45 PDT Marc Mutz via Development wrote:
Also, given a function like
setFoo(const QByteArray &);
what does this actually expect? An UTF-8 string? A local 8-bit string?
An octet stream? A Latin-1 string? QByteArray i
On Friday, 15 May 2020 03:33:28 PDT Lars Knoll wrote:
> Pretty much all uses of QL1String that I’ve seen are about ASCII only
> content. That is certainly true for Qt itself, but also to a large degree
> for our users. For those, utf-8 conversions are within 5% of latin1
> decoding. This makes it v
> On 15 May 2020, at 03:12, Thiago Macieira wrote:
>
> On Thursday, 14 May 2020 07:41:45 PDT Marc Mutz via Development wrote:
>> Also, given a function like
>>
>>setFoo(const QByteArray &);
>>
>> what does this actually expect? An UTF-8 string? A local 8-bit string?
>> An octet stream? A La
On Thu, May 14, 2020 at 06:12:15PM -0700, Thiago Macieira wrote:
That means the string classes, if any, need to be convertible to
QByteArray anyway.
yes, via QTextCodec.
(behind the scenes some friend functions may be used for zero-copy
conversions.)
_
On Thursday, 14 May 2020 07:41:45 PDT Marc Mutz via Development wrote:
> Also, given a function like
>
> setFoo(const QByteArray &);
>
> what does this actually expect? An UTF-8 string? A local 8-bit string?
> An octet stream? A Latin-1 string? QByteArray is the jack of all these,
> master of
Hi Lars,
On 2020-05-12 09:49, Lars Knoll wrote:
[...]
One open question is whether we should add a QUtf8String with a
char8_t. I am not yet convinced that we actually need the class
though.
[...]
I positively want to stop using QByteArray as the QUtf8String that it
currently is. QByteArray sh
22 matches
Mail list logo
