[Development] Doc: Making it easier for devs to know if a class is supported on a given platform

Hi all, With the proliferation of supported platforms and add-on modules, we now have a situation where some classes are only useable on particular platforms. There've been cases where a developer sees a class in the Qt docs and thinks "Ooh, this is just what I need!", only to find out (after spen

Re: [Development] What kind of airplane we want to build?

On Saturday 23 January 2016 01:44:32 Kevin Kofler wrote: > Marc Mutz wrote: > > I'm not saying we don't need new API should we replace QThread with > > std::thead. I'm saying that all the hard, impressive, work is already > > done. It seems to be mostly a question of API now. > > It shall be noted

Re: [Development] What kind of airplane we want to build?

On Saturday 23 January 2016 01:23:30 Kevin Kofler wrote: > I feel it's actually TOO rapidly changing. C++11 even threw out C > compatibility, not only by not adopting all C99 improvements (e.g. VLAs), > but also by subtly interpreting even as simple valid C90 code as "auto x = > 1.5;" in an incompa

Re: [Development] What kind of airplane we want to build?

Marc Mutz wrote: > I'm not saying we don't need new API should we replace QThread with > std::thead. I'm saying that all the hard, impressive, work is already > done. It seems to be mostly a question of API now. It shall be noted that QThread has backends for both POSIX threads (pthreads) and Win

Re: [Development] What kind of airplane we want to build?

On Saturday 23 January 2016 01:12:51 Kevin Kofler wrote: > I wonder why everyone so far agreed on that. So let me dissent: I think > having these things in Qt with Qt-style APIs is a good thing and I don't see > why we should discard our solution for the STL one. At most, where it makes > sense, we

Re: [Development] What kind of airplane we want to build?

Bubke Marco wrote: > I think many feel that C++ is rapidly changing. I feel it's actually TOO rapidly changing. C++11 even threw out C compatibility, not only by not adopting all C99 improvements (e.g. VLAs), but also by subtly interpreting even as simple valid C90 code as "auto x = 1.5;" in an

Re: [Development] What kind of airplane we want to build?

Ziller Eike wrote: >> I would like that trend to continue. The likely next candidates are >> threads, futures and locks. > > +1 I wonder why everyone so far agreed on that. So let me dissent: I think having these things in Qt with Qt-style APIs is a good thing and I don't see why we should disc

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 22:51:30 Kevin Kofler wrote: > Sure, Qt 3's QList was also a linked list, but I have internalized the Qt 4 > changes by now. Nitpick: that's Qt 2's QList. In Qt 3, we had QValueList and QPtrList. Qt 3's QValueList (which was a linked list) became Qt 4's QList whereas QP

Re: [Development] Question about QCoreApplicationData::*_libpaths

Marc Mutz wrote: > But again, CoW can be retrofitted onto any value type (e.g. > shared_ptr), while CoW types will never be truly value types. Again this nonsensical claim that shared_ptr is CoW. I already replied once explaining that it is not. Or where do you see a copy on write being done? sh

Re: [Development] Question about QCoreApplicationData::*_libpaths

Giuseppe D'Angelo wrote: > If you have QVector v; , and > > thread 1 does v[5] = ...; > thread 2 does QVector copy = v; > > without synchronizations, then you have a data race since QVector is only > reentrant. Of course you would. You would have a data race there even without CoW. Kevi

Re: [Development] Question about QCoreApplicationData::*_libpaths

Иван Комиссаров wrote: > Why? In case of QMap, we have no need to use operator= to change the map. > We simply detach and insert new data in it. Even operator= would actually be safe here. Kevin Kofler ___ Development mailing list Development@q

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Saturday 23 January 2016 00:11:27 Marc Mutz wrote: > Running attached test program (4 cores + 2-fold HT), I get these numbers: Same machine as described earlier. Linux 3.2, GCC 5.3, libc 2.13, 8GiB RAM. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Com

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 20:46:54 Marc Mutz wrote: > Which one is faster? On a dual-core, probably QVector. On a 64-core > processor, probably std::vector. Running attached test program (4 cores + 2-fold HT), I get these numbers: QVector; 1: 483 2: 492 4: 498 8: 503 16: 502 32: 513 64: 631 128

Re: [Development] Question about QCoreApplicationData::*_libpaths

Marc Mutz wrote: > Judging from the comments on my blog post from 2010(!), when they hear > QList people first think std::list (ie. linked list). Then they see that > there's also a QLinkedList and start thinking that QList is something like > std::deque. And then, if they are lucky, they realise i

Re: [Development] What kind of airplane we want to build?

On 23/01/16 04:37, Allan Sandfeld Jensen wrote: As I said, exceptions are like*a life vest*, they should be used *only in >critical situations* not everywhere. > Using them anywhere, can break code everywhere as the number of return points and code paths immediately becomes near infinite. They

