Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On Friday 31 July 2015 10:34:50 Knoll Lars wrote: On 31/07/15 10:15, Thiago Macieira thiago.macie...@intel.com 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 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] FW: Backwards compatibiltiy break in Qt 5.5
On Friday 31 July 2015 10:34:50 Knoll Lars wrote: On 31/07/15 10:15, Thiago Macieira thiago.macie...@intel.com 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 - 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] QDateTime is missing shared null optimization
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)
{
}
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? If so, I'd like to amend that.
Would it be preferred to introduce a
shared null like QTypedArrayData::sharedNull, or should I rather use a nullptr
to indicate the invalid state,
like in QImage? Or am I missing something and these tricks are not applicable
to QDateTime?
Grepping for QSharedDataPointer, I find many more classes that do not leverage
a shared null state. Should
we try to implement some helper functions/macros there which can be leveraged
by every user of this
class to implement a shared null state?
Bye
--
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbHCo KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QString behavior change
On Friday 31 July 2015 10:30:33 Giuseppe D'Angelo wrote: On Fri, Jul 31, 2015 at 10:25 AM, Thiago Macieira thiago.macie...@intel.com 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 spaces doesn't). Right, they are these two cases of trimmed_helper: if (begin == str.cbegin() end == str.cend()) return str; if (begin == end) return StringType(); The consistency of nullness is secondary to performance in this code section. I'm not going to add a test before those two. -- 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] Found wince info in Gerrit ,which makes me panic
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 around much longer. Iwould also like to know why qtserialbus is not supported in MS realtime system. Regards Gunnar Roth ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Found wince info in Gerrit ,which makes me panic
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 secret decison made at The qt company? But I thought wince will stay around much longer. There's no secret decision. Please see the thread Qt LTS C++11 plans. WinCE / EC 6, 7 and 8 will be dropped from Qt 5.7. WinEC 2013 will still work, as it is a target from MSVC 2012. That doesn't mean it will work for QtSerialBus. Given Alex's change, it most likely won't. Iwould also like to know why qtserialbus is not supported in MS realtime system. The RT in WinRT is stands for runtime, not real time. Almost everything for WinRT needs to be reimplemented from scratch, as the normal Win32 API is not available for applications. -- 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] Found wince info in Gerrit ,which makes me panic
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 thiago.macie...@intel.com: 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 secret decison made at The qt company? But I thought wince will stay around much longer. There's no secret decision. Please see the thread Qt LTS C++11 plans. WinCE / EC 6, 7 and 8 will be dropped from Qt 5.7. WinEC 2013 will still work, as it is a target from MSVC 2012. That doesn't mean it will work for QtSerialBus. Given Alex's change, it most likely won't. Iwould also like to know why qtserialbus is not supported in MS realtime system. The RT in WinRT is stands for runtime, not real time. Almost everything for WinRT needs to be reimplemented from scratch, as the normal Win32 API is not available for applications. -- 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] Found wince info in Gerrit ,which makes me panic
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 thiago.macie...@intel.com: 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 secret decison made at The qt company? But I thought wince will stay around much longer. There's no secret decision. Please see the thread Qt LTS C++11 plans. WinCE / EC 6, 7 and 8 will be dropped from Qt 5.7. WinEC 2013 will still work, as it is a target from MSVC 2012. That doesn't mean it will work for QtSerialBus. Given Alex's change, it most likely won't. Iwould also like to know why qtserialbus is not supported in MS realtime system. The RT in WinRT is stands for runtime, not real time. Almost everything for WinRT needs to be reimplemented from scratch, as the normal Win32 API is not available for applications. -- 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] Found wince info in Gerrit ,which makes me panic
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 - 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] FW: Backwards compatibiltiy break in Qt 5.5
On 28/07/15 21:24, Thiago Macieira thiago.macie...@intel.com 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 caused by the change. The amount of people that has since agreed with my point of view in this thread is a testament to that. Want homoglyph debugging? turn on environment variable. Simple as that. At the same time peopel with existing code won't be tearing at their hair on the prospect of retyping every qdebug instance I don't think I am underestimating the annoyance to those people nor that I am overestimating the benefit. You have also take into account that a great majority of source code is written in English and for those cases this feature is a net win. Anyway, I'm waiting for Lars to make a decision. Lars, you can either make your choices below or you may request consensus and then make your decision: 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) escape only NUL, backslash and quote e) escape nothing (5.0 through 5.4 behaviour) [I haven't included option f) mangle irrevocably (4.x behaviour)] I think (b) is the most sane option (including escaping of backslash and quote). If you’re worried about isPrint performance, feel free to optimise the ascii (or latin1) case. In practice, I don’t think this will matter currently, as qDebug is using QTextStream behind the scenes anyway. 2) ditto for qDebug for QByteArrays, except that for: b1) escape everything that isn't isprint() from ctype.h (locale dependent) b2) escape everything that isn't printable under Latin 1 Note that QByteArray::toUpper and toLower do not and have never used ctype.h and are instead fixed to Latin 1. QByteArray should probably use (a), as the encoding isn’t clear (we’re unfortunately not really consistent in our usage neither. Constructing a QString from a QByteArray assumes utf8, toUpper/toLower as you say assumes latin1). 3) QtTest should a) follow qDebug and be consistent b) do it differently, in which case we need to select which of the options Above Are there arguments against being consistent? Apart from us not wanting to change it in 5.5.1? 4) when to apply those changes, which are technically behaviour changes a) 5.5.1 b) 5.6.0 5.5.1 has my vote. Yes, we’re changing behaviour once again, but this brings it a lot closer to 5.4, while avoiding most of the issues that initially triggered the change. Note that the QtTest QString change happened in 5.4.0, so I advise against changing QTest::toString(QString) in 5.5.1, if a change is to happen. Agree. Obviously my preference has already been stated. If we eliminate 1a, my preferences are: 1c and 2a. I do not want QChar::isPrint to be used because it's expensive. As said above, I don’t think it matters, especially if we inline the ascii (and maybe latin1) case. 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 backslash. My goal is to keep the string easily readable in all languages, which is what IMO is needed to make debugging and logging easy. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QString behavior change
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 From: development-bounces+jaroslaw.kobus=theqtcompany@qt-project.org development-bounces+jaroslaw.kobus=theqtcompany@qt-project.org on behalf of Matthew Woehlke mwoehlke.fl...@gmail.com Sent: 30 July 2015 18:14 To: development@qt-project.org Subject: Re: [Development] QString behavior change On 2015-07-30 03:38, Gerhard Scheikl wrote: The behavior of QString::trimmed has changed from 5.3.2 to 5.5. .trimmed() on an empty string ( ) makes it null .trimmed() on an empty string () doesn't make it null Is this intended or a bug? Whether or not it is¹ should not be relevant; QString has for a very long time (since mid-4.x at least if not 4.0 or even longer) STRONGLY discouraged differentiating between empty and null states. Don't do that :-). (¹ For a more literal answer, see Thiago's reply.) By the way: the output of qDebug is not as expected: there are additional whitespaces before true/false and there is even another one before null at the first Before trim output. qDebug() String with space; QString my_string( ); qDebug() Before trim: empty: my_string.isEmpty() null: my_string.isNull(); my_string = my_string.trimmed(); qDebug() After trim: empty: my_string.isEmpty() null: my_string.isNull(); Output: String with space Before trim: empty: false null: false After trim: empty: true null: true Your expectation that is wrong ;-). As noted, QDebug adds spaces between things, and you have a space in ' null:', so the expected output is two spaces between the previous item and null; one added automatically by QDebug, and one that you printed explicitly. -- 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] QString behavior change
* Kobus Jaroslaw jaroslaw.ko...@theqtcompany.com [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 isEmpty? See the documentation of QString::isNull(): Qt makes a distinction between null strings and empty strings for historical reasons. For most applications, what matters is whether or not a string contains any data, and this can be determined using the isEmpty() function. Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpj9g2oX4dOl.pgp Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QString behavior change
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 changed from 5.3.2 to 5.5. .trimmed() on an empty string ( ) makes it null .trimmed() on an empty string () doesn't make it null Is this intended or a bug? This is caused by 54da2b2911ace652dbd2c8ea852c5b8c47ab09c8 in qtbase. I don't think it was intended. Actually, it was. Trimming a string that doesn't need trimming returns the original string. An empty string doesn't need trimming, therefore you get exactly what you had. But PLEASE stop relying on functions that mutate strings to reliably retain or fail to retain the nullness of a string. Unless the documentation for the particular function makes a distinction between null and not null, assume it will behave arbitrarily and will change in behaviour. 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 document them. But this surely isn't one of them? I really don't see why a non-empty string containing only whitespace would become a null string after trimming. I'd find it more logical that it would become an empty string instead. 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? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
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 backslash. My goal is to keep the string easily readable in all languages, which is what IMO is needed to make debugging and logging easy. 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 as \0xAB01 or something like that (and just leave the other occurences alone?) Or only escape them if there is something else to escape? Or even choose a different escape character completely, one that is not used as often? Paths end up in debug statements quite often (at least, in the code I work on) and I do find it confusing to have them escaped. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On Tue, Jul 28, 2015 at 9:51 AM, Gerhard Scheikl g.sche...@avibit.com 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. my opinion is that libxml is the best xml library, it is everywhere and it is very fast. I used libxml multiple times to parse big files, and this is just the best library for xml / xslt I personally don't care so much for the exact DOM/SAX API compliance, and furthermore this problem disappears because you implement a Qt API on top. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QString behavior change
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 empty string ( ) makes it null .trimmed() on an empty string () doesn't make it null Is this intended or a bug? This is caused by 54da2b2911ace652dbd2c8ea852c5b8c47ab09c8 in qtbase. I don't think it was intended. Actually, it was. Trimming a string that doesn't need trimming returns the original string. An empty string doesn't need trimming, therefore you get exactly what you had. But PLEASE stop relying on functions that mutate strings to reliably retain or fail to retain the nullness of a string. Unless the documentation for the particular function makes a distinction between null and not null, assume it will behave arbitrarily and will change in behaviour. 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 document them. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QString behavior change
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 document them. In this particular case, it was reasoned that the API was inconsistent and broken. So the behaviour was changed intentionally. -- 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] QString behavior change
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 in an empty string, do you find it (return empty)? Or do you fail to find it (return 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] QString behavior change
On Fri, Jul 31, 2015 at 10:25 AM, Thiago Macieira thiago.macie...@intel.com 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 spaces doesn't). -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QNoDebug - available but undocumented
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 QLoggingCategory? QLoggingCategory checks at runtime if the debug should be run. Which means that the compiler still need to generate the code for it. With the QNoDebug trick, everything can be removed at compile time, and nothing is generated in the binary for those debug statements. -- 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] QNoDebug - available but undocumented
qdebug.cpp should contain a comment like this: /*! \class QNoDebug \internal */ From: development-bounces+martin.smith=theqtcompany@qt-project.org development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Olivier Goffart oliv...@woboq.com Sent: Thursday, July 30, 2015 2:36 PM To: development@qt-project.org Subject: Re: [Development] QNoDebug - available but undocumented On Thursday 30. July 2015 13:33:28 Tomasz Siekierda wrote: Hi, just a quick observation: QNoDebug class can be used in code (compiles, works fine), but there is no documentation for it. Is that intentional? Shouldn't it be either hidden (made private) or documented? Although I have just learned about it's existence by accident, it looks like it can be quite useful, so I vote for adding some docs. It's a fake class that replaces QDebug when QT_NO_DEBUG_OUTPUT is defined. That way the code compiles but is optimized away. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QNoDebug - available but undocumented
On 31 July 2015 at 10:26, Smith Martin martin.sm...@theqtcompany.com 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 compiles but is optimized away. Thanks for the explanation. I've asked because I've been surprised to see it being used in some project like this: #ifdef DEBUG_FETCHER #define fetcherDebug qDebug() #else #define fetcherDebug NoDebug() #endif as a temporary solution to enable debug output of a new feature. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
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 as \0xAB01 or something like that (and just leave the other occurences alone?) Or only escape them if there is something else to escape? So you're proposing that qDebug should output: C:\\Users C:\\users C:\\01.org C:\\newdir C:\Windows Sorry, no, that's a total veto from me. Or even choose a different escape character completely, one that is not used as often? I don't think that's a good idea. What character can we use that is among the 94 from US-ASCII that aren't control characters already or the space? It's only going to punt the problem elsewhere and cause more confusion because such character is not used as often to escape things. It has to be a non-control character because this thread has shown that qDebug output is read by people. A control character that isn't visible can't be seen by people. The only alternative is to not escape the backslash and the quote at all, in which case these two completely different strings would be printed the same way: QString(C:\\u00a0); QString::fromUtf8(C:\\u\xc3\xa0); as C:\u00a0 -- 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] FW: Backwards compatibiltiy break in Qt 5.5
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) escape only NUL, backslash and quote e) escape nothing (5.0 through 5.4 behaviour) [I haven't included option f) mangle irrevocably (4.x behaviour)] I think (b) is the most sane option (including escaping of backslash and quote). If you’re worried about isPrint performance, feel free to optimise the ascii (or latin1) case. In practice, I don’t think this will matter currently, as qDebug is using QTextStream behind the scenes anyway. No optimisation because, as this thread has shown, non-ASCII text is common. Therefore, optimising for a particular case is not necessary and might just hurt the whole scenario. Besides, it's *debugging*, which implies slow code anyway. I'd rather make this simpler. 2) ditto for qDebug for QByteArrays, except that for: b1) escape everything that isn't isprint() from ctype.h (locale dependent) b2) escape everything that isn't printable under Latin 1 Note that QByteArray::toUpper and toLower do not and have never used ctype.h and are instead fixed to Latin 1. QByteArray should probably use (a), as the encoding isn’t clear (we’re unfortunately not really consistent in our usage neither. Constructing a QString from a QByteArray assumes utf8, toUpper/toLower as you say assumes latin1). Ok, so no change for QByteArray. 3) QtTest should a) follow qDebug and be consistent b) do it differently, in which case we need to select which of the options Above Are there arguments against being consistent? Apart from us not wanting to change it in 5.5.1? Same as before: we're trying to figure out why two strings are not the same. I'd rather *see* the evidence than try to guess. 4) when to apply those changes, which are technically behaviour changes a) 5.5.1 b) 5.6.0 5.5.1 has my vote. Yes, we’re changing behaviour once again, but this brings it a lot closer to 5.4, while avoiding most of the issues that initially triggered the change. Ok. 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 backslash. My goal is to keep the string easily readable in all languages, which is what IMO is needed to make debugging and logging easy. Ok. I will try to submit a patch tomorrow. -- 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] QNoDebug - available but undocumented
-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 martin.sm...@theqtcompany.com Cc: development@qt-project.org Subject: Re: [Development] QNoDebug - available but undocumented On 31 July 2015 at 10:26, Smith Martin martin.sm...@theqtcompany.com 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 compiles but is optimized away. Thanks for the explanation. I've asked because I've been surprised to see it being used in some project like this: #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 QLoggingCategory? ___ 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] Replace QtXml backend
31.07.2015, 10:43, Sylvain Pointeau sylvain.point...@gmail.com: On Tue, Jul 28, 2015 at 9:51 AM, Gerhard Scheikl g.sche...@avibit.com 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. my opinion is that libxml is the best xml library, it is everywhere and it is very fast. I used libxml multiple times to parse big files, and this is just the best library for xml / xslt I personally don't care so much for the exact DOM/SAX API compliance, and furthermore this problem disappears because you implement a Qt API on top. I use pugixml. It's lightning fast because it makes no string copies and doesn't convert input to UTF16 (unlike Qt's parsers) -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
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 thiago.macie...@intel.com wrote: 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 as \0xAB01 or something like that (and just leave the other occurences alone?) Or only escape them if there is something else to escape? So you're proposing that qDebug should output: C:\\Users C:\\users C:\\01.org C:\\newdir C:\Windows Sorry, no, that's a total veto from me. Or even choose a different escape character completely, one that is not used as often? I don't think that's a good idea. What character can we use that is among the 94 from US-ASCII that aren't control characters already or the space? It's only going to punt the problem elsewhere and cause more confusion because such character is not used as often to escape things. It has to be a non-control character because this thread has shown that qDebug output is read by people. A control character that isn't visible can't be seen by people. The only alternative is to not escape the backslash and the quote at all, in which case these two completely different strings would be printed the same way: QString(C:\\u00a0); QString::fromUtf8(C:\\u\xc3\xa0); as C:\u00a0 -- 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] FW: Backwards compatibiltiy break in Qt 5.5
On 31/07/15 10:15, Thiago Macieira thiago.macie...@intel.com 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
