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 o
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 repre
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:
>> > > >
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
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
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 some
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,
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 use
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
>> > performanc
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
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
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 pt
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 J
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
> shoul
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 proper
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 sayi
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'
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?
>
>
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
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
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.
>
>
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, Ke
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 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 te
> > 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 st
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
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
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
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 co
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?
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 suppose
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.or
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
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
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?
>
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 type
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 p
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
_
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 strin
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)
__
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
>
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(
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
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(), ::to
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 wh
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 d
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 num
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 doub
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, becaus
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 ae
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 t
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 Javascri
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
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
func
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 varian
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
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 sufficien
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 ov
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
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
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 a
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,
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 exam
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
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 m
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 t
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
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
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 rang
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
> -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: [Deve
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
72 matches
Mail list logo