Re: [Development] What kind of airplane we want to build?

On 22/01/16 18:52, Hausmann Simon wrote: I'm of the opinion that our mission should be to make life easier for programmers. I think this has always been the main mission for Qt. ___ Development mailing list Development@qt-project.org http://lists.

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 13:37:22 Matthew Woehlke wrote: > If you really have *the same* vector... Don't do that :-). Note that > this implies that you are either operating on the same variable, or one > thread is operating on a reference. That's not very common, and it's > just not thread safe, e

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 18:02:53 Bubke Marco wrote: > Actually what is happen if I am in the middle of changing a qvector, and > then copying the vector in an other thread? s/qvector/int/ and that answers your question. If you're mutating the same variable, then either use a mutex or use atom

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 19:37:22 Matthew Woehlke wrote: > On 2016-01-22 13:02, Bubke Marco wrote: > > Actually what is happen if I am in the middle of changing a qvector, and > > then copying the vector in an other thread? > > Are you concurrently modifying and copying *the same* vector, or a >

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 18:34:26 Matthew Woehlke wrote: > On 2016-01-22 13:13, Marc Mutz wrote: > > On Friday 22 January 2016 17:44:40 Thiago Macieira wrote: > >> On Friday 22 January 2016 11:14:47 Marc Mutz wrote: > >>> On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: > What >

Re: [Development] Question about QCoreApplicationData::*_libpaths

On 2016-01-22 13:02, Bubke Marco wrote: > Actually what is happen if I am in the middle of changing a qvector, and > then copying the vector in an other thread? Are you concurrently modifying and copying *the same* vector, or a shallow copy that, under the hood, happens to be shared? The latter

Re: [Development] What kind of airplane we want to build?

On Friday 22 January 2016, Bogdan Vatra wrote: > On Friday 22 January 2016 10:55:34 Cristian Adam wrote: > > On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote: > > > I'm not sure about what outcome to expect, and I don't remember any > > > numbers > > > posted by anyone else, either. > > > > From

Re: [Development] Question about QCoreApplicationData::*_libpaths

Il 22 gen 2016 6:03 PM, "Bubke Marco" ha scritto: > > Actually what is happen if I am in the middle of changing a qvector, and then copying the vector in an other thread? > If you have QVector v; , and thread 1 does v[5] = ...; thread 2 does QVector copy = v; without synchronizations, then you

Re: [Development] Question about QCoreApplicationData::*_libpaths

Actually what is happen if I am in the middle of changing a qvector, and then copying the vector in an other thread? -- Sent from cellphone, sorry for the typos On January 22, 2016 18:34:46 Matthew Woehlke wrote: > On 2016-01-22 13:13, Marc Mutz wrote: >> On Friday 22 January 2016 17:44:40

Re: [Development] Question about QCoreApplicationData::*_libpaths

On 2016-01-22 13:13, Marc Mutz wrote: > On Friday 22 January 2016 17:44:40 Thiago Macieira wrote: >> On Friday 22 January 2016 11:14:47 Marc Mutz wrote: >>> On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: What i'm missing? >>> >>> You haven't done the exercise with the int first

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 17:44:40 Thiago Macieira wrote: > On Friday 22 January 2016 11:14:47 Marc Mutz wrote: > > On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: > > > What > > > i'm missing? > > > > You haven't done the exercise with the int first. > > Here's the exercise with int. T

Re: [Development] What kind of airplane we want to build?

On Friday 22 January 2016 13:56:32 Konstantin Tokarev wrote: > Yeah, but compiler cannot perform some optimizations even when your code > does not throw anything, just because exceptions are enabled, if it does > not know for sure that called code may not throw. We've been plastering our API with

Re: [Development] What kind of airplane we want to build?

On Friday 22 January 2016 11:26:55 Bogdan Vatra wrote: > AFAIK C++11/14 compilers have zero-cost exception, so, is there any reason > why not start using them in Qt 6.0 ? Yes. There's a couple of man-decades worth of work to make entire Qt thread- safe. Then there's the whole discussion about wha

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 11:14:47 Marc Mutz wrote: > On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: > > What > > i'm missing? > > You haven't done the exercise with the int first. Here's the exercise with int. This is thread-safe: int f() { return 1; } auto x = f();

Re: [Development] Heads up for Qt Bug Report & Code Review users

On Friday 22 January 2016 15:16:54 Oswald Buddenhagen wrote: > here's an idea: we can make an email alias on the qt-project mta (which > gerrit uses for notifications), so your account (and list activity) > would look all intel-y, but all mail would actually go elsewhere. this > would affect all an

Re: [Development] extending QtMacExtras?

Sorvig Morten wrote: >> One thing that's really missing from Qt at the moment is a way for an >> application that is not the foreground application to post a window in the >> foreground (cf. also my thread on extending QProcess). To my knowledge this >> can only be done by forcing the application

