On Friday 31 July 2015 10:34:50 Knoll Lars wrote:
> On 31/07/15 10:15, "Thiago Macieira" wrote:
> [snip]
>
> >I will try to submit a patch tomorrow.
>
> Thanks Thiago!
Done.
Change: https://codereview.qt-project.org/122598
Doc update: https://codereview.qt-project.org/121992
--
Thiago Maciei
On Friday 31 July 2015 20:52:31 Gunnar Roth wrote:
> I am not talking about winrt AS this RT does not mean realtime, fair enough.
> BUT i am talking about wince,thought I made that clear.
You were, but I got confused when you said realtime. I didn't know WinCE is
realtime.
--
Thiago Macieira - t
And I read this thread.actually I wrote quite some messages in that. Seems not
to be The case for qt company employees.
Am 31.07.2015 20:21 schrieb Thiago Macieira :
>
> On Friday 31 July 2015 18:40:02 Gunnar Roth wrote:
> > Hi.
> > I found https://codereview.qt-project.org/#/c/122523/
> > Whi
I am not talking about winrt AS this RT does not mean realtime, fair enough.
BUT i am talking about wince,thought I made that clear.
Am 31.07.2015 20:21 schrieb Thiago Macieira :
>
> On Friday 31 July 2015 18:40:02 Gunnar Roth wrote:
> > Hi.
> > I found https://codereview.qt-project.org/#/c/122
On Friday 31 July 2015 18:40:02 Gunnar Roth wrote:
> Hi.
> I found https://codereview.qt-project.org/#/c/122523/
> Which says
> This library is not supported on WINCE.
> The target is to disappear from Qt very soon anyway.
> This is written by alexander.blasche@theqtcompany
> So is there some secre
Hi.
I found https://codereview.qt-project.org/#/c/122523/
Which says
This library is not supported on WINCE.
The target is to disappear from Qt very soon anyway.
This is written by alexander.blasche@theqtcompany
So is there some secret decison made at The qt company?
But I thought wince will stay a
On Friday 31 July 2015 17:20:02 Milian Wolff wrote:
> Most other classes in Qt are cheap to generate in an empty/invalid state,
> not so for QDateTime. Is there a reason for that, or is it just an
> oversight?
Oversight.
> If so, I'd like to amend that. Would it be preferred to
> introduce a sh
On Friday 31 July 2015 10:30:33 Giuseppe D'Angelo wrote:
> On Fri, Jul 31, 2015 at 10:25 AM, Thiago Macieira
>
> wrote:
> > In this particular case, it was reasoned that the API was inconsistent and
> > broken. So the behaviour was changed intentionally.
>
> TBH, it looks like it's still inconsi
On Friday 31 July 2015 10:34:50 Knoll Lars wrote:
> On 31/07/15 10:15, "Thiago Macieira" wrote:
> [snip]
>
> >I will try to submit a patch tomorrow.
>
> Thanks Thiago!
Without changing QtTest. That is, I'd like to keep the QString escaping in
QtTest exactly as it is today.
--
Thiago Macieira
Hello all,
I just realized that QDateTime in Qt 5 is still not implementing the "shared
null optimization" - I'm not sure
it's the right term.
What I mean is that you'll incur a heap allocation when doing
QDateTime invalidDate;
See:
QDateTime::QDateTime()
: d(new QDateTimePrivate)
{
}
Mo
31.07.2015, 10:43, "Sylvain Pointeau" :
> On Tue, Jul 28, 2015 at 9:51 AM, Gerhard Scheikl wrote:
>> I found a nice image on stackoverflow:
>> http://stackoverflow.com/questions/9387610/what-xml-parser-should-i-use-in-c
>>
>> If it is true, then our choice would be xerces because libxml2 doesn't
Agree with Thiago. Backslash is a good escape character, as it’s used in
pretty much all programming languages for that. If you want unescaped
paths, you can use noquote, or print the paths using slashes (using
QDir::fromNativeSeparators()).
Cheers,
Lars
On 31/07/15 10:23, "Thiago Macieira" wrot
On 31/07/15 10:15, "Thiago Macieira" wrote:
[snip]
>I will try to submit a patch tomorrow.
Thanks Thiago!
Cheers,
Lars
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Friday 31. July 2015 08:48:24 Curtis Mitch wrote:
> > #ifdef DEBUG_FETCHER
> > #define fetcherDebug qDebug()
> > #else
> > #define fetcherDebug NoDebug()
> > #endif
> >
> > as a temporary solution to enable debug output of a new feature.
>
> What's the benefit of this over QLoggingCate
> -Original Message-
> From: development-bounces+mitch.curtis=theqtcompany@qt-project.org
> [mailto:development-bounces+mitch.curtis=theqtcompany.com@qt-
> project.org] On Behalf Of Tomasz Siekierda
> Sent: Friday, 31 July 2015 10:43 AM
> To: Smith Martin
> Cc: development@qt-project.o
On 31 July 2015 at 10:26, Smith Martin wrote:
> qdebug.cpp should contain a comment like this:
>
> /*!
> \class QNoDebug
> \internal
> */
Well, it does not contain this comment.
Olivier Goffart:
> It's a fake class that replaces QDebug when QT_NO_DEBUG_OUTPUT is defined.
> That way the code
On Fri, Jul 31, 2015 at 10:25 AM, Thiago Macieira
wrote:
>
> In this particular case, it was reasoned that the API was inconsistent and
> broken. So the behaviour was changed intentionally.
TBH, it looks like it's still inconsistent (an empty string keeps its
storage allocated, a string made of s
qdebug.cpp should contain a comment like this:
/*!
\class QNoDebug
\internal
*/
From: development-bounces+martin.smith=theqtcompany@qt-project.org
on behalf of
Olivier Goffart
Sent: Thursday, July 30, 2015 2:36 PM
To: development@qt-project.org
On Friday 31 July 2015 09:48:08 Oswald Buddenhagen wrote:
> well, that recommendation is reasonable in face of the status quo, but
> i think we should (and could) do a better job at preserving nullness.
> there are only a handful of cases where the choice is arbitrary, and we
> can clearly documen
On Friday 31 July 2015 09:53:32 André Somers wrote:
> If nullness can't be relied on to be retained or non-null strings can
> degrade into being a null string, what's the point of having it at all?
There are corner-cases. Like using QString() to indicate no match found.
When you search for empty
On Friday 31 July 2015 09:29:36 André Somers wrote:
> Does it? The output is not aimed at being C++ again. So, why is is
> needed that the backslash is always escaped? Would it be possible to
> only escape \ if it is followed by 0x in the actual string, and then
> make escaped characters print a
On Friday 31 July 2015 07:20:00 Knoll Lars wrote:
> >1) qDebug for QStrings should
> >
> > a) escape everything non-US-ASCII (5.5.0 behaviour)
> > b) escape everything that isn't QChar::isPrint
> > c) escape only US-ASCII control characters (0 to 31), backslash and
> >
> >quote
> >
> > d) escap
* Kobus Jaroslaw [2015-07-31 07:46:07 +]:
> If you say not to differentiate empty and null states, some questions arise:
> 1) Why we have isNull and isEmpty at the same time?
> 2) Why their implementations are different?
> 3) What would be the advice on what to use in general: isNull of isEmpt
Op 31-7-2015 om 09:48 schreef Oswald Buddenhagen:
> On Thu, Jul 30, 2015 at 08:37:28AM -0700, Thiago Macieira wrote:
>> On Thursday 30 July 2015 11:47:16 Olivier Goffart wrote:
>>> On Thursday 30. July 2015 09:38:12 Gerhard Scheikl wrote:
Hi
The behavior of QString::trimmed has chang
On Thu, Jul 30, 2015 at 08:37:28AM -0700, Thiago Macieira wrote:
> On Thursday 30 July 2015 11:47:16 Olivier Goffart wrote:
> > On Thursday 30. July 2015 09:38:12 Gerhard Scheikl wrote:
> > > Hi
> > >
> > > The behavior of QString::trimmed has changed from 5.3.2 to 5.5.
> > > .trimmed() on an empt
If you say not to differentiate empty and null states, some questions arise:
1) Why we have isNull and isEmpty at the same time?
2) Why their implementations are different?
3) What would be the advice on what to use in general: isNull of isEmpty?
Jarek
Fro
On Tue, Jul 28, 2015 at 9:51 AM, Gerhard Scheikl
wrote:
>
> I found a nice image on stackoverflow:
>
> http://stackoverflow.com/questions/9387610/what-xml-parser-should-i-use-in-c
>
> If it is true, then our choice would be xerces because libxml2 doesn't
> have an
> exact DOM/SAX API compliance.
Op 31-7-2015 om 09:20 schreef Knoll Lars:
>
> Anything except 1e will still change "C:\Users" to "C:\\Users" in the
> output,
> which was one of the complaints listed.
> Yes, but this is unavoidable. We need to escape non printable characters
> and quote, and this implies we also need to escape the
On 28/07/15 21:24, "Thiago Macieira" wrote:
>On Tuesday 28 July 2015 21:58:08 NIkolai Marchenko wrote:
>> Fact is : you are severly overestimating the amount of cases where
>> homoglyph is a problem at the same time severly underestimating the
>>amount
>> of code you broke and inconvenience cause
29 matches
Mail list logo
