Re: [Development] Why can't QString use UTF-8 internally?
2015-02-12 11:53 GMT+04:00 Konstantin Ritt : > 2015-02-12 11:39 GMT+04:00 Rutledge Shawn >: > >> >> On 11 Feb 2015, at 18:15, Konstantin Ritt wrote: >> >> > FYI: Unicode codepoint != character visual representation. Moreover, a >> single character could be represented with a sequence of glyps or vice >> versa - a sequence of characters could be represented with a single glyph. >> > QString (and every other Unicode string class in the world) represents >> a sequence of Unicode codepoints (in this or that UTF), not characters or >> glyphs - always remember that! >> >> Is it impossible to convert some of the possible multi-codepoint >> sequences into single ones, or is it just that we prefer to preserve them >> so that when you convert back to UTF you get the same bytes with which you >> created the QString? >> > > Not sure I understand your question in context of visual representation. > Assume you're talking about composing the input string (though the same > string, composed and decomposed, would be shaped into the same sequence of > glyphs). > A while ago we decided to not change the composition form of the input > text and let the user to (de)compose where he needs a fixed composition > form, so that QString(wellformed_unicode_text).toUnicode() == > wellformed_unicode_text. > P.S. We could re-consider this or could introduce a macro that would change the composition form of a QString input but...why? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
2015-02-12 11:39 GMT+04:00 Rutledge Shawn : > > On 11 Feb 2015, at 18:15, Konstantin Ritt wrote: > > > FYI: Unicode codepoint != character visual representation. Moreover, a > single character could be represented with a sequence of glyps or vice > versa - a sequence of characters could be represented with a single glyph. > > QString (and every other Unicode string class in the world) represents a > sequence of Unicode codepoints (in this or that UTF), not characters or > glyphs - always remember that! > > Is it impossible to convert some of the possible multi-codepoint sequences > into single ones, or is it just that we prefer to preserve them so that > when you convert back to UTF you get the same bytes with which you created > the QString? > Not sure I understand your question in context of visual representation. Assume you're talking about composing the input string (though the same string, composed and decomposed, would be shaped into the same sequence of glyphs). A while ago we decided to not change the composition form of the input text and let the user to (de)compose where he needs a fixed composition form, so that QString(wellformed_unicode_text).toUnicode() == wellformed_unicode_text. Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
On 12/02/15 04:08, "Thiago Macieira" wrote: >On Thursday 12 February 2015 01:18:47 Allan Sandfeld Jensen wrote: >> On Thursday 12 February 2015, Marc Mutz wrote: >> > On Thursday 12 February 2015 00:18:28 Allan Sandfeld Jensen wrote: >> > > On Wednesday 11 February 2015, Marc Mutz wrote: >> > > > If long double was any useful (apparently it's no larger than >>double >> > > > on >> > > > Windows), we could use that, but as it stands, that would be >> > > > pointless. >> > > >> > > Apropos, the usefulness of extended precision floating point >>happens to >> > > be that they can represent both 64bit integers and 64bit floating >>point. >> > >> > ...except if it cannot. That would've actually made for a good >>requirement >> > for a long double type: be a superset of values representable in >>double >> > and long long. >> > >> > But that's not what the standard says :( >> >> I was referring to x87's 80bit floating point. > >We don't want to use that. > >However, the in-memory format for QJsonValue could store a 64-bit int. Yes, 80 or 128bit doubles are out of the question. The RFC basically doesn’t specify the range of allowed values, but hints that it should at least support doubles. We can go above that and allow 64bit integers as well as they are rather common these days. But anything above that is IMO something that is out of scope for Qt. So I’d be ok with a patch that adds builtin support for 64bit integers. We’d then need to decide at parse time whether to store the value as integer or double, and since JSON only talks about numbers the getters have to do automatic conversion (or we’d break existing code). To be able to deal with them you’d need a isInteger() flag on QJsonValue. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On 11 Feb 2015, at 18:15, Konstantin Ritt wrote: > FYI: Unicode codepoint != character visual representation. Moreover, a single > character could be represented with a sequence of glyps or vice versa - a > sequence of characters could be represented with a single glyph. > QString (and every other Unicode string class in the world) represents a > sequence of Unicode codepoints (in this or that UTF), not characters or > glyphs - always remember that! Is it impossible to convert some of the possible multi-codepoint sequences into single ones, or is it just that we prefer to preserve them so that when you convert back to UTF you get the same bytes with which you created the QString? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
On Thursday 12 February 2015 01:18:47 Allan Sandfeld Jensen wrote: > On Thursday 12 February 2015, Marc Mutz wrote: > > On Thursday 12 February 2015 00:18:28 Allan Sandfeld Jensen wrote: > > > On Wednesday 11 February 2015, Marc Mutz wrote: > > > > If long double was any useful (apparently it's no larger than double > > > > on > > > > Windows), we could use that, but as it stands, that would be > > > > pointless. > > > > > > Apropos, the usefulness of extended precision floating point happens to > > > be that they can represent both 64bit integers and 64bit floating point. > > > > ...except if it cannot. That would've actually made for a good requirement > > for a long double type: be a superset of values representable in double > > and long long. > > > > But that's not what the standard says :( > > I was referring to x87's 80bit floating point. We don't want to use that. However, the in-memory format for QJsonValue could store a 64-bit int. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Wednesday 11 February 2015 18:05:09 Matthew Woehlke wrote: > > Only if we build with -Werror -- which we do, in the compilers that > > support __null. > > Um... do you not have *any* C++11 builds? If Q_NULLPTR == nullptr (which > I assume it is in C++11?), and you try to pass Q_NULLPTR to something > that wants an integer type, you'd better get a compile error, because > such a conversion is not allowed by the C++ standard. (At least > gcc-c++-4.8.3-7.fc20.x86_64 correctly rejects this.) You're right... All the compilers that support __null and that we test also support C++11 and nullptr, so we wouldn't get the __null warning converted to error, we'd get the actual nullptr error. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
On Thursday 12 February 2015, Marc Mutz wrote: > On Thursday 12 February 2015 00:18:28 Allan Sandfeld Jensen wrote: > > On Wednesday 11 February 2015, Marc Mutz wrote: > > > If long double was any useful (apparently it's no larger than double on > > > Windows), we could use that, but as it stands, that would be pointless. > > > > Apropos, the usefulness of extended precision floating point happens to > > be that they can represent both 64bit integers and 64bit floating point. > > ...except if it cannot. That would've actually made for a good requirement > for a long double type: be a superset of values representable in double > and long long. > > But that's not what the standard says :( I was referring to x87's 80bit floating point. `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
On Thursday 12 February 2015 00:18:28 Allan Sandfeld Jensen wrote: > On Wednesday 11 February 2015, Marc Mutz wrote: > > If long double was any useful (apparently it's no larger than double on > > Windows), we could use that, but as it stands, that would be pointless. > > > > > > Apropos, the usefulness of extended precision floating point happens to be > that they can represent both 64bit integers and 64bit floating point. ...except if it cannot. That would've actually made for a good requirement for a long double type: be a superset of values representable in double and long long. But that's not what the standard says :( -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] why is QJSEngine not modifying metaObject
On Wed, Feb 11, 2015 at 1:12 PM, Matt Broadstone wrote: > On Wed, Feb 11, 2015 at 4:00 PM, Thiago Macieira > wrote: >> >> On Wednesday 11 February 2015 18:50:42 Hausmann Simon wrote: >> > Hi, >> > >> > The brute force way is to add this feature to the engine at the expense >> > of >> > performance, memory consumption and maintenance :) >> > >> > Today you can invoke Javascript defined functions by simply getting the >> > function as a property via QJSValue and call() it. >> >> The objective was to expose such a JS object to D-Bus, but QtDBus requires >> the >> meta object to match. > > > I'm not sure what your full requirements are (it seems maybe you want to do > the reverse of what I was trying to do), but you might be interested in a > little science project I put together for a similar task: > https://bitbucket.org/devonit/qqmldbusinterface. > Awesome! I'll probably need to do something very similar. Seems this also follows the pattern that qdbus follows for building the meta object. Thanks! Another question would be whether I should do this in my own project, of if something like this would be generally useful to add to QJSEngine? > Regards, > Matt > >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
On Wednesday 11 February 2015, Marc Mutz wrote: > If long double was any useful (apparently it's no larger than double on > Windows), we could use that, but as it stands, that would be pointless. > Apropos, the usefulness of extended precision floating point happens to be that they can represent both 64bit integers and 64bit floating point. About JSON, would it make sense to allow these values in memory form but not write them? We should probably parse more of the extensions (be forgiving in parsing, but strict in writing by default). There are quite a few for JSON, besides 64bit integer Datetime comes up often and has a few different hacks, with a semi- standardized solution in the Windows world. `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 2015-02-11 16:21, Thiago Macieira wrote: > On Wednesday 11 February 2015 15:54:40 Matthew Woehlke wrote: >> On 2015-02-11 15:38, Marc Mutz wrote: >>> On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote: (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to Qt, but just saying...) >>> >>> You said auto ptr = 0 doesn't give you a pointer. By extension, I thought >>> you were saying that auto ptr = nullptr does (and it does, in a way). >> >> Right (well, a nullptr_t anyway which behaves the same as an in-place >> 'nullptr'; in particular, can be implicitly converted to a pointer, and >> *cannot* be implicitly converted to a numeric type). > > True, but that's not the point here. The only value allowed for nullptr_t is > nullptr, which is why any nullptr_t can be converted to any pointer. > > However, the point here is: > > auto ptr = nullptr; > ptr = &something; // error! > > void *ptr = nullptr; > ptr = &something; // ok True, but if you know what type you want (e.g. 'void*') you should be specifying it explicitly. I was thinking of a case where you are going to pass nullptr to something, but for some reason you want to put it in a local variable first. (Admittedly, it's a stretch.) I think we've gone just a bit off topic for something I said up front wasn't very interesting :-). > What's the type of ptr in? > auto ptr = __null; > > Hint: GCC prints this warning: > warning: converting to non-pointer type ‘long int’ from NULL [-Wconversion- > null] Huh :-). So much for hoping that __null == nullptr in C++11 mode. (I'm not going to claim to understand the intricacies of __null...) >> Right. Qt is not at a point where it can write API that relies on the >> existence of nullptr/nullptr_t. Overloading in particular is a no-go. > > It can be done, with some effort, for non-public API (that is, not ABI- > binding): > https://codereview.qt-project.org/100076 > specifically > https://codereview.qt-project.org/#/c/100076/4/src/corelib/kernel/qmetatype_p.h Well, sure; I was intentionally ignoring the case of a library work-around to provide a nullptr_t. (Pedantic: shouldn't that have a conversion operator?) >> Q_NULLPTR is still useful because *some* builds will break if you try to >> pass a Q_NULLPTR where only an integer type is accepted, but not *every* >> build will catch such errors even using Q_NULLPTR. (I think we're in >> agreement on this point?) > > Only if we build with -Werror -- which we do, in the compilers that support > __null. Um... do you not have *any* C++11 builds? If Q_NULLPTR == nullptr (which I assume it is in C++11?), and you try to pass Q_NULLPTR to something that wants an integer type, you'd better get a compile error, because such a conversion is not allowed by the C++ standard. (At least gcc-c++-4.8.3-7.fc20.x86_64 correctly rejects this.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Wednesday 11 February 2015 15:54:40 Matthew Woehlke wrote: > On 2015-02-11 15:38, Marc Mutz wrote: > > On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote: > >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to > >> Qt, but just saying...) > > > > You said auto ptr = 0 doesn't give you a pointer. By extension, I thought > > you were saying that auto ptr = nullptr does (and it does, in a way). > > Right (well, a nullptr_t anyway which behaves the same as an in-place > 'nullptr'; in particular, can be implicitly converted to a pointer, and > *cannot* be implicitly converted to a numeric type). True, but that's not the point here. The only value allowed for nullptr_t is nullptr, which is why any nullptr_t can be converted to any pointer. However, the point here is: auto ptr = nullptr; ptr = &something; // error! void *ptr = nullptr; ptr = &something; // ok > > But for Q_NULLPTR, auto ptr = Q_NULLPTR may be deduced as nullptr_t on a > > c++11 compiler, int (NULL = 0) on others, long (NULL = 0L) on yet other, > > and void* (NULL = (void*')) on the rest (yes, not all of them are valid > > in C++). > Good point. You're right that Q_NULLPTR "isn't adequate" here. (OTOH, > the range of compilers / versions that support C++11 'auto' but *not* > C++11 'nullptr' or e.g. something like __null is not so great.) What's the type of ptr in? auto ptr = __null; Hint: GCC prints this warning: warning: converting to non-pointer type ‘long int’ from NULL [-Wconversion- null] > > So I maintain that we can't rely on nullptr semantics here as long as we > > use Q_NULLPTR. Same for foo(int) vs. foo(void*). > > Right. Qt is not at a point where it can write API that relies on the > existence of nullptr/nullptr_t. Overloading in particular is a no-go. It can be done, with some effort, for non-public API (that is, not ABI- binding): https://codereview.qt-project.org/100076 specifically https://codereview.qt-project.org/#/c/100076/4/src/corelib/kernel/qmetatype_p.h > Q_NULLPTR is still useful because *some* builds will break if you try to > pass a Q_NULLPTR where only an integer type is accepted, but not *every* > build will catch such errors even using Q_NULLPTR. (I think we're in > agreement on this point?) Only if we build with -Werror -- which we do, in the compilers that support __null. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] why is QJSEngine not modifying metaObject
On Wed, Feb 11, 2015 at 4:00 PM, Thiago Macieira wrote: > On Wednesday 11 February 2015 18:50:42 Hausmann Simon wrote: > > Hi, > > > > The brute force way is to add this feature to the engine at the expense > of > > performance, memory consumption and maintenance :) > > > > Today you can invoke Javascript defined functions by simply getting the > > function as a property via QJSValue and call() it. > > The objective was to expose such a JS object to D-Bus, but QtDBus requires > the > meta object to match. > I'm not sure what your full requirements are (it seems maybe you want to do the reverse of what I was trying to do), but you might be interested in a little science project I put together for a similar task: https://bitbucket.org/devonit/qqmldbusinterface. Regards, Matt > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
On Wednesday 11 February 2015 21:26:40 Marc Mutz wrote: > The interesting part is what Qt should do about it. Postel's Law clearly > asks > for accepting (even invalid) input as long as its meaning is clear. Clearly, > that is the case for larger-than-double numbers. So, by Postel's Law, Qt > should strive to support them. If you apply the law to the API side of > QtJSON, then it should do so even for writing. So Bo has a valid point. Accepting is one thing. But if we do this, we need to be able to generate 64- bit integers. Think of this: what happens if you do a pass-through QJsonDocument of data outside of JSON documents? Should QJsonDocument: 1) output invalid data because it arrived in such a way? 2) silently lose up to 11 bits of precision? If we chose #1, then the follow-up question is what happens if you extract the data to your structure and want to re-create the JSON document -- you wouldn't be able to. > If long double was any useful (apparently it's no larger than double on > Windows), we could use that, but as it stands, that would be pointless. There are very few architectures that support 80- or 128-bit precision floating point in hardware. x86 is one of them, but unlike single- and double-precision modes, the extended-precision support did not make the transition to the SSE world. That means x86-64 does support the type natively, but requires use of the expensive x87 unit and 32-bit style calling conventions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] why is QJSEngine not modifying metaObject
On Wednesday 11 February 2015 18:50:42 Hausmann Simon wrote: > Hi, > > The brute force way is to add this feature to the engine at the expense of > performance, memory consumption and maintenance :) > > Today you can invoke Javascript defined functions by simply getting the > function as a property via QJSValue and call() it. The objective was to expose such a JS object to D-Bus, but QtDBus requires the meta object to match. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 2015-02-11 15:38, Marc Mutz wrote: > On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote: >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to >> Qt, but just saying...) > > You said auto ptr = 0 doesn't give you a pointer. By extension, I thought you > were saying that auto ptr = nullptr does (and it does, in a way). Right (well, a nullptr_t anyway which behaves the same as an in-place 'nullptr'; in particular, can be implicitly converted to a pointer, and *cannot* be implicitly converted to a numeric type). > But for Q_NULLPTR, auto ptr = Q_NULLPTR may be deduced as nullptr_t on a > c++11 > compiler, int (NULL = 0) on others, long (NULL = 0L) on yet other, and void* > (NULL = (void*')) on the rest (yes, not all of them are valid in C++). Good point. You're right that Q_NULLPTR "isn't adequate" here. (OTOH, the range of compilers / versions that support C++11 'auto' but *not* C++11 'nullptr' or e.g. something like __null is not so great.) > So I maintain that we can't rely on nullptr semantics here as long as we use > Q_NULLPTR. Same for foo(int) vs. foo(void*). Right. Qt is not at a point where it can write API that relies on the existence of nullptr/nullptr_t. Overloading in particular is a no-go. Q_NULLPTR is still useful because *some* builds will break if you try to pass a Q_NULLPTR where only an integer type is accepted, but not *every* build will catch such errors even using Q_NULLPTR. (I think we're in agreement on this point?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 18:26:40 Guido Seifert wrote:
> > > Yes, and he already said such example, ß becomes SS
> >
> > The other example that was given is 'i' (UTF-8 0x69) becoming 'İ' under a
> > Turkish locale (UTF-8 0xc4 0xb0).
>
> Ah sorry. I was too focused on the visible length. 'i' = 'İ' = 1. But of
> course I have to look at the memory usage in the string. Btw... what would
> happen in Mark's example?
Which example? Using the std::transform with ::toupper?
Well, that depends on what toupper does and whether you configured the global C
library locale correctly.
-- Function: int toupper (int C)
Preliminary: | MT-Safe | AS-Safe | AC-Safe | *Note POSIX Safety
Concepts::.
If C is a lower-case letter, `toupper' returns the corresponding
upper-case letter. Otherwise C is returned unchanged.
1) toupper('i') == 'i'
"istanbul" → "iSTANBUL"
2) toupper('i') == L'İ' == 0x130
"istanbul" → "0STANBUL"
3) toupper('i') == 'I'
"istanbul" → "ISTANBUL"
All solutions are wrong for Turkish.
By the way, QByteArray's toUpper and toLower are now documented to operate
*exclusively* on Latin 1 and no locale variants apply, so i becomes I and ß/ÿ
remain ß/ÿ. There used to be a bug in this until 5.4.0 [1].
Also, QString does not support locale-based case conversions, so "istanbul"
always becomes "ISTANBUL" -- locale-based conversions should be in QLocale,
but the feature is missing. At least "fußball" becomes "FUSSBALL" and ÿ gets
properly uppercased.
[1] eef74f82db049517aa5a80e7c9456c4cbda953d1:
[...]
Also as a consequence, this changes the handling of two characters in
Latin 1: 'ß' should be uppercased to "SS" but we won't do it, and 'ÿ'
can't be uppercased in Latin 1 ('Ÿ' is outside the range).
[...]
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 17:28:43 Daniel Teske wrote: > On Wednesday 11 Feb 2015 17:20:04 Guido Seifert wrote: > > Minor OT, but I am too curious... do you have an example? > > Are there really cases were turning lower case into upper case or > > vice versa changes the length of a string? > > What is uppercase ß? As a German (juding from name and affiliation, sorry if not) you should know your own characters: http://en.wikipedia.org/wiki/Capital_%E1%BA%9E :) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Wednesday 11 February 2015 18:02:53 Matthew Woehlke wrote: > On 2015-02-11 04:18, Marc Mutz wrote: > > On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote: > >> Marc, I'm not sure if you're arguing for or against nullptr :-)... > > > > > > > > Then I agree with André; you need to start reading mails (threads) > > before responding :) > > Will someone please explain to me why you think I'm not? It's either that or > Is my irony detector broken? this. I was replying to André's question "can't you [..] wait until nuklptr is available?" with No. I thought that was obviously pro-Q_NULLPTR :) > >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to > >> Qt, but just saying...) > > > > > > > > While true, this is semantics that we can't rely on in Qt atm. > > (Ahem: "[this is] not relevant to Qt". Speaking of irony, I guess I'm > not the only one that can't keep the entire thread straight...) You said auto ptr = 0 doesn't give you a pointer. By extension, I thought you were saying that auto ptr = nullptr does (and it does, in a way). But for Q_NULLPTR, auto ptr = Q_NULLPTR may be deduced as nullptr_t on a c++11 compiler, int (NULL = 0) on others, long (NULL = 0L) on yet other, and void* (NULL = (void*')) on the rest (yes, not all of them are valid in C++). So I maintain that we can't rely on nullptr semantics here as long as we use Q_NULLPTR. Same for foo(int) vs. foo(void*). foo(Q_NULLPTR) may be ambiguous, call the int overload or the void* overload. Again, we can't rely on nullptr semantics when using Q_NULLPTR. We can only hope to catch some bugs and otherwise improve readability by using it (but the later, as we've seen is controversial). > > nor can it be relied on that Q_NULLPTR doesn't convert to an > > integral type. > > True for a given build. However, there is a fair chance that some other > (C++11) build will break in case of such code, increasing the chances > that someone will notice any issues of this nature. > > > The latter is esp. interesting, as I believe some compilers > > implement NULL to be nullptr-like even in C++98 (and Q_NULLPTR is NULL if > > it's not nullptr), so you may benefit even in C++98 by using Q_NULLPTR > > instead of 0. But you can't rely on that. > > This too :-). -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] why is QJSEngine not modifying metaObject
I see. So something like this: QObject* QJSEngine::jsValueToQObject(const QJSValue & v); Introspects the functions and properties and creates a proper QMetaObject. I might take a stab at this if I have time. On Wed, Feb 11, 2015 at 10:50 AM, Hausmann Simon wrote: > Hi, > > The brute force way is to add this feature to the engine at the expense of > performance, memory consumption and maintenance :) > > Today you can invoke Javascript defined functions by simply getting the > function as a property via QJSValue and call() it. > > > Simon > > Original Message > From: Rees, Kevron > Sent: Wednesday, February 11, 2015 17:18 > To: Hausmann Simon > Cc: Thiago Macieira; development@qt-project.org > Subject: Re: [Development] why is QJSEngine not modifying metaObject > > > On Wed, Feb 11, 2015 at 12:03 AM, Hausmann Simon > wrote: >> Hi, >> >> Kind of :) It works on a type level. So a new type is defined with new >> methods and a new meta object is defined. But it doesn't use a mechanism >> where a new meta object is created each time a method is added. >> >> If we move the current engine over to generate meta objects from internal >> classes then perhaps we could create the meta objects on demand and batch >> them. That would make the example at hand work. >> > > This sounds desirable. > >> Of course this could also be implemented by brute force, but I'm not sure it >> is worth it. >> > > Can you elaborate on this brute force method? Is there another way to > get the internal JS class metadata in c++? > >> Simon >> >> Original Message >> From: Thiago Macieira >> Sent: Wednesday, February 11, 2015 08:35 >> To: development@qt-project.org >> Subject: Re: [Development] why is QJSEngine not modifying metaObject >> >> >> On Wednesday 11 February 2015 07:11:26 Hausmann Simon wrote: >>> Hi, >>> >>> The short answer to your question is that the meta object system isn't >>> really designed for this. In theory this could be implemented but it would >>> come at a high cost for something that rarely happens. The qml engine >>> supports this, but in qml this happens at type compilation time, not fully >>> dynamic. >> >> Wasn't this how QML1 worked? >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
On Wednesday 11 February 2015 17:42:54 Giuseppe D'Angelo wrote: > Il 11/02/2015 16:11, Marc Mutz ha scritto: > > If Qt produces 64-bit integers in its JSON output, then the next bug > > report will (probably rightfully) be that Qt's JSON output cannot be > > read by some JavaScript library X. > > Note that it's perfectly legal, and a "feature" of JSON: > > https://tools.ietf.org/html/rfc7158#section-6 > > >This specification allows implementations to set limits on the range > >and precision of numbers accepted. Since software that implements > >IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is > >generally available and widely used, good interoperability can be > >achieved by implementations that expect no more precision or range > >than these provide, in the sense that implementations will > >approximate JSON numbers within the expected precision. A JSON > >number such as 1E400 or 3.141592653589793238462643383279 may indicate > >potential interoperability problems, since it suggests that the > >software that created it expects receiving software to have greater > >capabilities for numeric magnitude and precision than is widely > >available. > > > >Note that when such software is used, numbers that are integers and > >are in the range [-(2**53)+1, (2**53)-1] are interoperable in the > >sense that implementations will agree exactly on their numeric > >values. > > So Qt is totally right at accepting an arbitrary range, and another JS > library would be right at not accepting the numbers that Qt outputs. > > But even with this total mis-specification (just say it's IEEE754 > doubles and make JS a normative reference already!), I'd rather not go > down that road and avoid integer-based APIs for QJsonValue (to the point > of deprecating the existing qint64 constructor; I won't make that call > though). And, with the reasonable assumption that the accepted values > are JS numbers (minus NaN/infinity), which nowadays is probably the > equivalent of saying that an int is 32 bits, then sending out 64-bit ids > as numbers is a flaw that has to be corrected on sender's side. There are two different topics here: how to best represent larger-than-double integers or floats in JSON and whether Qt should support them. I read the above as an instance of Postel's Law: Interoperable software might not want to create numbers that JS can't parse (in the original sense, with eval()), but it doesn't hurt to allow larger numbers. Of course, at the end of the day, it's the job of the API user to conform to the spec, even though, if emails and json are any indicator, they are not good at that. That said, Bo's customer is apparently right, according to the spec. The interesting part is what Qt should do about it. Postel's Law clearly asks for accepting (even invalid) input as long as its meaning is clear. Clearly, that is the case for larger-than-double numbers. So, by Postel's Law, Qt should strive to support them. If you apply the law to the API side of QtJSON, then it should do so even for writing. So Bo has a valid point. If long double was any useful (apparently it's no larger than double on Windows), we could use that, but as it stands, that would be pointless. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] why is QJSEngine not modifying metaObject
Hi, The brute force way is to add this feature to the engine at the expense of performance, memory consumption and maintenance :) Today you can invoke Javascript defined functions by simply getting the function as a property via QJSValue and call() it. Simon Original Message From: Rees, Kevron Sent: Wednesday, February 11, 2015 17:18 To: Hausmann Simon Cc: Thiago Macieira; development@qt-project.org Subject: Re: [Development] why is QJSEngine not modifying metaObject On Wed, Feb 11, 2015 at 12:03 AM, Hausmann Simon wrote: > Hi, > > Kind of :) It works on a type level. So a new type is defined with new > methods and a new meta object is defined. But it doesn't use a mechanism > where a new meta object is created each time a method is added. > > If we move the current engine over to generate meta objects from internal > classes then perhaps we could create the meta objects on demand and batch > them. That would make the example at hand work. > This sounds desirable. > Of course this could also be implemented by brute force, but I'm not sure it > is worth it. > Can you elaborate on this brute force method? Is there another way to get the internal JS class metadata in c++? > Simon > > Original Message > From: Thiago Macieira > Sent: Wednesday, February 11, 2015 08:35 > To: development@qt-project.org > Subject: Re: [Development] why is QJSEngine not modifying metaObject > > > On Wednesday 11 February 2015 07:11:26 Hausmann Simon wrote: >> Hi, >> >> The short answer to your question is that the meta object system isn't >> really designed for this. In theory this could be implemented but it would >> come at a high cost for something that rarely happens. The qml engine >> supports this, but in qml this happens at type compilation time, not fully >> dynamic. > > Wasn't this how QML1 worked? > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
So forget proposing QString to operate on visual or logical glyphs. There is QTextBoundaryFinder class that operates on logical items, and QFontMetrics that operates on visual glyphs. Regards, Konstantin 2015-02-11 21:59 GMT+04:00 Matthew Woehlke : > On 2015-02-11 12:00, Thiago Macieira wrote: > > On Wednesday 11 February 2015 11:49:49 Matthew Woehlke wrote: > >> I'm not going to claim this is the *best* answer, but at least one that > >> seems logical... length() should be the number of times one must hit > >> backspace starting from the end of the text to erase the entire text. > > > > That will depend on the editor. Some may remove the full character with > all > > the combining characters, some others may not. > > Yeah, I thought of that :-/. TBH I think these sorts of things should be > specified by Unicode (if they don't already; I would rather hope they > do) rather than Qt trying to decide how to answer them. > > >> Conversely, I'm sure there are times when you need to know the number of > >> codepoints (e.g. allocating memory to make a copy). Possibly length() > >> and size() should return different results. (Which is a mess, but...) > > > > Uh... no, that's not a good idea. > > > > If we were going do to something like that, we'd have to find a less > confusing > > name. Something like width(). > > Well... yes, for the sake of compatibility I'm inclined to agree. > Changing the meaning of one or both of these, or that they are presently > synonyms, would confuse the heck out of people. That said... Bo *did* > specify "length()" when he wanted a method to return logical characters > and not codepoints. It may be that he's just out of luck there... > > (@Konstantin, yes I'm aware that logical glyphs != codepoints... that > was the whole point of Bo's original request, at least as I understood it.) > > -- > Matthew > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On 2015-02-11 12:00, Thiago Macieira wrote: > On Wednesday 11 February 2015 11:49:49 Matthew Woehlke wrote: >> I'm not going to claim this is the *best* answer, but at least one that >> seems logical... length() should be the number of times one must hit >> backspace starting from the end of the text to erase the entire text. > > That will depend on the editor. Some may remove the full character with all > the combining characters, some others may not. Yeah, I thought of that :-/. TBH I think these sorts of things should be specified by Unicode (if they don't already; I would rather hope they do) rather than Qt trying to decide how to answer them. >> Conversely, I'm sure there are times when you need to know the number of >> codepoints (e.g. allocating memory to make a copy). Possibly length() >> and size() should return different results. (Which is a mess, but...) > > Uh... no, that's not a good idea. > > If we were going do to something like that, we'd have to find a less > confusing > name. Something like width(). Well... yes, for the sake of compatibility I'm inclined to agree. Changing the meaning of one or both of these, or that they are presently synonyms, would confuse the heck out of people. That said... Bo *did* specify "length()" when he wanted a method to return logical characters and not codepoints. It may be that he's just out of luck there... (@Konstantin, yes I'm aware that logical glyphs != codepoints... that was the whole point of Bo's original request, at least as I understood it.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
> > Yes, and he already said such example, ß becomes SS > > The other example that was given is 'i' (UTF-8 0x69) becoming 'İ' under a > Turkish locale (UTF-8 0xc4 0xb0). Ah sorry. I was too focused on the visible length. 'i' = 'İ' = 1. But of course I have to look at the memory usage in the string. Btw... what would happen in Mark's example? Guido ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
FYI: Unicode codepoint != character visual representation. Moreover, a single character could be represented with a sequence of glyps or vice versa - a sequence of characters could be represented with a single glyph. QString (and every other Unicode string class in the world) represents a sequence of Unicode codepoints (in this or that UTF), not characters or glyphs - always remember that! Regards, Konstantin 2015-02-11 20:49 GMT+04:00 Matthew Woehlke : > On 2015-02-11 11:29, Thiago Macieira wrote: > > On Wednesday 11 February 2015 11:22:59 Julien Blanc wrote: > >> On 11/02/2015 10:32, Bo Thorsen wrote: > >>> 2) length() returns the number of chars I see on the screen, not a > >>> random implementation detail of the chosen encoding. > >> > >> How’s that supposed to work with combining characters, which are part of > >> unicode ? > > > > That's true. And add that there are some zero-width characters too and > some > > characters that are double-width. > > I'm not going to claim this is the *best* answer, but at least one that > seems logical... length() should be the number of times one must hit > backspace starting from the end of the text to erase the entire text. > IOW, the number of logical glyphs. Double-width characters are one > logical glyph. Combining characters are not independently logical glyphs > (e.g. 'ñ' is one glyph, regardless of how it is encoded). > > Conversely, I'm sure there are times when you need to know the number of > codepoints (e.g. allocating memory to make a copy). Possibly length() > and size() should return different results. (Which is a mess, but...) > > -- > Matthew > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 2015-02-11 04:18, Marc Mutz wrote: > On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote: >> Marc, I'm not sure if you're arguing for or against nullptr :-)... > > Then I agree with André; you need to start reading mails (threads) before > responding :) Will someone *please* explain to me why you think I'm not? Marc: what made me scratch my head was your comments regarding 'emit'. In general, you appear to be arguing for nullptr, but then you say you don't like 'emit' while indicating that the arguments in favor of 'emit' are similar to the arguments in favor of nullptr. Am I missing why this isn't a contradiction? Is my irony detector broken? >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to >> Qt, but just saying...) > > While true, this is semantics that we can't rely on in Qt atm. (Ahem: "[this is] not relevant to Qt". Speaking of irony, I guess I'm not the only one that can't keep the entire thread straight...) > nor can it be relied on that Q_NULLPTR doesn't convert to an > integral type. True for a given build. However, there is a fair chance that some other (C++11) build will break in case of such code, increasing the chances that someone will notice any issues of this nature. > The latter is esp. interesting, as I believe some compilers > implement NULL to be nullptr-like even in C++98 (and Q_NULLPTR is NULL if > it's > not nullptr), so you *may* benefit even in C++98 by using Q_NULLPTR instead > of > 0. But you can't _rely_ on that. This too :-). -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 11:49:49 Matthew Woehlke wrote: > I'm not going to claim this is the *best* answer, but at least one that > seems logical... length() should be the number of times one must hit > backspace starting from the end of the text to erase the entire text. That will depend on the editor. Some may remove the full character with all the combining characters, some others may not. > IOW, the number of logical glyphs. Double-width characters are one > logical glyph. Combining characters are not independently logical glyphs > (e.g. 'ñ' is one glyph, regardless of how it is encoded). Exactly. We don't have a function for that, though. > Conversely, I'm sure there are times when you need to know the number of > codepoints (e.g. allocating memory to make a copy). Possibly length() > and size() should return different results. (Which is a mess, but...) Uh... no, that's not a good idea. If we were going do to something like that, we'd have to find a less confusing name. Something like width(). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt containers and non-copyable types
On 2015-02-11 11:39, Thiago Macieira wrote: > On Wednesday 11 February 2015 11:31:10 Matthew Woehlke wrote: >> On 2015-02-10 19:44, Thiago Macieira wrote: >>> ... they aren't useful because we'll never accept movable-but-not-copyable >>> objects. An implicitly shared container implies a copyable contained >>> object. >> Wouldn't you just disable sharing (and indeed, copying the container at >> all) if the type is non-copyable? (Isn't this what happens with >> std::vector? I'd have to think yes...) > > That would be required, but the problem is that it can't be easily > implemented. Every non-const accessor function has a call to detach(), which > requires the copy constructor. So, it may not count as "easy", but is it not possible to partially specialize a non-COW implementation for non-copyable types? > There are a couple of functions that search backwards if you give them > negative values. Also because we use signed everywhere and the warnings about > comparing signed and unsigned are annoying. Ah, yes. Okay, then. (TBH I've sometimes found it "nice" that Qt containers use 'int' and not size_t, so I've probably run into the conversion thing also and benefited from 'the Qt way'.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
On Wednesday 11 February 2015 12:12:33 Bo Thorsen wrote:
> If I say to my customers they have to send me another language because
> the Qt JSON library can't read 64 bit unsigned integers they say "Qt
> sucks, switch to another JSON library.". We can't win here.
What's to stop someone at 64-bit? What if someone has a bad generator that
suddenly starts outputting 65-bit numbers or bigger?
It could be as stupid a bug as the y2k:
printf("%d/%d/19%d", d.tm_day, d.tm_month + 1, d.tm_year);
Which suddenly started printing "19100".
Similarly, what if someone is using an 80-bit extended precision FP and writes
that? Are we expected to keep the precision?
We also had a discussion recently of someone using '' instead of "" for
quoting strings.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On 2015-02-11 11:29, Thiago Macieira wrote: > On Wednesday 11 February 2015 11:22:59 Julien Blanc wrote: >> On 11/02/2015 10:32, Bo Thorsen wrote: >>> 2) length() returns the number of chars I see on the screen, not a >>> random implementation detail of the chosen encoding. >> >> How’s that supposed to work with combining characters, which are part of >> unicode ? > > That's true. And add that there are some zero-width characters too and some > characters that are double-width. I'm not going to claim this is the *best* answer, but at least one that seems logical... length() should be the number of times one must hit backspace starting from the end of the text to erase the entire text. IOW, the number of logical glyphs. Double-width characters are one logical glyph. Combining characters are not independently logical glyphs (e.g. 'ñ' is one glyph, regardless of how it is encoded). Conversely, I'm sure there are times when you need to know the number of codepoints (e.g. allocating memory to make a copy). Possibly length() and size() should return different results. (Which is a mess, but...) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
Il 11/02/2015 16:11, Marc Mutz ha scritto: If Qt produces 64-bit integers in its JSON output, then the next bug report will (probably rightfully) be that Qt's JSON output cannot be read by some JavaScript library X. Note that it's perfectly legal, and a "feature" of JSON: https://tools.ietf.org/html/rfc7158#section-6 This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available. Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values. So Qt is totally right at accepting an arbitrary range, and another JS library would be right at not accepting the numbers that Qt outputs. But even with this total mis-specification (just say it's IEEE754 doubles and make JS a normative reference already!), I'd rather not go down that road and avoid integer-based APIs for QJsonValue (to the point of deprecating the existing qint64 constructor; I won't make that call though). And, with the reasonable assumption that the accepted values are JS numbers (minus NaN/infinity), which nowadays is probably the equivalent of saying that an int is 32 bits, then sending out 64-bit ids as numbers is a flaw that has to be corrected on sender's side. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
2015-02-11 20:35 GMT+04:00 Thiago Macieira : > > There are probably more examples. > ftp://ftp.unicode.org/Public/UNIDATA/SpecialCasing.txt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt containers and non-copyable types (was: Why can't QString use UTF-8 internally?)
On Wednesday 11 February 2015 11:31:10 Matthew Woehlke wrote: > On 2015-02-10 19:44, Thiago Macieira wrote: > > ... they aren't useful because we'll never accept movable-but-not-copyable > > objects. An implicitly shared container implies a copyable contained > > object. > Wouldn't you just disable sharing (and indeed, copying the container at > all) if the type is non-copyable? (Isn't this what happens with > std::vector? I'd have to think yes...) That would be required, but the problem is that it can't be easily implemented. Every non-const accessor function has a call to detach(), which requires the copy constructor. The best we could do in a Qt container for a non-copyable type is a const container. You'd have to create it in the constructor and NEVER modify it again. No emplace_back. > > For QVector, we might have to switch to qint64 or to qintptr or some other > > name for a *signed* integer type. > > If it has to be signed, ssize_t (okay, same as qintptr I guess, so > really I'm just voting against an always-64-bit type) would seem > preferable. (Why does it need to be signed? For methods that return 'not > found' I'd expect the all-1's value, a la std::string. Where do you > actually need a negative *value*, e.g. -N, not just -1?) There are a couple of functions that search backwards if you give them negative values. Also because we use signed everywhere and the warnings about comparing signed and unsigned are annoying. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 14:23:08 Tomaz Canabrava wrote: > On Wed, Feb 11, 2015 at 2:20 PM, Guido Seifert wrote: > > Minor OT, but I am too curious... do you have an example? > > Are there really cases were turning lower case into upper case or > > vice versa changes the length of a string? > > Yes, and he already said such example, ß becomes SS The other example that was given is 'i' (UTF-8 0x69) becoming 'İ' under a Turkish locale (UTF-8 0xc4 0xb0). Even if you use the new uppercase ẞ, the operation changes length in UTF-8 (0xc3 0x9f → 0xe1 0xba 0x9e), even though it doesn't in UTF-16. There are probably more examples. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt containers and non-copyable types (was: Why can't QString use UTF-8 internally?)
On 2015-02-10 19:44, Thiago Macieira wrote: > On Tuesday 10 February 2015 19:07:09 Matthew Woehlke wrote: >> Heh. That reminds me, when will Qt classes get emplace methods? > > I added those methods to my local refactor of QVector, but.. > >> Or the ability to accept movable-but-not-copyable types? > > ... they aren't useful because we'll never accept movable-but-not-copyable > objects. An implicitly shared container implies a copyable contained object. Wouldn't you just disable sharing (and indeed, copying the container at all) if the type is non-copyable? (Isn't this what happens with std::vector? I'd have to think yes...) >> (Something else to consider for Qt 6 would be fixing the index types to >> be size_t instead of int. Assuming we don't just drop the classes.) > > For QVector, we might have to switch to qint64 or to qintptr or some other > name for a *signed* integer type. If it has to be signed, ssize_t (okay, same as qintptr I guess, so really I'm just voting against an always-64-bit type) would seem preferable. (Why does it need to be signed? For methods that return 'not found' I'd expect the all-1's value, a la std::string. Where do you actually need a negative *value*, e.g. -N, not just -1?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 11:22:59 Julien Blanc wrote:
> On 11/02/2015 10:32, Bo Thorsen wrote:
> > 2) length() returns the number of chars I see on the screen, not a
> > random implementation detail of the chosen encoding.
>
> How’s that supposed to work with combining characters, which are part of
> unicode ?
That's true. And add that there are some zero-width characters too and some
characters that are double-width.
Also, QString::length() returns the number of UTF-16 codepoints, not the
number of UCS-4 characters, so it reports 2 characters for a pair of
surrogates, not 1.
If you really want to know the width of the string as seen on screen, you need
to use QFontMetrics, even for a monospace setting.
> > 3) at(int) and [] gives the unicode char, not a random encoding char.
>
> Same problem with combining characters. What do you expect :
>
> QString s = QString::fromWCharArray(L"n\u0303");
> s.length(); // 1 or 2 ??
> s[0]; // n or ñ ??
Yet, unlike std::u16string, QString can convert from NFD to NFC:
QString s = QString::fromUtf16(u"n\u0303")
.normalized(QString::NormalizationForm_C);
s.length() == 1;
s[0] == "ñ";
> > Another note: Latin1 is the worst idea for i18n ever invented, and it's
> > by now useless, irrelevant and only a source for bugs once you start to
> > truly support i18n outside of USA and Western Europe. I would be one
> > step closer to total happiness if C++17 and Qt7 makes this "encoding"
> > completely unsupported.
>
> Could not agree more with that part.
There are two reasons we keep Latin1 in the API:
1) it's a superset of US-ASCII, so toAscii and fromAscii are just calls to
the Latin1 functions with the note "behaviour is undefined if the string
contains non-ASCII characters"
2) it's dead easy to convert to and from it to UTF-16
As I was explaining yesterday to some people, the core of the loop of
converting from Latin1 to UTF-16 is *two* AVX2 instructions:
b36: vpmovzxbw (%rax,%rsi,1),%ymm0
b3c: vmovdqu %ymm0,(%rdi,%rax,2)
[plus the loop overhead itself]
The conversion from UTF-16 to Latin1 is a little more complex due to the
requirement to replace non-Latin1 characters with '?', so it's a few more
instructions with AVX-512F:
1c60a: vpmovzxwd 0x0(%r13,%rdx,2),%zmm2
1c612: vpcmpnltud %zmm1,%zmm2,%k1
1c61d: vpblendmd %zmm0,%zmm2,%zmm3{%k1}
1c623: vpmovdb %zmm3,(%rdx,%rdi,1)
Without AVX-512F (which no one has yet), it expands to more code.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 Feb 2015 17:20:04 Guido Seifert wrote: > Minor OT, but I am too curious... do you have an example? > Are there really cases were turning lower case into upper case or > vice versa changes the length of a string? What is uppercase ß? daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 17:23:51 Christoph Feck wrote: > On Wednesday 11 February 2015 17:20:04 Guido Seifert wrote: > > Minor OT, but I am too curious... do you have an example? > > Are there really cases were turning lower case into upper case or > > vice versa changes the length of a string? > > office (4 code points) -> OFFICE (7 code points) Looks like I cannot count, but you get the idea. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 17:20:04 Guido Seifert wrote: > Minor OT, but I am too curious... do you have an example? > Are there really cases were turning lower case into upper case or > vice versa changes the length of a string? office (4 code points) -> OFFICE (7 code points) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wed, Feb 11, 2015 at 2:20 PM, Guido Seifert wrote:
>
> Minor OT, but I am too curious... do you have an example?
> Are there really cases were turning lower case into upper case or
> vice versa changes the length of a string?
>
Yes, and he already said such example, ß becomes SS
>
> Guido
>
> > > std::string s("hello");
> > > std::transform(s.begin(), s.end(), s.begin(), ::toupper);
> > >
> > > and
> > > std::transform(s.begin(), s.end(), s.begin(), ::tolower);
> > >
> > > Not sure about the performance though
> >
> > That's flawed by construction. Uppercasing and lowercasing are string
> > operations, since it can change length, *especially* if you do it in
> UTF-8.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
Minor OT, but I am too curious... do you have an example?
Are there really cases were turning lower case into upper case or
vice versa changes the length of a string?
Guido
> > std::string s("hello");
> > std::transform(s.begin(), s.end(), s.begin(), ::toupper);
> >
> > and
> > std::transform(s.begin(), s.end(), s.begin(), ::tolower);
> >
> > Not sure about the performance though
>
> That's flawed by construction. Uppercasing and lowercasing are string
> operations, since it can change length, *especially* if you do it in UTF-8.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] why is QJSEngine not modifying metaObject
On Wed, Feb 11, 2015 at 12:03 AM, Hausmann Simon wrote: > Hi, > > Kind of :) It works on a type level. So a new type is defined with new > methods and a new meta object is defined. But it doesn't use a mechanism > where a new meta object is created each time a method is added. > > If we move the current engine over to generate meta objects from internal > classes then perhaps we could create the meta objects on demand and batch > them. That would make the example at hand work. > This sounds desirable. > Of course this could also be implemented by brute force, but I'm not sure it > is worth it. > Can you elaborate on this brute force method? Is there another way to get the internal JS class metadata in c++? > Simon > > Original Message > From: Thiago Macieira > Sent: Wednesday, February 11, 2015 08:35 > To: development@qt-project.org > Subject: Re: [Development] why is QJSEngine not modifying metaObject > > > On Wednesday 11 February 2015 07:11:26 Hausmann Simon wrote: >> Hi, >> >> The short answer to your question is that the meta object system isn't >> really designed for this. In theory this could be implemented but it would >> come at a high cost for something that rarely happens. The qml engine >> supports this, but in qml this happens at type compilation time, not fully >> dynamic. > > Wasn't this how QML1 worked? > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 10:32:22 Mark Gaiser wrote:
> > Have you tried to uppercase or lowercase a string using only the Standard
> > Library?
>
> std::string s("hello");
> std::transform(s.begin(), s.end(), s.begin(), ::toupper);
>
> and
> std::transform(s.begin(), s.end(), s.begin(), ::tolower);
>
> Not sure about the performance though
That's flawed by construction. Uppercasing and lowercasing are string
operations, since it can change length, *especially* if you do it in UTF-8.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
Marc Mutz schreef op 11-2-2015 om 16:11:
> On Wednesday 11 February 2015 14:04:59 Bo Thorsen wrote:
>> Den 11-02-2015 kl. 13:27 skrev Giuseppe D'Angelo:
>>> On 11 February 2015 at 12:12, Bo Thorsen wrote:
It's so easy to say we just follow the standard. But I have two current
projects where my customers say they send me a 64 bit database ID in a
JSON value. Converting those through a double might work, but can you
guarantee this?
>>> No, because IEEE754 64-bit floating point numbers can't represent all
>>> 64 bit integers... the right solution, from a JSON point of view, is
>>> not sending a number but a string.
>> Exactly, that's why I wrote "might". You don't know if the number you
>> get is correct or not.
>>
>> But we can't get the string from {"i":1}. You get an empty string if you
>> do toString on the i value.
>>
>> And that's the problem. People have web APIs that return uint64 as a
>> number and I need to get that number. ATM the only way is to read it
>> from the full QByteArray. If the toString would never fail and give me
>> the contents or I can get the bytes from it or add the extra type
>> reading functions - all three would work. The current meagre API is
>> pretty much the only way that doesn't.
> If Qt produces 64-bit integers in its JSON output, then the next bug report
> will (probably rightfully) be that Qt's JSON output cannot be read by some
> JavaScript library X.
>
> That said, if in doubt, follow Postel's Law.
>
So, the setter should probably read something like:
enum ResponsibilityLevel { IAmClueLess,
IKnowThisIsNotStandardJsonAndWontComplainToQt };
setValue(qint64 value, ResponsibilityLevel responsibility = IAmClueLess);
Assert/throw if responsibility is at IAmClueLess :-)
Actually following Postels law would mean being able to read an Int64,
but not being able write one right?
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
On Wednesday 11 February 2015 14:04:59 Bo Thorsen wrote:
> Den 11-02-2015 kl. 13:27 skrev Giuseppe D'Angelo:
> > On 11 February 2015 at 12:12, Bo Thorsen wrote:
> >> It's so easy to say we just follow the standard. But I have two current
> >> projects where my customers say they send me a 64 bit database ID in a
> >> JSON value. Converting those through a double might work, but can you
> >> guarantee this?
> >
> > No, because IEEE754 64-bit floating point numbers can't represent all
> > 64 bit integers... the right solution, from a JSON point of view, is
> > not sending a number but a string.
>
> Exactly, that's why I wrote "might". You don't know if the number you
> get is correct or not.
>
> But we can't get the string from {"i":1}. You get an empty string if you
> do toString on the i value.
>
> And that's the problem. People have web APIs that return uint64 as a
> number and I need to get that number. ATM the only way is to read it
> from the full QByteArray. If the toString would never fail and give me
> the contents or I can get the bytes from it or add the extra type
> reading functions - all three would work. The current meagre API is
> pretty much the only way that doesn't.
If Qt produces 64-bit integers in its JSON output, then the next bug report
will (probably rightfully) be that Qt's JSON output cannot be read by some
JavaScript library X.
That said, if in doubt, follow Postel's Law.
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Item creation time in QML
On 9 Feb 2015, at 11:25, Gunnar Sletta wrote: > Hi, > > Thought I would share a couple of benchmark numbers for item creation time in > QML. The sources are found here: > https://github.com/sletta/stuff/tree/master/qml/benchmarks. The motivation is > that we can generally animate a large number of items, but we often stutter > when adding and removing stuff from the scene or when scrolling complex lists. > > How the benchmark works is that the it tries to figure out how many > operations of a given type is possible each frame (not per second) while > sustaining a perfect 60 fps (or whatever other fps you target). For these > numbers, we’re looking at delegation creation and destruction. You can look > at the content of each specific benchmark here: > https://github.com/sletta/stuff/tree/master/qml/benchmarks/benchmark/creation. > > > This was measured on my 13” MacBookPro, Intel i5 2.6Ghz, Intel Iris GPU using > ‘dev’. On lower end mobile and embedded, the numbers can be an order of > magnitude lower. > > > ./qmlbench --delay 2500 --repeat 5 --fullscreen --fps-interval 2000 > > benchmark/creation > running: "benchmark/creation/delegates_blendedrect.qml" > 485 ops/frame > 490 ops/frame > 487 ops/frame > 477 ops/frame > 489 ops/frame > 485.6 ops/frame average > running: "benchmark/creation/delegates_buttoncontrol.qml" > 10 ops/frame > 10 ops/frame > 10 ops/frame > 10 ops/frame > 10 ops/frame > 10 ops/frame average > running: "benchmark/creation/delegates_complex.qml" > 11 ops/frame > 11 ops/frame > 11 ops/frame > 11 ops/frame > 11 ops/frame > 11 ops/frame average > running: "benchmark/creation/delegates_image.qml" > 303 ops/frame > 304 ops/frame > 301 ops/frame > 304 ops/frame > 304 ops/frame > 303.2 ops/frame average > running: "benchmark/creation/delegates_labelcontrol.qml" > 81 ops/frame > 81 ops/frame > 80 ops/frame > 81 ops/frame > 82 ops/frame > 81 ops/frame average > running: "benchmark/creation/delegates_longtext.qml" > 37 ops/frame > 37 ops/frame > 37 ops/frame > 37 ops/frame > 37 ops/frame > 37 ops/frame average > running: "benchmark/creation/delegates_rect.qml" > 527 ops/frame > 530 ops/frame > 527 ops/frame > 526 ops/frame > 531 ops/frame > 528.2 ops/frame average > running: "benchmark/creation/delegates_script.qml" > 382 ops/frame > 387 ops/frame > 387 ops/frame > 374 ops/frame > 385 ops/frame > 383 ops/frame average > running: "benchmark/creation/delegates_text.qml" > 128 ops/frame > 128 ops/frame > 127 ops/frame > 128 ops/frame > 127 ops/frame > 127.6 ops/frame average > running: "benchmark/creation/delegates_text_nativerendering.qml" > 138 ops/frame > 137 ops/frame > 136 ops/frame > 137 ops/frame > 136 ops/frame > 136.8 ops/frame average > running: "benchmark/creation/delegates_text_plain.qml" > 130 ops/frame > 129 ops/frame > 128 ops/frame > 128 ops/frame > 129 ops/frame > 128.8 ops/frame average > running: "benchmark/creation/delegates_text_richtext.qml" > 46 ops/frame > 46 ops/frame > 46 ops/frame > 46 ops/frame > 46 ops/frame > 46 ops/frame average > running: "benchmark/creation/delegates_text_styled.qml" > 125 ops/frame > 125 ops/frame > 126 ops/frame > 126 ops/frame > 125 ops/frame > 125.4 ops/frame average > running: "benchmark/creation/delegates_tworects.qml" > 314 ops/frame > 312 ops/frame > 313 ops/frame > 314 ops/frame > 315 ops/frame > 313.6 ops/frame average > All done... > > — > > Being able to do 500+items rectangles in one frame is decent, but not > awesome. Being able todo 130 text items in one frame, is less than ideal, > given that we often use several text items per cell in a list or table. Text > is probably the most important UI element we have. Being able to do 10 > buttons is, well, unfortunate :) If we look at Button, we see that it is a > fairly complex QML beast. Hierarchy is > > Button -> BasicButton -> Control -> FocusScope > > and there are quite a bit of stuff on every level, including the dynamic > style handling which will in turn create a StyleItem. > > And keep in mind that even though this isn’t the most high-end mac, it is > sitll a pretty decent computer, Qt is supposed to run on much worse hardware > than this. > > — > > There have been a few changes going into 5.5 which make these numbers better > than 5.4, but I still think we got quite a ways to go. That’s very interesting. Do you think it was ever better in past versions? What do you think we should do about it? Mainly focus on trying to create fewer objects, or is there still a lot of headroom for making the creation more efficient? Is cre
Re: [Development] JSON 64 bit int
Den 11-02-2015 kl. 13:27 skrev Giuseppe D'Angelo:
> On 11 February 2015 at 12:12, Bo Thorsen wrote:
>>
>> It's so easy to say we just follow the standard. But I have two current
>> projects where my customers say they send me a 64 bit database ID in a JSON
>> value. Converting those through a double might work, but can you guarantee
>> this?
>
> No, because IEEE754 64-bit floating point numbers can't represent all
> 64 bit integers... the right solution, from a JSON point of view, is
> not sending a number but a string.
Exactly, that's why I wrote "might". You don't know if the number you
get is correct or not.
But we can't get the string from {"i":1}. You get an empty string if you
do toString on the i value.
And that's the problem. People have web APIs that return uint64 as a
number and I need to get that number. ATM the only way is to read it
from the full QByteArray. If the toString would never fail and give me
the contents or I can get the bytes from it or add the extra type
reading functions - all three would work. The current meagre API is
pretty much the only way that doesn't.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
On 11 February 2015 at 12:12, Bo Thorsen wrote: > > It's so easy to say we just follow the standard. But I have two current > projects where my customers say they send me a 64 bit database ID in a JSON > value. Converting those through a double might work, but can you guarantee > this? No, because IEEE754 64-bit floating point numbers can't represent all 64 bit integers... the right solution, from a JSON point of view, is not sending a number but a string. -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Wednesday 11 February 2015 10:56:29 Olivier Goffart wrote: > On Wednesday 11 February 2015 10:49:31 Marc Mutz wrote: > > On Wednesday 11 February 2015 07:54:52 Hausmann Simon wrote: > > > I suppose that it is absolutely unlikely that we are going to find a > > > consensus on what is purely an aesthetic issue. > > > > > > I for one am entirely with André and I do not like UPPERCASE macros in > > > my face unless I can avoid them. It's aesthetics and I suppose there > > > is little that will change that. > > > > > > As approver I will approve code that uses Q_NULLPTR but I expect others > > > reviewing my code to respect my preference to use 0 until we can use > > > nullptr. > > > > Apart from the claim that there is nothing technical in this discussion, > > I agree with the above. Respect the preference of the guy who codes. I > > like simple rules. This is one. > > I prefer using curly braces for if even if there is only one line. > This is what the KDE coding style mandate, it makes diff smaller when you > add or remove lines, and it helps preventing mistakes likes the "goto > fail; goto fail;" one. > Am i going to be allowed to use curly braces? I, for one, won't stop you. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 11:11:36 Olivier Goffart wrote: > "UB could ckick in" has no meaning. > > In practice there is no reason why casting a pointer to member function to > remove the const would not work. Yet, you would not accept it[1]. > > Data races are undefined behavior according to the standard. So anything > could happen. I believe the N4323 paper Thiago cited is meant as a step in the direction of tightening (loosening?) the rules around the definition of data races, so writing the same value would be legal even if the writes conflict. But the summary doesn't say so, and I didn't have time yet to read the full paper. If and when the execution model is thus changed, we can assume that older compilers will respect it, too, and use it. But I agree we can't until then. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
Den 11-02-2015 kl. 11:58 skrev Giuseppe D'Angelo:
> On 11 February 2015 at 11:40, Bo Thorsen wrote:
>> {"i":1e33} gives a 0 if I convert the number to int (which is fair
>> enough). If I convert to variant, it gives me a double.
>
> Because it _is_ a double, given that JSON is a subset of Javascript,
> and numbers in Javascript are IEEE754 64bit floating point numbers.
> (And it's also a strict subset, given that JSON omits the handling of
> +/- infinity and NaN...). I'm not too happy with the fact that
> QJsonValue has "int" in its API...
I know this is the history of JSON, but it's no longer the reality. The
use of JSON are all over the place now and they are not restricting
themselves to Javascript numbers. You can find requests in the bug
tracker for what I just asked about - JSON is no longer just about
Javascript.
We have one of two choices here: Follow a restrictive schema that is no
longer a description of how it's used. Or follow what users outside of
the Javascript world would like to have.
It's so easy to say we just follow the standard. But I have two current
projects where my customers say they send me a 64 bit database ID in a
JSON value. Converting those through a double might work, but can you
guarantee this? Yes, they do something that's wrong. But this is how I
see JSON used these days. Restricting the JSON values to a set of types
from one of the simplest typesystems found in programming languages is
just silly IMHO.
If I say to my customers they have to send me another language because
the Qt JSON library can't read 64 bit unsigned integers they say "Qt
sucks, switch to another JSON library.". We can't win here.
Well, there's actually a third option: Give me the original QByteArray
that the value comes from. If there was a way to get this, I can convert
the value any way I want. Something like "QByteArray bytes() const"
would allow for any kind of parsing on our side. I'd be fine with this
as a workaround that would allow us to stay with the spec.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JSON 64 bit int
On 11 February 2015 at 11:40, Bo Thorsen wrote:
> {"i":1e33} gives a 0 if I convert the number to int (which is fair
> enough). If I convert to variant, it gives me a double.
Because it _is_ a double, given that JSON is a subset of Javascript,
and numbers in Javascript are IEEE754 64bit floating point numbers.
(And it's also a strict subset, given that JSON omits the handling of
+/- infinity and NaN...). I'm not too happy with the fact that
QJsonValue has "int" in its API...
--
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 11/02/15 10:46, "Marc Mutz" wrote: >On Wednesday 11 February 2015 08:27:24 Knoll Lars wrote: >> To settle this, I am also with Andre and Simon. > >Please don't evade: how is the situation different for emit vs. Q_NULLPTR? emit IMO helps code readability, as you know this is not a regular function call but a signal emission. Having said that I don’t think we have a strong requirement to use it. > >> let’s not go and replace 0 with the macro in places where >> things are unambiguous. > >For old code, by definition, 0 as currently used cannot be ambiguous >(since it >compiled before). > >Ergo, you're banning replacing any 0 with nullptr in existing code, in >passing >or else (except where it causes a warning), even though a few lines up >you >seem to allow replacing it "where it makes things clearer" (whatever that >means). Unambiguous to somebody reading the code, not the compiler. There is a difference between them. >For new code, we're not replacing a 0. > >To me that reads that it's fine to use Q_NULLPTR in new code, even though >a few >lines up you say that you dislike macros. > >Can you leave less wiggle room, please? :) Well, I think Thiago already summed it up nicely: >Two examples: >a) void *ptr = 0; >b) str.toInt(0, 0); > >In (a), use of Q_NULLPTR would make the code noisier, so don't use it. In >(b), >the first 0 could be replaced with Q_NULLPTR to indicate that yes we know >it's >a pointer, as opposed to an integer. Readability and making sure a human can parse the written code quickly is important to me. And less macros usually do make the code more readable. But where things are ambiguous to a human reading the code (again, that’s different from a compiler), I’m fine with using Q_NULLPTR to clarify. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] JSON 64 bit int
Hi guys,
ATM QJsonValue doesn't have a way to read a 64 bit integer or unsigned
integers. The standards doesn't seem to limit the contents of an int.
And I know of several projects that use this.
{"i":1e33} gives a 0 if I convert the number to int (which is fair
enough). If I convert to variant, it gives me a double.
I would like to have some more conversion available. uint, qint64 and
quint64 would be great. It sucks that I have to find the place in the
original string and parse it myself.
Would patches for this be accepted or is there a reason those aren't
added yet?
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On 11/02/2015 10:32, Bo Thorsen wrote: > 2) length() returns the number of chars I see on the screen, not a > random implementation detail of the chosen encoding. How’s that supposed to work with combining characters, which are part of unicode ? > 3) at(int) and [] gives the unicode char, not a random encoding char. Same problem with combining characters. What do you expect : QString s = QString::fromWCharArray(L"n\u0303"); s.length(); // 1 or 2 ?? s[0]; // n or ñ ?? > std::string fails at those completely basic requirement, which is why > you will never see me use it, unless some customer API demands it or I'm > in one of those exceptional cases where there is sure to be ascii only > in the strings. QString (at least in qt4, not tested with qt5) fails, too, but less often. > Another note: Latin1 is the worst idea for i18n ever invented, and it's > by now useless, irrelevant and only a source for bugs once you start to > truly support i18n outside of USA and Western Europe. I would be one > step closer to total happiness if C++17 and Qt7 makes this "encoding" > completely unsupported. Could not agree more with that part. Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Tuesday 10 February 2015 17:25:07 Thiago Macieira wrote: > On Wednesday 11 February 2015 01:59:40 Olivier Goffart wrote: > > Unless it is a buffer of std::atomic, it is an undefined behavior, so not > > only the contents of the buffer is unpredictable, but anything, really. > > > > (A sufficiently smart conforming compiler could see that you are writing > > at > > the same location without proper synchronization and conclude that you are > > not using threads and optimize away all the other locks) > > > > (This is getting a bit out of topic) > > Unless there are out-of-thin-air values, I don't see how a UB could kick in > and I don't think atomics are necessary. > > See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4323.html - > "Out-of-Thin-Air Execution is Vacuous" "UB could ckick in" has no meaning. In practice there is no reason why casting a pointer to member function to remove the const would not work. Yet, you would not accept it[1]. Data races are undefined behavior according to the standard. So anything could happen. (I mentioned that the compiler could remove locks, but it could also use the buffer as temporary scratch area for something else knowing that the memory is going to be overwritten, or it could just replace the main() function with an empty body, knowing that your program has undefined behavior) [1] remember https://codereview.qt-project.org/13013/ ? -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org /me decided this thread shall live on :-) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
Den 11-02-2015 kl. 10:48 skrev Olivier Goffart: > On Wednesday 11 February 2015 10:32:31 Bo Thorsen wrote: >> This would make me very unhappy. I'm doing a customer project right now >> that uses std::string all over the place and there is real pain involved >> in this. It's an almost empty layer over char* and brings none of the >> features of QString. Of all the failures of the C++ standards committee, >> std::string is the worst. >> >> Any string class has to be unicode. What it uses internally is an >> implementation detail (which is what started this thread). It's fine to >> have a pure ascii string type as well, but there are so few cases left >> in real world applications where this is useful. >> >> What QString internally uses is a pure optimization question, and I'll >> leave that to others. But whatever is decided, I want to be sure it >> keeps some of the things QString offers: >> >> 1) Unicode! Don't assume the user remembers to use utf8. >> qlabel->setText(stdString) *will* fail. Leaving decisions on encoding to >> users is a bad idea. >> >> 2) length() returns the number of chars I see on the screen, not a >> random implementation detail of the chosen encoding. >> >> 3) at(int) and [] gives the unicode char, not a random encoding char. >> >> std::string fails at those completely basic requirement, which is why >> you will never see me use it, unless some customer API demands it or I'm >> in one of those exceptional cases where there is sure to be ascii only >> in the strings. >> >> Another note: Latin1 is the worst idea for i18n ever invented, and it's >> by now useless, irrelevant and only a source for bugs once you start to >> truly support i18n outside of USA and Western Europe. I would be one >> step closer to total happiness if C++17 and Qt7 makes this "encoding" >> completely unsupported. >> >> I know this I've made the statements here a bit harsh, but I see the >> same kinds of problems again and again in customer code, when they chose >> to use std::string all over the place. They give the same arguments I've >> seen here - optimized, faster, etc - and add a few like "easier to >> switch away from Qt, backend is std/boost only and no Qt allowed and so >> on". And they pay for it in development time, bugfixing and angry users. >> >> Sure, QString isn't optimized for some cases. But I'll take a less >> optimized class any day over something that brings heaps of bugs. Then I >> have time to focus on optimizing the serious things instead of fixing bugs. > > Again, std::string is not an equivalent of QString, it is a equivalent of > QByteArray. > The equivalent of QString would be std::wstring or std::u16string. And those > classes have the properties you desire. I know. I responded to a suggestion to use std::string with utf8 encoding. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Wednesday 11 February 2015 10:49:31 Marc Mutz wrote: > On Wednesday 11 February 2015 07:54:52 Hausmann Simon wrote: > > I suppose that it is absolutely unlikely that we are going to find a > > consensus on what is purely an aesthetic issue. > > > > I for one am entirely with André and I do not like UPPERCASE macros in my > > face unless I can avoid them. It's aesthetics and I suppose there is > > little that will change that. > > > > As approver I will approve code that uses Q_NULLPTR but I expect others > > reviewing my code to respect my preference to use 0 until we can use > > nullptr. > > Apart from the claim that there is nothing technical in this discussion, I > agree with the above. Respect the preference of the guy who codes. I like > simple rules. This is one. I prefer using curly braces for if even if there is only one line. This is what the KDE coding style mandate, it makes diff smaller when you add or remove lines, and it helps preventing mistakes likes the "goto fail; goto fail;" one. Am i going to be allowed to use curly braces? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 10:32:31 Bo Thorsen wrote: > This would make me very unhappy. I'm doing a customer project right now > that uses std::string all over the place and there is real pain involved > in this. It's an almost empty layer over char* and brings none of the > features of QString. Of all the failures of the C++ standards committee, > std::string is the worst. > > Any string class has to be unicode. What it uses internally is an > implementation detail (which is what started this thread). It's fine to > have a pure ascii string type as well, but there are so few cases left > in real world applications where this is useful. > > What QString internally uses is a pure optimization question, and I'll > leave that to others. But whatever is decided, I want to be sure it > keeps some of the things QString offers: > > 1) Unicode! Don't assume the user remembers to use utf8. > qlabel->setText(stdString) *will* fail. Leaving decisions on encoding to > users is a bad idea. > > 2) length() returns the number of chars I see on the screen, not a > random implementation detail of the chosen encoding. > > 3) at(int) and [] gives the unicode char, not a random encoding char. > > std::string fails at those completely basic requirement, which is why > you will never see me use it, unless some customer API demands it or I'm > in one of those exceptional cases where there is sure to be ascii only > in the strings. > > Another note: Latin1 is the worst idea for i18n ever invented, and it's > by now useless, irrelevant and only a source for bugs once you start to > truly support i18n outside of USA and Western Europe. I would be one > step closer to total happiness if C++17 and Qt7 makes this "encoding" > completely unsupported. > > I know this I've made the statements here a bit harsh, but I see the > same kinds of problems again and again in customer code, when they chose > to use std::string all over the place. They give the same arguments I've > seen here - optimized, faster, etc - and add a few like "easier to > switch away from Qt, backend is std/boost only and no Qt allowed and so > on". And they pay for it in development time, bugfixing and angry users. > > Sure, QString isn't optimized for some cases. But I'll take a less > optimized class any day over something that brings heaps of bugs. Then I > have time to focus on optimizing the serious things instead of fixing bugs. Again, std::string is not an equivalent of QString, it is a equivalent of QByteArray. The equivalent of QString would be std::wstring or std::u16string. And those classes have the properties you desire. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Wednesday 11 February 2015 07:54:52 Hausmann Simon wrote: > I suppose that it is absolutely unlikely that we are going to find a > consensus on what is purely an aesthetic issue. > > I for one am entirely with André and I do not like UPPERCASE macros in my > face unless I can avoid them. It's aesthetics and I suppose there is > little that will change that. > > As approver I will approve code that uses Q_NULLPTR but I expect others > reviewing my code to respect my preference to use 0 until we can use > nullptr. Apart from the claim that there is nothing technical in this discussion, I agree with the above. Respect the preference of the guy who codes. I like simple rules. This is one. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Wednesday 11 February 2015 08:27:24 Knoll Lars wrote: > To settle this, I am also with Andre and Simon. Please don't evade: how is the situation different for emit vs. Q_NULLPTR? > let’s not go and replace 0 with the macro in places where > things are unambiguous. For old code, by definition, 0 as currently used cannot be ambiguous (since it compiled before). Ergo, you're banning replacing any 0 with nullptr in existing code, in passing or else (except where it causes a warning), even though a few lines up you seem to allow replacing it "where it makes things clearer" (whatever that means). For new code, we're not replacing a 0. To me that reads that it's fine to use Q_NULLPTR in new code, even though a few lines up you say that you dislike macros. Can you leave less wiggle room, please? :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
Den 10-02-2015 kl. 23:17 skrev Thiago Macieira: > My current thinking is: > 1) modernise our headers with macros, now > 2) allow people to use Q_NULLPTR where it helps with readability > 3) disallow replacing of zeroes with Q_NULLPTR except as required by rules > #1 > or #2 > > Two examples: > a)void *ptr = 0; > b)str.toInt(0, 0); > > In (a), use of Q_NULLPTR would make the code noisier, so don't use it. In (b), > the first 0 could be replaced with Q_NULLPTR to indicate that yes we know it's > a pointer, as opposed to an integer. I think this is a perfect set of rules and sums up most of the discussion nicely. +1. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
Am 11.02.2015 um 10:11 schrieb Marc Mutz: > You overlooked "where a corresponding character exists". Either uppercase ß > exists (it does, it was found in an old printing, so there's a movement to > adopt it, except Unicode doesn't have it), then it's not a problem, or it does > (as is the case in Unicode), and the character stays lower-case. Unicode 5.1, published in 2008 introduced "U+1E9E LATIN CAPITAL LETTER SHARP S[5]". Ciao, Mathias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wed, Feb 11, 2015 at 12:33 AM, Thiago Macieira wrote:
> On Tuesday 10 February 2015 23:17:21 Allan Sandfeld Jensen wrote:
> > Maybe with C++11 we don't need QString that much anymore. Use std::string
> > with UTF8 and std::u32string for UCS4.
> >
> > For Qt6 it would be worth considering how many of our classes still makes
> > sense. Those we want CoW semantics on would make sense, but if we don't
> > really want that on strings, maybe every framework having its own string
> > class is finally obsolete in C++?
>
> Eh... have you tried to convert a UTF-8 or UTF-16 or UCS-4 string to the
> locale's narrow character set without using QString?
>
> Have you tried to convert a number to string? You need C++14 to do that
> reasonably, since std::to_string didn't exist in C++11. How about the
> reverse?
> The only way to do that is sscanf or std::istringstream.
>
What do you mean with C++14? According to cppreference [1] C++11 allows
this just fine.
[1] http://en.cppreference.com/w/cpp/string/basic_string/to_string
>
> Have you tried to uppercase or lowercase a string using only the Standard
> Library?
>
std::string s("hello");
std::transform(s.begin(), s.end(), s.begin(), ::toupper);
and
std::transform(s.begin(), s.end(), s.begin(), ::tolower);
Not sure about the performance though :)
> We may want to have this discussion for QVector vs std::vector. For QString
> and QByteArray, there's no discussion: they stay, period.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
Den 10-02-2015 kl. 23:17 skrev Allan Sandfeld Jensen: > On Tuesday 10 February 2015, Oswald Buddenhagen wrote: >> On Wed, Feb 11, 2015 at 12:37:41AM +0400, Konstantin Ritt wrote: >>> Yes, that would be an ideal solution. Unfortunately, that would also >>> break a LOT of existing code. >> >> i was thinking of making it explicit with a smooth migration path - add >> QUtf8String (basically QByteArray, but don't permit implicit conversion >> to avoid encoding mistakes) and QUcs4String (and QUtf16String as an >> alias for current QString - for all the windows function calls). the >> main effort would be adding respective overloads to all our api. then >> deprecate QString, and prune it in qt6. then maybe re-add it as an >> alias for utf8string a few minor versions down. does that sound >> feasible? >> > Maybe with C++11 we don't need QString that much anymore. Use std::string with > UTF8 and std::u32string for UCS4. This would make me very unhappy. I'm doing a customer project right now that uses std::string all over the place and there is real pain involved in this. It's an almost empty layer over char* and brings none of the features of QString. Of all the failures of the C++ standards committee, std::string is the worst. Any string class has to be unicode. What it uses internally is an implementation detail (which is what started this thread). It's fine to have a pure ascii string type as well, but there are so few cases left in real world applications where this is useful. What QString internally uses is a pure optimization question, and I'll leave that to others. But whatever is decided, I want to be sure it keeps some of the things QString offers: 1) Unicode! Don't assume the user remembers to use utf8. qlabel->setText(stdString) *will* fail. Leaving decisions on encoding to users is a bad idea. 2) length() returns the number of chars I see on the screen, not a random implementation detail of the chosen encoding. 3) at(int) and [] gives the unicode char, not a random encoding char. std::string fails at those completely basic requirement, which is why you will never see me use it, unless some customer API demands it or I'm in one of those exceptional cases where there is sure to be ascii only in the strings. Another note: Latin1 is the worst idea for i18n ever invented, and it's by now useless, irrelevant and only a source for bugs once you start to truly support i18n outside of USA and Western Europe. I would be one step closer to total happiness if C++17 and Qt7 makes this "encoding" completely unsupported. I know this I've made the statements here a bit harsh, but I see the same kinds of problems again and again in customer code, when they chose to use std::string all over the place. They give the same arguments I've seen here - optimized, faster, etc - and add a few like "easier to switch away from Qt, backend is std/boost only and no Qt allowed and so on". And they pay for it in development time, bugfixing and angry users. Sure, QString isn't optimized for some cases. But I'll take a less optimized class any day over something that brings heaps of bugs. Then I have time to focus on optimizing the serious things instead of fixing bugs. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
11.02.2015, 12:13, "Marc Mutz" : > On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote: >> Marc, I'm not sure if you're arguing for or against nullptr :-)... > > Then I agree with André; you need to start reading mails (threads) before > responding :) >> On 2015-02-10 18:23, Marc Mutz wrote: >>> On Tuesday 10 February 2015 20:13:12 André Pönitz wrote: Can't you simply wait until 'nullptr' is available? >>> No. >>> >>> For a simple reason: using nullptr (Q_ or not) is more expressive than 0. >>> And why would i want to throw away information I already have? >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to >> Qt, but just saying...) > > While true, this is semantics that we can't rely on in Qt atm. Neither can > auto be used, nor can it be relied on that Q_NULLPTR doesn't convert to an > integral type. The latter is esp. interesting, as I believe some compilers > implement NULL to be nullptr-like even in C++98 (and Q_NULLPTR is NULL if it's > not nullptr), so you *may* benefit even in C++98 by using Q_NULLPTR instead of > 0. But you can't _rely_ on that. One can just use NULL and get the best of both worlds - C++98 compatibility and warnings about type conversions. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote: > Marc, I'm not sure if you're arguing for or against nullptr :-)... Then I agree with André; you need to start reading mails (threads) before responding :) > On 2015-02-10 18:23, Marc Mutz wrote: > > On Tuesday 10 February 2015 20:13:12 André Pönitz wrote: > >> Can't you simply wait until 'nullptr' is available? > > > > No. > > > > For a simple reason: using nullptr (Q_ or not) is more expressive than 0. > > And why would i want to throw away information I already have? > > (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to > Qt, but just saying...) While true, this is semantics that we can't rely on in Qt atm. Neither can auto be used, nor can it be relied on that Q_NULLPTR doesn't convert to an integral type. The latter is esp. interesting, as I believe some compilers implement NULL to be nullptr-like even in C++98 (and Q_NULLPTR is NULL if it's not nullptr), so you *may* benefit even in C++98 by using Q_NULLPTR instead of 0. But you can't _rely_ on that. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 02:22:45 Thiago Macieira wrote: > > charT do_toupper(charT c) const; > > const charT* do_toupper(charT* low, const charT* high) const; > > > > > > > > Effects: Converts a character or characters to upper case. The second > > form replaces each character *p in the range [low,high) for which a > > corresponding upper-case character exists, with that character. > > > > > > > > Returns: The first form returns the corresponding upper-case character if > > it is known to exist, or its argument if not. The second form returns > > high. > > The above does not deal with string expansion due to uppercasing (the > famous "ß" to "SS" case). The function is flawed by design. You overlooked "where a corresponding character exists". Either uppercase ß exists (it does, it was found in an old printing, so there's a movement to adopt it, except Unicode doesn't have it), then it's not a problem, or it does (as is the case in Unicode), and the character stays lower-case. The problem might exist in upper-casing i in Turkish@utf-8, though (because i is US-ASCII, but toUpper(i) isn't). > Qt has done this since Qt 2.0 (June 1999), so we're at 15 years ahead and > counting. I would simply not trust something close to two decades behind us > to do something they haven't begun to implement yet. I agree 100% that Qt is light-years ahead of the standard when it comes to all things i18n. But... You can turn this argument 180° and it explains the situation with container classes. For more than 15 years, we have a vector that can use custom allocators and can iterate backwards symmetrically. Yes, vector implementations were lacking on existing platforms as little as 8 years ago, but what if all the man-power that has gone into making sub-standard container classes for Qt had instead gone into contributing to std implementations? What does this mean? It simply means: Pick your battles. There's zero point in trying to re-invent shared_ptr or anything from the STL (except fixing max(), but how do you explain the difference to std::max(), then?). But std::locale, as is universally agreed, not just in the Qt world, is deeply flawed. Here, Qt can contribute. By implementing a better alternative (not that I think current QLocale is _that_ great), but also by helping to move the standard forward. We're seeing how we stall development when things that aren't at the core of Qt's offering are good enough for Qt. Better invest the little time that is spent the Qt containers these days on improving the STL implementations where we find them lacking. That reminds me to start looking into why std::vector::emplace_back expands to 1K of text size more than push_back(T&&) on GCC... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Tuesday 10 February 2015 17:22:45 Thiago Macieira wrote: > Because unlike std::vector, std::basic_string is woefully inadequate > compared to QString and QByteArray. I just mentioned the easy cases, but a > quick check shows how much more is lacking. > > I rest my case. QString will be there at least through the major release of > Qt released before 2020. As I said, you can still use std::basic_string as a container, and then have qToLower, qToUpper, QTextCodec::fromUnicode for tasks which you think are missing in the standard library. Then again, it is not really the time to discuss this kind of things. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Patch in qt installer framework
> -Original Message- > From: development-bounces+kai.koehne=theqtcompany.com@qt- > project.org [mailto:development- > bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of > Caspar Romot > Sent: Monday, February 02, 2015 7:51 AM > To: development@qt-project.org > Subject: [Development] Patch in qt installer framework > > Hello, > > I have made a patch in qt installer framework and created a merge request. I > now sassigned reviewers to it. I guess you're talking about https://codereview.qt-project.org/#/c/105221/ > When should I expect some sort of feedback? I see that Karsten has last replied a week ago, and said discussion should happen in https://bugreports.qt.io/browse/QTIFW-624 It's been a week since then. Anyhow, please understand there are a couple of reasons discussion stalls: People go on vacation, become ill, or have to take on more urgent tasks ... If you're wondering, you can always try to reach reviewers directly, preferably on IRC (e.g. #qt-sdk channel on freenode for the IFW). > Thank you in advance! Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] why is QJSEngine not modifying metaObject
Hi, Kind of :) It works on a type level. So a new type is defined with new methods and a new meta object is defined. But it doesn't use a mechanism where a new meta object is created each time a method is added. If we move the current engine over to generate meta objects from internal classes then perhaps we could create the meta objects on demand and batch them. That would make the example at hand work. Of course this could also be implemented by brute force, but I'm not sure it is worth it. Simon Original Message From: Thiago Macieira Sent: Wednesday, February 11, 2015 08:35 To: development@qt-project.org Subject: Re: [Development] why is QJSEngine not modifying metaObject On Wednesday 11 February 2015 07:11:26 Hausmann Simon wrote: > Hi, > > The short answer to your question is that the meta object system isn't > really designed for this. In theory this could be implemented but it would > come at a high cost for something that rarely happens. The qml engine > supports this, but in qml this happens at type compilation time, not fully > dynamic. Wasn't this how QML1 worked? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