Re: [Development] Fwd: A simple analysis of apps using qtbase's private headers

On Friday 22 January 2016 18:09:55 NIkolai Marchenko wrote: > Speaking of workarounds : > I have to use this ugly hack that depends on otherwise inaccessible code to > update QPrintPreviewDialog > > //dia is a QPrintPreviewDialog > QPrintPreviewWidget* w = dia->findChild(); > QMetaObject::invokeMe

[Development] Charts and DataVis Questions

Hi, I have few naive questions about Charts and DataVis modules. 1) As I understand DataVis module is mainly a 3d data visualization module while Charts is mainly a 1d data visualization module. Why not merging them to a unique data visualization module? In my lab scientists are interested in plo

Re: [Development] Fwd: A simple analysis of apps using qtbase's private headers

Speaking of workarounds : I have to use this ugly hack that depends on otherwise inaccessible code to update QPrintPreviewDialog //dia is a QPrintPreviewDialog QPrintPreviewWidget* w = dia->findChild(); QMetaObject::invokeMethod(w, "updatePreview", Qt::QueuedConnection); can you please add "updat

Re: [Development] Fwd: A simple analysis of apps using qtbase's private headers

On Fri, Jan 22, 2016, at 03:57 PM, PCMan wrote: > > The following three seems to be using at least qpa/qplatformtheme.h > > > > * KDE's frameworkintegration 5.16.0 > > * libqtxdg 1.3.0 > > * lxqt-qtplugin 0.10.0 > > > > Maybe for being able to create it's own theme? > > > > > Yes, but it's not on

[Development] Fwd: A simple analysis of apps using qtbase's private headers

-- Forwarded message -- From: PCMan Date: Fri, Jan 22, 2016 at 10:56 PM Subject: Re: [Development] A simple analysis of apps using qtbase's private headers To: Lisandro Damián Nicanor Pérez Hello, I'm one of the LXQt developers so I can answer part of your questions. On Fri, Ja

Re: [Development] Question about QCoreApplicationData::*_libpaths

On 2016-01-22 05:00, Marc Mutz wrote: > On Friday 22 January 2016 09:43:17 Иван Комиссаров wrote: >> Why? In case of QMap, we have no need to use operator= to change the map. >> We simply detach and insert new data in it. >> Of course, in case of multiple changes, the map can reach some "invalid >>

Re: [Development] Heads up for Qt Bug Report & Code Review users

On Thu, Jan 21, 2016 at 10:27:06AM +, Jokiniva Jukka wrote: > Use your unified Qt Account credentials to login from now on. > fwiw, i'm anticipating that everyone who still used two different accounts for jira (proper) and gerrit will have problems now (though maybe not quite as tough as thiag

Re: [Development] Question about QCoreApplicationData::*_libpaths

