On 21/10/15 08:37,
"development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
Thiago Macieira"
wrote:
>Em qua 21 out 2015, às 06:29:30, Knoll Lars escreveu:
>> As I remember it, the change from QSubString to QStringRef was a simple API
>> naming decision, i.e. independen
2015-10-21 4:15 GMT+03:00 Robert Griebl :
> On 20.10.2015 17:56, Thiago Macieira wrote:
>> ...because the application will unload the libraries while other threads are
>> still running code from those threads. In the bug report, the crash happens
>> because of the QXcbEventReader thread, but it cou
Em qua 21 out 2015, às 06:29:30, Knoll Lars escreveu:
> As I remember it, the change from QSubString to QStringRef was a simple API
> naming decision, i.e. independent of the implementation details.
Then it must be a coincidence that it changed internals more or less at the
same time.
> The re
On 20/10/15 18:11,
"development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
Thiago Macieira"
wrote:
>On Tuesday 20 October 2015 08:49:17 André Somers wrote:
>> Op 19-10-2015 om 17:54 schreef Thiago Macieira:
>> > First of all, QStringRef keeps a pointer to the original QS
Thanks for pointing out that Jira feature. Getting the data manually was
quite easy Actually.
What I am trying to find out is how unresolved P1 issues changes relative
to all P1 issues. The ratio is growing exponentially. That should be
worrying considering the definition of P1: Critical - Urgent
* Çağdaş Kayra Akman [2015-10-21 00:42:49 +0300]:
> After being bitten by some showstopper bugs in the last few Qt releases, I
> have decided to gather some P1 statistics. I thought you might find the
> numbers interesting.
Are you aware of the reports JIRA can generate[1]? Might make this
kind o
On 20.10.2015 17:56, Thiago Macieira wrote:
> ...because the application will unload the libraries while other threads are
> still running code from those threads. In the bug report, the crash happens
> because of the QXcbEventReader thread, but it could have been any other thread
> we start or any
Hi,
After being bitten by some showstopper bugs in the last few Qt releases, I
have decided to gather some P1 statistics. I thought you might find the
numbers interesting.
Regards,
Kayra Akman
Qt_P1.ods
Description: application/vnd.oasis.opendocument.spreadsheet
On Tuesday 20 October 2015 23:51:12 Marc Mutz wrote:
> On Tuesday 20 October 2015 17:56:33 Thiago Macieira wrote:
> > Can anyone think of a solution to this problem?
>
> Don't call ::exit()? I'm only half-joking. Who calls ::exit() in a C++
> program (apart from implicitly by leaving main())?
The
On Tuesday 20 October 2015 17:56:33 Thiago Macieira wrote:
> Can anyone think of a solution to this problem?
Don't call ::exit()? I'm only half-joking. Who calls ::exit() in a C++ program
(apart from implicitly by leaving main())?
Wild guess: maybe std::terminate() works better?
--
Marc Mutz
On Tuesday 20 October 2015 08:49:17 André Somers wrote:
> Op 19-10-2015 om 17:54 schreef Thiago Macieira:
> > First of all, QStringRef keeps a pointer to the original QString, so it
> > isn't as fragile as QStringView. In fact, during the development of the
> > XML stream classes, there was a QSubS
On Tuesday 20 October 2015 10:06:28 Julien Blanc wrote:
> Le lundi 19 octobre 2015 à 16:08 -0700, Thiago Macieira a écrit :
> > So the summary of QStringView is:
> > a) never used as return type
> > b) used only as a parameter if the function processes the data and never
> > stores it and wi
...because the application will unload the libraries while other threads are
still running code from those threads. In the bug report, the crash happens
because of the QXcbEventReader thread, but it could have been any other thread
we start or any other library starts.
Can anyone think of a sol
Op 20-10-2015 om 11:08 schreef Иван Комиссаров:
> Btw, isn't the QStringView is the same as Range
> { Container::Iterator begin; Container::Iterator end; } ?
> Why we introduce only QStringView/QByteArrayView? Maybe we should
> think about adding range API to all containers?
>
> Alexandrescus pre
On Tuesday 20 October 2015 11:08:51 Иван Комиссаров wrote:
> Btw, isn't the QStringView is the same as Range
> { Container::Iterator begin; Container::Iterator end; } ?
No. A string_view (or QStringView) is targeted at string operations. A range
is just a pair of iterators.
> Why we introduce on
On Tuesday 20 October 2015 09:13:18 Smith Martin wrote:
> I see. But then, if I have QStringView, doesn't that eliminate most of the
> reasons for needing the other string containing classes? If I want the
> efficiency of QStringView, won't QString underneath always be the right
> choice?
No. Two
Btw, isn't the QStringView is the same as Range
{ Container::Iterator begin; Container::Iterator end; } ?
Why we introduce only QStringView/QByteArrayView? Maybe we should think
about adding range API to all containers?
Alexandrescus presentation about ranges:
http://www.slideshare.net/rawwell/ite
I guess we need QStringView for QString and QByteArrayView for QByteArray, etc.
martin
From: development-bounces+martin.smith=theqtcompany@qt-project.org
on behalf of
Smith Martin
Sent: Tuesday, October 20, 2015 9:13 AM
To: Marc Mutz; development@q
On October 20, 2015 10:10:36 Knoll Lars wrote:
> On 20/10/15 09:59, "Bubke Marco" wrote:
>
>>On October 20, 2015 08:43:26 Thiago Macieira
>>wrote:
>>
>>> On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote:
So if deep copies loose their ineffciency myth, what reason remains to
not
On 20/10/15 09:59, "Bubke Marco" wrote:
>On October 20, 2015 08:43:26 Thiago Macieira
>wrote:
>
>> On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote:
>>> So if deep copies loose their ineffciency myth, what reason remains to
>>>not
>>> use QSV in all functions taking QString?
>>
>> Complicati
Le lundi 19 octobre 2015 à 16:08 -0700, Thiago Macieira a écrit :
>
> So the summary of QStringView is:
> a) never used as return type
> b) used only as a parameter if the function processes the data and never
> stores it and will never, ever store it (lazy processing)
> c) for existing
Gentlemen,
Making custom Qt Platform Menu on iOS as advised by Richard Moe
(https://bugreports.qt.io/browse/QTBUG-41275)
was working fine with Qt-5.4 on iOS 7, 8 and the recent 9.
After upgrading to Qt-5.5, I'm getting all iOS-standard menu items
additionally to my menu items, tested on iOS-9.0.2
On October 20, 2015 08:43:26 Thiago Macieira wrote:
> On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote:
>> So if deep copies loose their ineffciency myth, what reason remains to not
>> use QSV in all functions taking QString?
>
> Complicating the API.
>
> You cannot possibly prove that doing
That's QByteArray at the end, of course.
From: development-bounces+martin.smith=theqtcompany@qt-project.org
on behalf of
Smith Martin
Sent: Tuesday, October 20, 2015 9:13 AM
To: Marc Mutz; development@qt-project.org
Subject: Re: [Development] RFC: P
I see. But then, if I have QStringView, doesn't that eliminate most of the
reasons for needing the other string containing classes? If I want the
efficiency of QStringView, won't QString underneath always be the right choice?
In Thiago's example, if I have a QStringView API on my class, would I
25 matches
Mail list logo