On 2016-01-21 17:35, Milian Wolff wrote: > On Donnerstag, 21. Januar 2016 22:44:02 CET Andre Somers wrote: >> So, please, enlighten me. What would be a realistic way to recover from >> such an exception? > > [...] > - abort whole application in orderly fashion (i.e. not terminate but do a > real

Re: [Development] Heads up for Qt Bug Report & Code Review users

On Thu, Jan 21, 2016 at 03:50:58PM -0800, Thiago Macieira wrote: > Looks like I will soon[*] have a problem: I use two different accounts for my > Qt services. I need to use the account associated with my Intel mail address > for Code Review, as that's the one associated with the Corporate CLA. >

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Thursday, January 21, 2016 12:10:21 PM CET Matthew Woehlke wrote: > On 2016-01-20 23:44, Kevin Kofler wrote: > > Almost all my containers grow with allocations. How should I know in > > advance how much memory to reserve? It'd just waste an arbitrary amount > > of memory and then still end up re

Re: [Development] What kind of airplane we want to build?

22.01.2016, 13:32, "Bogdan Vatra" : > On Friday 22 January 2016 10:55:34 Cristian Adam wrote: >>  On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote: >>  > I'm not sure about what outcome to expect, and I don't remember any >>  > numbers >>  > posted by anyone else, either. >> >>  From the David

Re: [Development] Question about QCoreApplicationData::*_libpaths

Le vendredi 22 janvier 2016 à 01:13 +0100, Kevin Kofler a écrit : > > I think Qt should ignore the "wider C++ community", too. The STL is really a > completely different beast, we only share the language-level parts. That statement sounds very harsh. Please remember that your users are part o

Re: [Development] What kind of airplane we want to build?

On Friday 22 January 2016 10:55:34 Cristian Adam wrote: > On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote: > > I'm not sure about what outcome to expect, and I don't remember any > > numbers > > posted by anyone else, either. > > From the David Stone's Writing Robust Code >

Re: [Development] What kind of airplane we want to build?

Also, exceptions tend to hinder refactoring. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

> On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote: >> I'm not sure about what outcome to expect, and I don't remember any >> numbers posted by anyone else, either. Cristial replied: > From the David Stone's Writing Robust Code page 34: However, see what Marc said about how to do a proper comp

Re: [Development] What kind of airplane we want to build?

22.01.2016, 12:50, "Marc Mutz" : > On Friday 22 January 2016 10:38:28 Welbourne Edward wrote: >>  > AFAIK C++11/14 compilers have zero-cost exception, so, is there any >>  > reason why not start using them in Qt 6.0 ? >> >>  Any "zero cost" claim is with respect to some assumed base-point. ISTR >

Re: [Development] What kind of airplane we want to build?

On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote: > > I'm not sure about what outcome to expect, and I don't remember any numbers > posted by anyone else, either. > > > >From the David Stone's Writing Robust Code page 34: Performance

Re: [Development] What kind of airplane we want to build?

On Friday 22 January 2016 10:38:28 Welbourne Edward wrote: > > AFAIK C++11/14 compilers have zero-cost exception, so, is there any > > reason why not start using them in Qt 6.0 ? > > Any "zero cost" claim is with respect to some assumed base-point. ISTR > exceptions require RTTI (run-time type in

Re: [Development] What kind of airplane we want to build?

On Fri, Jan 22, 2016 at 10:26 AM, Bogdan Vatra wrote: > > AFAIK C++11/14 compilers have zero-cost exception, so, is there any reason > why > not start using them in Qt 6.0 ? > > +1 Exceptions in normal path lead to faster execution than using return codes. For more information about this see th

Re: [Development] What kind of airplane we want to build?

> AFAIK C++11/14 compilers have zero-cost exception, so, is there any > reason why not start using them in Qt 6.0 ? Any "zero cost" claim is with respect to some assumed base-point. ISTR exceptions require RTTI (run-time type info, as used by dynamic_cast<>), so I guess this "zero cost" claim tak

Re: [Development] What kind of airplane we want to build?

On January 22, 2016 09:52:31 Hausmann Simon wrote: > Hi, > > I think answering the question about the kind of airplane to build is closely > tied to another question that may be worthwhile > asking. I think it's worthwhile because I'm convinced that answers diverge > greatly depending on who

Re: [Development] What kind of airplane we want to build?

Hi, Personally I'd like to add to the nice to have list: the exceptions. Yeah, I know that there are some people that don't like them, but for me the exceptions are like the life vest under you seat, it is very good to have them, of course it's not that good to be in the situation to need them :

Re: [Development] Question about QCoreApplicationData::*_libpaths

Of course, i should add mutex to the getter and setter. 2016-01-22 13:14 GMT+03:00 Marc Mutz : > On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: > > What > > i'm missing? > > You haven't done the exercise with the int first. > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutsch

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: > What > i'm missing? You haven't done the exercise with the int first. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___

Re: [Development] Question about QCoreApplicationData::*_libpaths

But i don't have multiple writers (1 thread can change map, multiple can read) and QMap actually uses atomics (so no memory ordering problems). What i'm missing? 2016-01-22 13:00 GMT+03:00 Marc Mutz : > On Friday 22 January 2016 09:43:17 Иван Комиссаров wrote: > > Why? In case of QMap, we have no

Re: [Development] What kind of airplane we want to build?

Hi, I think answering the question about the kind of airplane to build is closely tied to another question that may be worthwhile asking. I think it's worthwhile because I'm convinced that answers diverge greatly depending on who you ask. Why are we trying to build an airplane? Or differen

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 09:43:17 Иван Комиссаров wrote: > Why? In case of QMap, we have no need to use operator= to change the map. > We simply detach and insert new data in it. > Of course, in case of multiple changes, the map can reach some "invalid > state" before changes are finished (i.e. in

Re: [Development] Question about QCoreApplicationData::*_libpaths

Why? In case of QMap, we have no need to use operator= to change the map. We simply detach and insert new data in it. Of course, in case of multiple changes, the map can reach some "invalid state" before changes are finished (i.e. in case we need transacted changes, we have to use mutex anyway). Bu

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 01:31:20 Kevin Kofler wrote: > Marc Mutz wrote: > > Ivan was talking about thread-safe classes. You need to lock a mutex to > > take the copy. > > Returning a QMap instead of a std::shared_ptr would be perfectly > thread-safe there. Wrong. -- Marc Mutz | Senior Softw

Re: [Development] Question about QCoreApplicationData::*_libpaths

On Friday 22 January 2016 01:13:06 Kevin Kofler wrote: > > I don't like QList because only experts can tell which guarantees it > > provides for any given type (can I keep references into the container > > across appends?). > > Simply assume that you can't. > [...] Judging from the comments on m