Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Friday 24. July 2015 08:43:59 Thiago Macieira wrote: > So the question is only whether we want to add the [Q_DECL_OVERRIDE] macro > now and replace with the keyword in 5.7. > > I'd say no. I already used clang-modernize in qtbase to add the macro everywhere in Qt 5.5 Even other modules have had the macro added in many places to fix warnings. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Friday 24 July 2015 20:23:45 Marc Mutz wrote: > Fair enough, but seeing all the commits flying by that add Q_D_O to "fix > warnings with clang", it's not hard to imagine that a) the problem will > solve itself by a grass roots movement and b) people will a > not-too-unrealistic future warning will complain not just about > inconsistent use, but any missing override, like the already-existing > warnings for nullptr. So if 5.6 is anything near 4.8, we'll probably add > those macros to a point release, by popular demand. I think it's worth it if there's a benefit in performance or in reduction of warnings. Doing it for the sake of doing it, not so much. -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Friday 24 July 2015 20:23:45 Marc Mutz wrote: > itself by a grass roots movement and b) people will a not-too-unrealistic s/people will// -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Friday 24 July 2015 17:43:59 Thiago Macieira wrote: > So the question is only whether we want to add the macro now and replace > with the keyword in 5.7. > > I'd say no. Fair enough, but seeing all the commits flying by that add Q_D_O to "fix warnings with clang", it's not hard to imagine that a) the problem will solve itself by a grass roots movement and b) people will a not-too-unrealistic future warning will complain not just about inconsistent use, but any missing override, like the already-existing warnings for nullptr. So if 5.6 is anything near 4.8, we'll probably add those macros to a point release, by popular demand. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Friday 24 July 2015 13:34:39 Marc Mutz wrote: > On Thursday 23 July 2015 16:29:12 Knoll Lars wrote: > > On 23/07/15 14:27, "Marc Mutz" wrote: > > >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > > >> * Q_DECL_OVERRIDE - required in new code, don't add to old code > > > > > >- Required to be used consistently within a class, because Clang warns be > > > > > > default if one function has override and another doesn't. > > > > > >- Even add to old code. The benefits outweigh the git history churn. > > > > > >Consensus? > > > > Yes, but again, I’d propose we wait until 5.6 is branched and then start > > using the keyword directly, not the macro. > > Is there any compiler we support that doesn't support it? Note: MSVC > supports it from 2005 (override; final was called 'sealed'). We don't claim to require C++11 in 5.6, so you cannot use the naked keyword, even if all of the compilers we support can understand it. It's possible someone is compiling Qt with some other compiler. So the question is only whether we want to add the macro now and replace with the keyword in 5.7. I'd say no. -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 24/07/15 13:34, "Marc Mutz" wrote: >On Thursday 23 July 2015 16:29:12 Knoll Lars wrote: >> On 23/07/15 14:27, "Marc Mutz" wrote: >> >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> >> * Q_DECL_OVERRIDE - required in new code, don't add to old code >> > >> >- Required to be used consistently within a class, because Clang warns >>be >> > >> > default if one function has override and another doesn't. >> > >> >- Even add to old code. The benefits outweigh the git history churn. >> > >> >Consensus? >> >> Yes, but again, I’d propose we wait until 5.6 is branched and then start >> using the keyword directly, not the macro. > >Is there any compiler we support that doesn't support it? Note: MSVC >supports >it from 2005 (override; final was called 'sealed'). I believe they all support it, but in 5.6, we still allow compilation in C++98 mode, so it has to be a macro there. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 23 July 2015 16:29:12 Knoll Lars wrote: > On 23/07/15 14:27, "Marc Mutz" wrote: > >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > >> * Q_DECL_OVERRIDE - required in new code, don't add to old code > > > >- Required to be used consistently within a class, because Clang warns be > > > > default if one function has override and another doesn't. > > > >- Even add to old code. The benefits outweigh the git history churn. > > > >Consensus? > > Yes, but again, I’d propose we wait until 5.6 is branched and then start > using the keyword directly, not the macro. Is there any compiler we support that doesn't support it? Note: MSVC supports it from 2005 (override; final was called 'sealed'). -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 23/07/15 19:16, "Thiago Macieira" wrote: >On Thursday 23 July 2015 19:22:46 Marc Mutz wrote: >> I believe we should strive to have the LTS release warning-free in this >> regard. It's going to be in use for a long time, and the demand for >>nullptr- >> correctness will only grow with time. > >Agreed. > >I'd say go ahead with cleaning up zero-as-null in public headers and then >add >it to headersclean. > >For 5.7, we can do s/Q_NULLPTR/nullptr/g. Ok for me as well, if someone volunteers to do the job. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 23 July 2015 19:22:46 Marc Mutz wrote: > I believe we should strive to have the LTS release warning-free in this > regard. It's going to be in use for a long time, and the demand for nullptr- > correctness will only grow with time. Agreed. I'd say go ahead with cleaning up zero-as-null in public headers and then add it to headersclean. For 5.7, we can do s/Q_NULLPTR/nullptr/g. -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 23 July 2015 15:47:10 Knoll Lars wrote: > On 23/07/15 14:23, "Marc Mutz" wrote: > >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > >> * Q_NULLPTR - strongly encouraged > > > >Ok, trying to summarize the discussion so we can move forward. > > > >There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about > >Qt > >headers not compiling with -Wzero-as-null-pointer-constant, sometimes not > >even > >when locking the Qt headers away behind an -isystem. I understood the > >discussion in this thread as follows: > > > >- ok to use Q_NULLPTR in public headers (the bug report suggests that this > > > > should actually be enforced by headersclean). > > > >- ok to use in new code or as a drive-by iff the 0 isn't immediately > >visible > > > > as a nullptr. Example: > > validator(0), // Q_NULLPTR ok here > > > > Counter-example: > > const char *msg = 0 // Q_NULLPTR not wanted here > > > >- otherwise, we don't want Q_NULLPTR. We're waiting until we can move > >directly > > > > to nullptr. In particular, we cannot use Q_NULLPTR for its potentially > > disambiguating characteristics, until we require C++11 nullptr. So code > > > >must > > > > still compile (modulo warnings) (and have the same meaning) if the > > > >Q_NULLPTR > > > > is replaced back to 0. > > > >Consensus? > > Mostly. But it looks like VS 2012 support nullptr, so I’d say we wait for > 5.6 to be branched. After that we should globally get rid of Q_NULLPTR. > i.e. Do a search and replace Q_NULLPTR -> nullptr in our code base. Then > IMO the first two rules above should be taken into use with > s/Q_NULLPTR/nullptr/. I believe we should strive to have the LTS release warning-free in this regard. It's going to be in use for a long time, and the demand for nullptr- correctness will only grow with time. Otherwise, I agree. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 2015-07-23 08:23, Marc Mutz wrote: > On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> * Q_NULLPTR - strongly encouraged > > Ok, trying to summarize the discussion so we can move forward. > > There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about Qt > headers not compiling with -Wzero-as-null-pointer-constant, sometimes not > even > when locking the Qt headers away behind an -isystem. I understood the > discussion in this thread as follows: > > - ok to use Q_NULLPTR in public headers (the bug report suggests that this > should actually be enforced by headersclean). The bug reporter would appreciate that, yes :-). Especially in macros (e.g. Q_OBJECT¹) and default parameter values. (The reporter would also appreciate https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486 getting fixed, but that doesn't seem likely to happen any time soon :-(. And no, I'm not asking Qt to fix GCC bugs; just mentioning it because it is pertinent.) (¹ Pedantic: the original report indicates that the problem in Q_OBJECT is indirect, via QT_TR_FUNCTIONS. IIRC in 4.8.x there are a lot more such issues in Q_OBJECT, most of which have been fixed by now. Also, QT_TR_FUNCTIONS may be fixed already in 5.5; I haven't checked yet.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 23/07/15 14:27, "Marc Mutz" wrote: >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> * Q_DECL_OVERRIDE - required in new code, don't add to old code > >- Required to be used consistently within a class, because Clang warns be > default if one function has override and another doesn't. >- Even add to old code. The benefits outweigh the git history churn. > >Consensus? Yes, but again, I’d propose we wait until 5.6 is branched and then start using the keyword directly, not the macro. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 23/07/15 14:27, "Marc Mutz" wrote: >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> * Q_DECL_OVERRIDE - required in new code, don't add to old code > >- Required to be used consistently within a class, because Clang warns be > default if one function has override and another doesn't. >- Even add to old code. The benefits outweigh the git history churn. > >Consensus? > >Thanks, >Marc > >-- >Marc Mutz | Senior Software Engineer >KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >Tel: +49-30-521325470 >KDAB - The Qt Experts >___ >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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 23/07/15 14:23, "Marc Mutz" wrote: >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> * Q_NULLPTR - strongly encouraged > >Ok, trying to summarize the discussion so we can move forward. > >There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about >Qt >headers not compiling with -Wzero-as-null-pointer-constant, sometimes not >even >when locking the Qt headers away behind an -isystem. I understood the >discussion in this thread as follows: > >- ok to use Q_NULLPTR in public headers (the bug report suggests that this > should actually be enforced by headersclean). >- ok to use in new code or as a drive-by iff the 0 isn't immediately >visible > as a nullptr. Example: > validator(0), // Q_NULLPTR ok here > Counter-example: > const char *msg = 0 // Q_NULLPTR not wanted here >- otherwise, we don't want Q_NULLPTR. We're waiting until we can move >directly > to nullptr. In particular, we cannot use Q_NULLPTR for its potentially > disambiguating characteristics, until we require C++11 nullptr. So code >must > still compile (modulo warnings) (and have the same meaning) if the >Q_NULLPTR > is replaced back to 0. > >Consensus? Mostly. But it looks like VS 2012 support nullptr, so I’d say we wait for 5.6 to be branched. After that we should globally get rid of Q_NULLPTR. i.e. Do a search and replace Q_NULLPTR -> nullptr in our code base. Then IMO the first two rules above should be taken into use with s/Q_NULLPTR/nullptr/. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> Non-C++11 but also useful:
>
> * Q_DECL_{PURE,CONST}_FUNCTION - encouraged
>
> A pure function is a function that will return the same value if called
> twice with the same parameters. Pure functions are allowed to read from
> pointers passed to it, including the "this" pointer. Pure functions are
> not allowed to have observable side-effects (rule of thumb: no writing to
> dereferenced pointers or to global variables).
>
> A const function is a function that is pure and does not dereference any
> pointers.
>
> Quite by definition, const and pure functions cannot return void. Any such
> calls would be discarded by the compiler.
Consensus, I think? Esp. useful for out-of-line qHash(), e.g.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > * Q_DECL_NOTHROW / Q_DECL_NOEXCEPT - strongly encouraged > > To public functions (all modules); any function in modules compiled with > exception (QtCore, QtXmlPatterns, QtConcurrent). > > You probably want Q_DECL_NOTHROW instead of Q_DECL_NOEXCEPT. > > Do not add to functions that: > * allocate memory > * call functions that may throw, especially user functions > * call POSIX cancellation points > * have narrow contracts -- that is, you could conceivably add a Q_ASSERT > on input parameters > > If the function is an inline template function and the exception depends > on the template argument, use Q_DECL_NOEXCEPT_EXPR. Consensus, I think? I'd add that having a nothrow move ctor and move assignment operator is a very important optimisation for std::vector. User-defined copy ctors and copy assignment operators, but also a user-defined dtors (even if empty) inhibit the synthesising of move special member functions by the compiler, so remove them when you can or manually add the move special member functions, preferably with Q_DECL_NOTHROW / Q_DECL_NOEXCEPT_EXPR. Example changes for both situations: https://codereview.qt-project.org/121833 https://codereview.qt-project.org/121824 Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > * Q_CONSTEXPR - use only where required > > You probably don't need this. You'll need it when accessing const data from > a Q_DECL_CONSTEXPR function. Otherwise, you won't need it. > > You could use this to create a static-initialisation-time const variable of > a non-POD type, but since our sources still compile in C++98 and we still > have a rule against non-POD statics, you should not do this. Consensus, I think? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > * Q_DECL_OVERRIDE - required in new code, don't add to old code - Required to be used consistently within a class, because Clang warns be default if one function has override and another doesn't. - Even add to old code. The benefits outweigh the git history churn. Consensus? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > * Q_DECL_EQ_DEFAULT - really discouraged > > I can't think of any case where you could use this and let the code still > compile in C++98, so don't use it > > * Q_DECL_EQ_DELETE - strongly encouraged, use with care > > Let's the compiler print an error instead of allowing a linker error for > an unresolved symbol. > > * Q_DECL_CONSTEXPR / Q_DECL_RELAXED_CONSTEXPR - strongly encouraged > > Use where it makes sense. If possible, use the C++11 restricted constexpr > as we have still too few compilers with C++14 relaxed constexpr support > (Clang 3.5, GCC 5), but feel free to use Q_DECL_RELAXED_CONSTEXPR when > there's benefit for constexprness but impossible to solve in C++11 > > * Q_DECL_FINAL - optional, use with care > > There's a small benefit in optimisation by devirtualising calls. Use it > with care. > > Use in public classes is discouraged, since people can compile with a > C++98 and derive / override what they shouldn't. All of the above is consensus, I think? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > * Q_NULLPTR - strongly encouraged Ok, trying to summarize the discussion so we can move forward. There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about Qt headers not compiling with -Wzero-as-null-pointer-constant, sometimes not even when locking the Qt headers away behind an -isystem. I understood the discussion in this thread as follows: - ok to use Q_NULLPTR in public headers (the bug report suggests that this should actually be enforced by headersclean). - ok to use in new code or as a drive-by iff the 0 isn't immediately visible as a nullptr. Example: validator(0), // Q_NULLPTR ok here Counter-example: const char *msg = 0 // Q_NULLPTR not wanted here - otherwise, we don't want Q_NULLPTR. We're waiting until we can move directly to nullptr. In particular, we cannot use Q_NULLPTR for its potentially disambiguating characteristics, until we require C++11 nullptr. So code must still compile (modulo warnings) (and have the same meaning) if the Q_NULLPTR is replaced back to 0. Consensus? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Wednesday 27 May 2015 09:46:08 Marc Mutz wrote: > On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > > Hello > > > > I think it's time to institute a policy that we should fix our sources to > > use the new C++11 keywords. I'd like to propose the following. > > Can we move all (excl. Q_NULLPTR, which is controversial) forward? Hi Marc Can you summarise the non-controversial parts of the thread? -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > Hello > > I think it's time to institute a policy that we should fix our sources to > use the new C++11 keywords. I'd like to propose the following. Can we move all (excl. Q_NULLPTR, which is controversial) forward? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
> On Feb 10, 2015, at 10:51 AM, Marc Mutz wrote: > > On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote: >>> On Feb 9, 2015, at 3:40 PM, Marc Mutz wrote: >>> >>> On Monday 09 February 2015 09:54:12 Smith Martin wrote: This is the kind of thing we should add to the documentation, but can you elaborate? I mean, illustrate the meaning of "locality of reference," "wildly mixing insertions, lookups, and removals," and "batch updates and separate them from lookups, time-wise." >>> >>> There is a book, Effective STL, and an online paper, "What every >>> programmer needs to know about memory". I don't think that it's the job >>> of the Qt docs to explain "what every programmer needs to know about >>> memory", because it is not specific to Qt. >>> >>> The Qt documentation also doesn't give many details on Unicode. It's >>> assumed that people using it know the basics. >>> >>> You will also not find in the Qt docs that signed integer overflow is >>> undefined behaviour. >>> >>> The Qt docs are not a CS text book :) >> >> That QMap is implemented based on a RB tree is mentioned in a single >> sentence in the beginning of the description of the class, which is the >> sentence that nobody ever reads (because it tends to contain useful >> information like "The QList class is a template class that provides >> lists.”). >> >> It is followed by a short (but longer) comparison between QMap and QHash, >> which in turn is linked to a relatively long section that compares the >> complexity of Qt’s different containers. So, fact is that the Qt docs *do* >> explain more than “QMap is a RB tree” (and I think that is good so). And >> since they talk a lot about algorithmic complexity, it would probably be >> useful to mention a few other things that concern performance differences >> as well. In ~5 sentences. I really can’t see how that could hurt. >> >> Actually you sounded like you’d like to educate people about this also >> “outside of CS courses” (by sending them to their manager etc), so do you >> have a different, realistic proposal? > > The topic of this thread is guidelines for Qt code, not code using Qt. Qt code is code using Qt. Qt developers are Qt users. Qt developers (read: contributors) also read Qt documentation to find out which data structures to use for solving which problem. > We > don't want to impose writing Q_DECL_CONSTEXPR everywhere possible for users > of > Qt. Likewise, if they want to use QMap, then that's fine. A profiler will > tell > them if they made a mistake that matters. > > The situation is different for Qt code: Actually not much, since there are many other libraries than Qt out there that use Qt and therefore must also “optimize for everything”. > Consider a recent example: QString::multiArg(). It used a QMap. Now it uses a > QVarLengthArray (introduced in 7b5ba56b0ab55fcaf79fbf9aad70bf767c938e15). A > very naïve benchmark (I'm allowed to say that, it was my choice). was sped up > by 30%. The naïviteé in the benchmark is that this includes repeated > allocation of a handful of QString arguments from short (C) string literals > each time through the loop, which probably dominates the result. > > We don't know what Qt is being used for, so we need to optimize everything. > One user surely will run multiArg() in a tight loop and that will dominate > his > runtime. As every C++ library that's any good, we cannot be sloppy when it > comes to efficiency. > > So, no, I don't think we should discuss everthing ever written about C++ > efficiency in the Qt docs. Nobody has claimed that we should. > But we need to point it out to each other in code > reviews and become better at not writing sloppy code. Nobody has claimed that we shouldn’t. Discussing in the documentation which classes are best used in which use cases, might reduce the need to educate people over and over again in code reviews though. And reviews could be abbreviated to “don’t use QMap in this case, read ”, instead of discussing the same thing over and over again. > IOW: We need to start thinking about our algorithms and data structures > again[1], but this time in the new world of caches and multithreading where > the only fast data structure is an array.[2] > > Thanks, > Marc > > [1] http://www.amazon.com/Algorithms-Structures-Prentice-Hall-Automatic- > Computation/dp/0130224189 > > [2] http://vimeo.com/97337258 > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-Independent Software Solutions -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 something > that wants an integer type, you'd better get a compile error, because > such a conversion is not allowed by the C++ standard. (At least > gcc-c++-4.8.3-7.fc20.x86_64 correctly rejects this.) You're right... All the compilers that support __null and that we test also support C++11 and nullptr, so we wouldn't get the __null warning converted to error, we'd get the actual nullptr error. -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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, but just saying...) >>> >>> You said auto ptr = 0 doesn't give you a pointer. By extension, I thought >>> you were saying that auto ptr = nullptr does (and it does, in a way). >> >> Right (well, a nullptr_t anyway which behaves the same as an in-place >> 'nullptr'; in particular, can be implicitly converted to a pointer, and >> *cannot* be implicitly converted to a numeric type). > > True, but that's not the point here. The only value allowed for nullptr_t is > nullptr, which is why any nullptr_t can be converted to any pointer. > > However, the point here is: > > auto ptr = nullptr; > ptr = &something; // error! > > void *ptr = nullptr; > ptr = &something; // ok True, but if you know what type you want (e.g. 'void*') you should be specifying it explicitly. I was thinking of a case where you are going to pass nullptr to something, but for some reason you want to put it in a local variable first. (Admittedly, it's a stretch.) I think we've gone just a bit off topic for something I said up front wasn't very interesting :-). > What's the type of ptr in? > auto ptr = __null; > > Hint: GCC prints this warning: > warning: converting to non-pointer type ‘long int’ from NULL [-Wconversion- > null] Huh :-). So much for hoping that __null == nullptr in C++11 mode. (I'm not going to claim to understand the intricacies of __null...) >> Right. Qt is not at a point where it can write API that relies on the >> existence of nullptr/nullptr_t. Overloading in particular is a no-go. > > It can be done, with some effort, for non-public API (that is, not ABI- > binding): > https://codereview.qt-project.org/100076 > specifically > https://codereview.qt-project.org/#/c/100076/4/src/corelib/kernel/qmetatype_p.h Well, sure; I was intentionally ignoring the case of a library work-around to provide a nullptr_t. (Pedantic: shouldn't that have a conversion operator?) >> Q_NULLPTR is still useful because *some* builds will break if you try to >> pass a Q_NULLPTR where only an integer type is accepted, but not *every* >> build will catch such errors even using Q_NULLPTR. (I think we're in >> agreement on this point?) > > 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 something that wants an integer type, you'd better get a compile error, because such a conversion is not allowed by the C++ standard. (At least gcc-c++-4.8.3-7.fc20.x86_64 correctly rejects this.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 ptr = 0 doesn't give you a pointer. By extension, I thought > > you were saying that auto ptr = nullptr does (and it does, in a way). > > Right (well, a nullptr_t anyway which behaves the same as an in-place > 'nullptr'; in particular, can be implicitly converted to a pointer, and > *cannot* be implicitly converted to a numeric type). True, but that's not the point here. The only value allowed for nullptr_t is nullptr, which is why any nullptr_t can be converted to any pointer. However, the point here is: auto ptr = nullptr; ptr = &something; // error! void *ptr = nullptr; ptr = &something; // ok > > But for Q_NULLPTR, auto ptr = Q_NULLPTR may be deduced as nullptr_t on a > > c++11 compiler, int (NULL = 0) on others, long (NULL = 0L) on yet other, > > and void* (NULL = (void*')) on the rest (yes, not all of them are valid > > in C++). > Good point. You're right that Q_NULLPTR "isn't adequate" here. (OTOH, > the range of compilers / versions that support C++11 'auto' but *not* > C++11 'nullptr' or e.g. something like __null is not so great.) What's the type of ptr in? auto ptr = __null; Hint: GCC prints this warning: warning: converting to non-pointer type ‘long int’ from NULL [-Wconversion- null] > > So I maintain that we can't rely on nullptr semantics here as long as we > > use Q_NULLPTR. Same for foo(int) vs. foo(void*). > > Right. Qt is not at a point where it can write API that relies on the > existence of nullptr/nullptr_t. Overloading in particular is a no-go. It can be done, with some effort, for non-public API (that is, not ABI- binding): https://codereview.qt-project.org/100076 specifically https://codereview.qt-project.org/#/c/100076/4/src/corelib/kernel/qmetatype_p.h > Q_NULLPTR is still useful because *some* builds will break if you try to > pass a Q_NULLPTR where only an integer type is accepted, but not *every* > build will catch such errors even using Q_NULLPTR. (I think we're in > agreement on this point?) Only if we build with -Werror -- which we do, in the compilers that support __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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 saying that auto ptr = nullptr does (and it does, in a way). Right (well, a nullptr_t anyway which behaves the same as an in-place 'nullptr'; in particular, can be implicitly converted to a pointer, and *cannot* be implicitly converted to a numeric type). > But for Q_NULLPTR, auto ptr = Q_NULLPTR may be deduced as nullptr_t on a > c++11 > compiler, int (NULL = 0) on others, long (NULL = 0L) on yet other, and void* > (NULL = (void*')) on the rest (yes, not all of them are valid in C++). Good point. You're right that Q_NULLPTR "isn't adequate" here. (OTOH, the range of compilers / versions that support C++11 'auto' but *not* C++11 'nullptr' or e.g. something like __null is not so great.) > So I maintain that we can't rely on nullptr semantics here as long as we use > Q_NULLPTR. Same for foo(int) vs. foo(void*). Right. Qt is not at a point where it can write API that relies on the existence of nullptr/nullptr_t. Overloading in particular is a no-go. Q_NULLPTR is still useful because *some* builds will break if you try to pass a Q_NULLPTR where only an integer type is accepted, but not *every* build will catch such errors even using Q_NULLPTR. (I think we're in agreement on this point?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 reading mails (threads) > > before responding :) > > Will someone please explain to me why you think I'm not? It's either that or > Is my irony detector broken? this. I was replying to André's question "can't you [..] wait until nuklptr is available?" with No. I thought that was obviously pro-Q_NULLPTR :) > >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to > >> Qt, but just saying...) > > > > > > > > While true, this is semantics that we can't rely on in Qt atm. > > (Ahem: "[this is] not relevant to Qt". Speaking of irony, I guess I'm > not the only one that can't keep the entire thread straight...) You said auto ptr = 0 doesn't give you a pointer. By extension, I thought you were saying that auto ptr = nullptr does (and it does, in a way). But for Q_NULLPTR, auto ptr = Q_NULLPTR may be deduced as nullptr_t on a c++11 compiler, int (NULL = 0) on others, long (NULL = 0L) on yet other, and void* (NULL = (void*')) on the rest (yes, not all of them are valid in C++). So I maintain that we can't rely on nullptr semantics here as long as we use Q_NULLPTR. Same for foo(int) vs. foo(void*). foo(Q_NULLPTR) may be ambiguous, call the int overload or the void* overload. Again, we can't rely on nullptr semantics when using Q_NULLPTR. We can only hope to catch some bugs and otherwise improve readability by using it (but the later, as we've seen is controversial). > > nor can it be relied on that Q_NULLPTR doesn't convert to an > > integral type. > > True for a given build. However, there is a fair chance that some other > (C++11) build will break in case of such code, increasing the chances > that someone will notice any issues of this nature. > > > The latter is esp. interesting, as I believe some compilers > > implement NULL to be nullptr-like even in C++98 (and Q_NULLPTR is NULL if > > it's not nullptr), so you may benefit even in C++98 by using Q_NULLPTR > > instead of 0. But you can't rely on that. > > This too :-). -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 to me why you think I'm not? Marc: what made me scratch my head was your comments regarding 'emit'. In general, you appear to be arguing for nullptr, but then you say you don't like 'emit' while indicating that the arguments in favor of 'emit' are similar to the arguments in favor of nullptr. Am I missing why this isn't a contradiction? Is my irony detector broken? >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to >> Qt, but just saying...) > > While true, this is semantics that we can't rely on in Qt atm. (Ahem: "[this is] not relevant to Qt". Speaking of irony, I guess I'm not the only one that can't keep the entire thread straight...) > nor can it be relied on that Q_NULLPTR doesn't convert to an > integral type. True for a given build. However, there is a fair chance that some other (C++11) build will break in case of such code, increasing the chances that someone will notice any issues of this nature. > The latter is esp. interesting, as I believe some compilers > implement NULL to be nullptr-like even in C++98 (and Q_NULLPTR is NULL if > it's > not nullptr), so you *may* benefit even in C++98 by using Q_NULLPTR instead > of > 0. But you can't _rely_ on that. This too :-). -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 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 aesthetics and I suppose there > > > is little that will change that. > > > > > > As approver I will approve code that uses Q_NULLPTR but I expect others > > > reviewing my code to respect my preference to use 0 until we can use > > > nullptr. > > > > Apart from the claim that there is nothing technical in this discussion, > > I agree with the above. Respect the preference of the guy who codes. I > > like simple rules. This is one. > > I prefer using curly braces for if even if there is only one line. > This is what the KDE coding style mandate, it makes diff smaller when you > add or remove lines, and it helps preventing mistakes likes the "goto > fail; goto fail;" one. > Am i going to be allowed to use curly braces? I, for one, won't stop you. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 function call but a signal emission. Having said that I don’t think we have a strong requirement to use it. > >> let’s not go and replace 0 with the macro in places where >> things are unambiguous. > >For old code, by definition, 0 as currently used cannot be ambiguous >(since it >compiled before). > >Ergo, you're banning replacing any 0 with nullptr in existing code, in >passing >or else (except where it causes a warning), even though a few lines up >you >seem to allow replacing it "where it makes things clearer" (whatever that >means). Unambiguous to somebody reading the code, not the compiler. There is a difference between them. >For new code, we're not replacing a 0. > >To me that reads that it's fine to use Q_NULLPTR in new code, even though >a few >lines up you say that you dislike macros. > >Can you leave less wiggle room, please? :) Well, I think Thiago already summed it up nicely: >Two examples: >a) void *ptr = 0; >b) str.toInt(0, 0); > >In (a), use of Q_NULLPTR would make the code noisier, so don't use it. In >(b), >the first 0 could be replaced with Q_NULLPTR to indicate that yes we know >it's >a pointer, as opposed to an integer. Readability and making sure a human can parse the written code quickly is important to me. And less macros usually do make the code more readable. But where things are ambiguous to a human reading the code (again, that’s different from a compiler), I’m fine with using Q_NULLPTR to clarify. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 like UPPERCASE macros in my > > face unless I can avoid them. It's aesthetics and I suppose there is > > little that will change that. > > > > As approver I will approve code that uses Q_NULLPTR but I expect others > > reviewing my code to respect my preference to use 0 until we can use > > nullptr. > > Apart from the claim that there is nothing technical in this discussion, I > agree with the above. Respect the preference of the guy who codes. I like > simple rules. This is one. I prefer using curly braces for if even if there is only one line. This is what the KDE coding style mandate, it makes diff smaller when you add or remove lines, and it helps preventing mistakes likes the "goto fail; goto fail;" one. Am i going to be allowed to use curly braces? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 aesthetics and I suppose there is > little that will change that. > > As approver I will approve code that uses Q_NULLPTR but I expect others > reviewing my code to respect my preference to use 0 until we can use > nullptr. Apart from the claim that there is nothing technical in this discussion, I agree with the above. Respect the preference of the guy who codes. I like simple rules. This is one. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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, 0 as currently used cannot be ambiguous (since it compiled before). Ergo, you're banning replacing any 0 with nullptr in existing code, in passing or else (except where it causes a warning), even though a few lines up you seem to allow replacing it "where it makes things clearer" (whatever that means). For new code, we're not replacing a 0. To me that reads that it's fine to use Q_NULLPTR in new code, even though a few lines up you say that you dislike macros. Can you leave less wiggle room, please? :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 examples: > a)void *ptr = 0; > b)str.toInt(0, 0); > > In (a), use of Q_NULLPTR would make the code noisier, so don't use it. In (b), > the first 0 could be replaced with Q_NULLPTR to indicate that yes we know it's > a pointer, as opposed to an integer. I think this is a perfect set of rules and sums up most of the discussion nicely. +1. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 wrote: >>> On Tuesday 10 February 2015 20:13:12 André Pönitz wrote: Can't you simply wait until 'nullptr' is available? >>> No. >>> >>> For a simple reason: using nullptr (Q_ or not) is more expressive than 0. >>> And why would i want to throw away information I already have? >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to >> Qt, but just saying...) > > While true, this is semantics that we can't rely on in Qt atm. Neither can > auto be used, nor can it be relied on that Q_NULLPTR doesn't convert to an > integral type. The latter is esp. interesting, as I believe some compilers > implement NULL to be nullptr-like even in C++98 (and Q_NULLPTR is NULL if it's > not nullptr), so you *may* benefit even in C++98 by using Q_NULLPTR instead of > 0. But you can't _rely_ on that. One can just use NULL and get the best of both worlds - C++98 compatibility and warnings about type conversions. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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:12 André Pönitz wrote: > >> Can't you simply wait until 'nullptr' is available? > > > > No. > > > > For a simple reason: using nullptr (Q_ or not) is more expressive than 0. > > And why would i want to throw away information I already have? > > (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to > Qt, but just saying...) While true, this is semantics that we can't rely on in Qt atm. Neither can auto be used, nor can it be relied on that Q_NULLPTR doesn't convert to an integral type. The latter is esp. interesting, as I believe some compilers implement NULL to be nullptr-like even in C++98 (and Q_NULLPTR is NULL if it's not nullptr), so you *may* benefit even in C++98 by using Q_NULLPTR instead of 0. But you can't _rely_ on that. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
To settle this, I am also with Andre and Simon. I’m fine with keeping our headers warning free, so go ahead and use Q_NULLPTR there (until we at some point can require c++11 and can replace it with nullptr). But I don’t like littering our code with macros. Where it’s use makes things clearer as in the example Thiago mentioned, I’m ok to use it, but let’s not go and replace 0 with the macro in places where things are unambiguous. Once we can use C++11 unconditionally (and thus don’t have to use macros), I’m happy to re-open the discussion about the .cpp files. Cheers, Lars On 11/02/15 07:54, "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 aesthetics and I suppose there is >little that will change that. > >As approver I will approve code that uses Q_NULLPTR but I expect others >reviewing my code to respect my preference to use 0 until we can use >nullptr. > > >Simon > > > Original Message >From: Marc Mutz >Sent: Wednesday, February 11, 2015 00:19 >To: André Pönitz >Cc: development@qt-project.org >Subject: Re: [Development] Upgrading the sources to C++11 keywords >(Q_NULLPTR, etc.) > > >On Tuesday 10 February 2015 20:13:12 André Pönitz wrote: >> On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote: >> > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote: >> > > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote: >> > > > +1. I’m ok with us making sure our headers are clean against >>warnings >> > > > (if possible), but I don’t see a real need to enforce it’s usage >>in >> > > > implementations. >> > > >> > > Fair enough. But how about allowing people to change zeroes to >> > > Q_NULLPTR? >> > >> > Even more importantly: what about new code? >> >> Can't you simply wait until 'nullptr' is available? > >No. > >For a simple reason: using nullptr (Q_ or not) is more expressive than 0. >And >why would i want to throw away information I already have? > >> Do you really *need* >> to use macros instead of the core language? > >Do you use 'emit' when you emit signals? Lemme tell you: It's a pesky >macro >and it just adds line noise. > >So tell me.. where's the difference? > >Thanks, >Marc > >-- >Marc Mutz | Senior Software Engineer >KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 >KDAB - Qt Experts - Platform-Independent Software Solutions >___ >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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
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 aesthetics and I suppose there is little that will change that. As approver I will approve code that uses Q_NULLPTR but I expect others reviewing my code to respect my preference to use 0 until we can use nullptr. Simon Original Message From: Marc Mutz Sent: Wednesday, February 11, 2015 00:19 To: André Pönitz Cc: development@qt-project.org Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.) On Tuesday 10 February 2015 20:13:12 André Pönitz wrote: > On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote: > > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote: > > > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote: > > > > +1. I’m ok with us making sure our headers are clean against warnings > > > > (if possible), but I don’t see a real need to enforce it’s usage in > > > > implementations. > > > > > > Fair enough. But how about allowing people to change zeroes to > > > Q_NULLPTR? > > > > Even more importantly: what about new code? > > Can't you simply wait until 'nullptr' is available? No. For a simple reason: using nullptr (Q_ or not) is more expressive than 0. And why would i want to throw away information I already have? > Do you really *need* > to use macros instead of the core language? Do you use 'emit' when you emit signals? Lemme tell you: It's a pesky macro and it just adds line noise. So tell me.. where's the difference? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
Marc, I'm not sure if you're arguing for or against nullptr :-)... On 2015-02-10 18:23, Marc Mutz wrote: > On Tuesday 10 February 2015 20:13:12 André Pönitz wrote: >> Can't you simply wait until 'nullptr' is available? > > No. > > For a simple reason: using nullptr (Q_ or not) is more expressive than 0. And > why would i want to throw away information I already have? (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to Qt, but just saying...) >> Do you really *need* to use macros instead of the core language? > > Do you use 'emit' when you emit signals? Lemme tell you: It's a pesky macro > and it just adds line noise. I do use 'emit'. It adds information, not noise. When I see 'emit', I know that I am emitting a signal and not just calling some method. I can also search my code for 'emit'. (Searching for signal emissions is very hard if I am not using 'emit'.) Similarly, if for some reason I need to know where a null pointer occurs, I can at least search for 'nullptr' and know I will not get false positives. Try that with '0' and you will get *LOTS* of false positives. (I may not find all of them, but the ones I'd miss, I'd miss regardless of using '0' or 'nullptr'.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 20:13:12 André Pönitz wrote: > On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote: > > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote: > > > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote: > > > > +1. I’m ok with us making sure our headers are clean against warnings > > > > (if possible), but I don’t see a real need to enforce it’s usage in > > > > implementations. > > > > > > Fair enough. But how about allowing people to change zeroes to > > > Q_NULLPTR? > > > > Even more importantly: what about new code? > > Can't you simply wait until 'nullptr' is available? No. For a simple reason: using nullptr (Q_ or not) is more expressive than 0. And why would i want to throw away information I already have? > Do you really *need* > to use macros instead of the core language? Do you use 'emit' when you emit signals? Lemme tell you: It's a pesky macro and it just adds line noise. So tell me.. where's the difference? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 2015-02-10 17:44, André Pönitz wrote:
> On Tue, Feb 10, 2015 at 05:15:03PM -0500, Matthew Woehlke wrote:
>> On 2015-02-08 16:42, André Pönitz wrote:
>>> I.e. in case of a simple pointer initialization, why should one *ever*
>>> prefer
>>>
>>> void something()
>>> {
>>> Foo *f = Q_NULLPTR;
>>> ...
>>> }
>>>
>>> over
>>>
>>> void something()
>>> {
>>> Foo *f = 0;
>>> ...
>>> }
>>>
>>> ?
>>
>> For the same reason that *any* style rule exists: to encourage standard
>> practices that make it easier to use compiler tools to find bugs.
>>
>> If I religiously use Q_NULLPTR, than I can also turn on the warning that
>> tells me when I use '0' as a null pointer constant. Which in turn can
>> help catch places where I really meant '0' and *not* a null pointer but
>> an unintended conversion is occurring. Conversely, because 'nullptr' is
>> not an integer, you can't accidentally call something that takes an
>> integer when you really meant a pointer (doesn't apply so much to your
>> specific example, but is a reason to use it in general).
>>
>> If '0' is permitted in some contexts, then it is hard to use the
>> warning, and therefore hard to catch bugs. (And, as mentioned, not using
>> it *in headers* can be particularly annoying to someone who wants to
>> employ such a policy downstream, and can't because Qt produces huge
>> amounts of warning spam. Granted, "in headers" should perhaps read "in
>> public macros", but still...)
>>
>> As Bo noted, it's your own problem whether or not to use it in Qt's own
>> .cpp files. Please consider your users when deciding whether or not to
>> use it in headers, however.
>
> Are you reading the mails you are responding to?
...yes?
You asked why nullptr/Q_NULLPTR should be used in contexts where the
benefit is less obvious. I gave several reasons (here and also in a
different reply) why I think it should be - and indeed, why, when
possible, I personally *do* - use it everywhere, including places such
as the above example. I also noted that some of these reasons may or may
not be important to Qt.
(Admittedly some comments may be directed more to the direction of the
discussion in general than particular points of a specific mail. I image
most people prefer fewer mails :-).)
In what way do you feel that is off topic?
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 2015-02-09 15:05, Marc Mutz wrote: > On Monday 09 February 2015 20:10:44 André Pönitz wrote: >> On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote: >>> I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I >>> know at some point we will be able to just s/Q_NULLPTR/nullptr/. That's >>> not possible with 0 (not even with NULL (could be C code)), so I don't >>> see the point in continuing to use 0. >> >> At some time you will be able to ran clang-modernize with the >> Use-Nullptr transformation or something similar. >> >> [...] >> Diversity is good in biology. Less so in code. > > By the same token, we should stop fixing code formatting "mistakes" in > passing, > since we could just run clang-format. As a related anecdote, I actually have code bases (okay, personal code bases, but still) that run format checking *as a pre-commit hook*. It's quite nice to have a code base that is completely style-consistent (as much so anyway as tools can validate) :-). (I suspect there are Python code bases for which this is also true.) I've also worked on non-private code bases that have been occasionally audited with code formatting tools. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tue, Feb 10, 2015 at 05:15:03PM -0500, Matthew Woehlke wrote:
> On 2015-02-08 16:42, André Pönitz wrote:
> > I.e. in case of a simple pointer initialization, why should one *ever*
> > prefer
> >
> > void something()
> > {
> > Foo *f = Q_NULLPTR;
> > ...
> > }
> >
> > over
> >
> > void something()
> > {
> > Foo *f = 0;
> > ...
> > }
> >
> > ?
>
> For the same reason that *any* style rule exists: to encourage standard
> practices that make it easier to use compiler tools to find bugs.
>
> If I religiously use Q_NULLPTR, than I can also turn on the warning that
> tells me when I use '0' as a null pointer constant. Which in turn can
> help catch places where I really meant '0' and *not* a null pointer but
> an unintended conversion is occurring. Conversely, because 'nullptr' is
> not an integer, you can't accidentally call something that takes an
> integer when you really meant a pointer (doesn't apply so much to your
> specific example, but is a reason to use it in general).
>
> If '0' is permitted in some contexts, then it is hard to use the
> warning, and therefore hard to catch bugs. (And, as mentioned, not using
> it *in headers* can be particularly annoying to someone who wants to
> employ such a policy downstream, and can't because Qt produces huge
> amounts of warning spam. Granted, "in headers" should perhaps read "in
> public macros", but still...)
>
> As Bo noted, it's your own problem whether or not to use it in Qt's own
> .cpp files. Please consider your users when deciding whether or not to
> use it in headers, however.
Are you reading the mails you are responding to?
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tue, Feb 10, 2015 at 11:25:52PM +0100, Mathias Hasselmann wrote: > > > Am 10.02.2015 um 20:13 schrieb André Pönitz: > >On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote: > >>On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote: > >>>On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote: > +1. I’m ok with us making sure our headers are clean against warnings (if > possible), but I don’t see a real need to enforce it’s usage in > implementations. > >>> > >>>Fair enough. But how about allowing people to change zeroes to Q_NULLPTR? > >> > >>Even more importantly: what about new code? > > > >Can't you simply wait until 'nullptr' is available? Do you really *need* > >to use macros instead of the core language? > > Do you want me to count your uses of the foreach macro in Qt Creator? ;-) Which one-char C++ core alternative to 'foreach' do you have in mind? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 2015-02-09 15:30, André Pönitz wrote: > Will you propose to use 'auto' instead of 'int' whenever it compiles? > Just because 'auto' *sometimes* makes sense? Personally, I'm a fan of AAA :-). However that's not an option for Qt because there is no reasonable way to use it while still supporting C++98. Ergo, comparing 'auto' to Q_NULLPTR is apples and oranges. That said, I'm also a fan of using nullptr everywhere... and Q_NULLPTR *does* allow using it when possible while still being C++98 compatible. (Yes, *everywhere*. IMHO, '0' as a null pointer constant is an anachronism that can and should be avoided in modern code. I would happily enforce a rule to that effect.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
Am 10.02.2015 um 20:13 schrieb André Pönitz: > On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote: >> On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote: >>> On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote: +1. I’m ok with us making sure our headers are clean against warnings (if possible), but I don’t see a real need to enforce it’s usage in implementations. >>> >>> Fair enough. But how about allowing people to change zeroes to Q_NULLPTR? >> >> Even more importantly: what about new code? > > Can't you simply wait until 'nullptr' is available? Do you really *need* > to use macros instead of the core language? Do you want me to count your uses of the foreach macro in Qt Creator? ;-) Ciao, Mathias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 23:10:01 André Pönitz wrote: > > > Can't you simply wait until 'nullptr' is available? Do you really *need* > > > to use macros instead of the core language? > > > > We go back to the discussion of VS2008. That's the only major compiler we > > still care about that doesn't support it. > > You are inventing a problem that does not exist. > > '0' has served well enough as a null pointer constant in the past. There is > no doubt it will do so for a few more years. VS2008 will be not an issue > then. > > Getting the headers "clean" for the folks that "need" to turn on each and > every possible compiler warning (and then can't stand the heat...) is one > thing. Fine. Let them have Q_NULLPTR in the headers. > > But littering the implementation with it and keeping up the claim that > replacing a core C++ idiom by *A MACRO* would be a step to _modernize_ is > completely inapprehensible. I understand that. I was not advocating in favour of using Q_NULLPTR or in favour of preventing its use. I merely reacted to your suggestion that we wait for the ability to use nullptr itself. We can do that as soon as VS2008 is no longer a concern. Until then, we can't discuss this. 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 examples: a) void *ptr = 0; b) str.toInt(0, 0); In (a), use of Q_NULLPTR would make the code noisier, so don't use it. In (b), the first 0 could be replaced with Q_NULLPTR to indicate that yes we know it's a pointer, as opposed to an integer. -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 2015-02-08 16:42, André Pönitz wrote:
> I.e. in case of a simple pointer initialization, why should one *ever* prefer
>
> void something()
> {
> Foo *f = Q_NULLPTR;
> ...
> }
>
> over
>
> void something()
> {
> Foo *f = 0;
> ...
> }
>
> ?
For the same reason that *any* style rule exists: to encourage standard
practices that make it easier to use compiler tools to find bugs.
If I religiously use Q_NULLPTR, than I can also turn on the warning that
tells me when I use '0' as a null pointer constant. Which in turn can
help catch places where I really meant '0' and *not* a null pointer but
an unintended conversion is occurring. Conversely, because 'nullptr' is
not an integer, you can't accidentally call something that takes an
integer when you really meant a pointer (doesn't apply so much to your
specific example, but is a reason to use it in general).
If '0' is permitted in some contexts, then it is hard to use the
warning, and therefore hard to catch bugs. (And, as mentioned, not using
it *in headers* can be particularly annoying to someone who wants to
employ such a policy downstream, and can't because Qt produces huge
amounts of warning spam. Granted, "in headers" should perhaps read "in
public macros", but still...)
As Bo noted, it's your own problem whether or not to use it in Qt's own
.cpp files. Please consider your users when deciding whether or not to
use it in headers, however.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tue, Feb 10, 2015 at 01:17:25PM -0800, Thiago Macieira wrote: > On Tuesday 10 February 2015 20:13:12 André Pönitz wrote: > > On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote: > > > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote: > > > > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote: > > > > > +1. I’m ok with us making sure our headers are clean against warnings > > > > > (if > > > > > possible), but I don’t see a real need to enforce it’s usage in > > > > > implementations. > > > > > > > > Fair enough. But how about allowing people to change zeroes to > > > > Q_NULLPTR? > > > > > > Even more importantly: what about new code? > > > > Can't you simply wait until 'nullptr' is available? Do you really *need* > > to use macros instead of the core language? > > We go back to the discussion of VS2008. That's the only major compiler we > still care about that doesn't support it. You are inventing a problem that does not exist. '0' has served well enough as a null pointer constant in the past. There is no doubt it will do so for a few more years. VS2008 will be not an issue then. Getting the headers "clean" for the folks that "need" to turn on each and every possible compiler warning (and then can't stand the heat...) is one thing. Fine. Let them have Q_NULLPTR in the headers. But littering the implementation with it and keeping up the claim that replacing a core C++ idiom by *A MACRO* would be a step to _modernize_ is completely inapprehensible. Anyway. I think I should give up here. Long live the Q_PREPROCESSOR! Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 20:13:12 André Pönitz wrote: > On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote: > > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote: > > > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote: > > > > +1. I’m ok with us making sure our headers are clean against warnings > > > > (if > > > > possible), but I don’t see a real need to enforce it’s usage in > > > > implementations. > > > > > > Fair enough. But how about allowing people to change zeroes to > > > Q_NULLPTR? > > > > Even more importantly: what about new code? > > Can't you simply wait until 'nullptr' is available? Do you really *need* > to use macros instead of the core language? We go back to the discussion of VS2008. That's the only major compiler we still care about that doesn't support it. But if we decide to use the actual keyword, then we *irrevocably* remove support for GCC older than 4.6 and I know there's a lot of people trying to use older versions. If we're going that way, we should remove the -c++11 option from configure and simply force it on, for Qt 5.5. -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote: > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote: > > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote: > > > +1. I’m ok with us making sure our headers are clean against warnings (if > > > possible), but I don’t see a real need to enforce it’s usage in > > > implementations. > > > > Fair enough. But how about allowing people to change zeroes to Q_NULLPTR? > > Even more importantly: what about new code? Can't you simply wait until 'nullptr' is available? Do you really *need* to use macros instead of the core language? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 16:33:23 Knoll Lars wrote: > Not a whole lot? That Atomic COW is around 10% slower than a Plain string > (does Atomic COW use a fast allocator?) in the use case where you copy > strings once and modify them in 2/3 of the cases ;-) I guess the slowdown from -fexceptions is less than 10% and that still sufficed to -fno-exceptions most modules. So 10% slowdown is really, really, bad. And in Qt, we're cheating. We're not marking strings unsharable when we hand out references to characters, as we must, to be *implicitly* shared. We're only doing "semi-implicit-sharedness", because, let's face it, if we did real- implicit, we'd be detaching all the time. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote: > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote: > > +1. I’m ok with us making sure our headers are clean against warnings (if > > possible), but I don’t see a real need to enforce it’s usage in > > implementations. > > Fair enough. But how about allowing people to change zeroes to Q_NULLPTR? Even more importantly: what about new code? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 18:01:09 Christian Kandeler wrote: > On 02/10/2015 05:33 PM, Olivier Goffart wrote: > > Note that some STL implementation (most notably the GNU one) use implicit > > sharing for std::string > > I thought that was prohibited in C++11? It is. But the C++98 mode std::string is implicitly-shared. That means you cannot share a std::string created from C++98 code with a C++11 code without recompilation. -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 18:01:09 Christian Kandeler wrote: > On 02/10/2015 05:33 PM, Olivier Goffart wrote: > > Note that some STL implementation (most notably the GNU one) use implicit > > sharing for std::string > > I thought that was prohibited in C++11? That's right, but GCC did not want to break their ABI. (Actually, I've heard they are going to introduce a new ABI with GCC 5.0 http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ ) -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 10/02/2015 17:33, Olivier Goffart wrote: > On Tuesday 10 February 2015 17:08:55 Julien Blanc wrote: >> On 10/02/2015 16:33, Knoll Lars wrote: >>> IMO there’s simply too many questions that this one example doesn’t answer >>> to conclude that what we are doing is bad. >> Two arguments : >> - implicit sharing is convenient, and really developer friendly. It is >> probably a good idea since strings are really present a lot in signals >> and slots (and afaik, passed by value in these context) >> - implicit sharing is implicit, you don’t have the choice not to pay for >> it, which is a bad thing. >> >> From my experience, QStrings are slow. About two times slower than >> using plain std::string in our use cases, but the culprit for this >> slowness is, as far as we know, the internal 16 bits encoding, whereas >> our data sources are all using utf-8. We have no evidence that the >> implicit sharing cost is significant or not. > std::string is NOT an equivalent of QString No, they’re not equivalent. I was not saying that QString is poorly optimized or so. I was saying that QString is about twice slower than std::string in our use case, which starts to make us think seriously to get completely rid of it in some parts of our code (the non gui parts). > The equivalent of QString would be std::wstring or std::u16string. > The equivalent of std::string would be QByteArray. The bad thing being that you can’t seriously replace QString with QByteArray, in, nearly everywhere. QtSql uses QString, QtXml uses QString, and nearly anything that works with strings in Qt uses QString, because that is the default string class. Which means getting rid of QString is also getting rid of these components, which starts to be a big deal. > Note that some STL implementation (most notably the GNU one) use implicit > sharing for std::string That may have been true in the past, but i’m pretty sure this is no longer the case now. The main problem with COW for std::string is that operator[] non-const may invalidate iterators, which is really something you don’t expect (i can’t find evidence that the standard forbids it though i’ve read it somewhere). > Also, we don't share data structures among threads so much in a > typical application. So the arguments given against implicit sharing > are not really valid. In fact that makes them worse. It means you pay for something you don’t use. The question being « is it worth the cost » is probably yes if you consider it permits lazy developers to not crash their application because QString is thread safe. Problem comes when you know what you’re doing and don’t want to pay for features you don’t use. Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 02/10/2015 05:33 PM, Olivier Goffart wrote: > Note that some STL implementation (most notably the GNU one) use implicit > sharing for std::string I thought that was prohibited in C++11? Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 17:08:55 Julien Blanc wrote: > On 10/02/2015 16:33, Knoll Lars wrote: > > IMO there’s simply too many questions that this one example doesn’t answer > > to conclude that what we are doing is bad. > > Two arguments : > - implicit sharing is convenient, and really developer friendly. It is > probably a good idea since strings are really present a lot in signals > and slots (and afaik, passed by value in these context) > - implicit sharing is implicit, you don’t have the choice not to pay for > it, which is a bad thing. > > From my experience, QStrings are slow. About two times slower than > using plain std::string in our use cases, but the culprit for this > slowness is, as far as we know, the internal 16 bits encoding, whereas > our data sources are all using utf-8. We have no evidence that the > implicit sharing cost is significant or not. std::string is NOT an equivalent of QString The equivalent of QString would be std::wstring or std::u16string. The equivalent of std::string would be QByteArray. Note that some STL implementation (most notably the GNU one) use implicit sharing for std::string > Now the question is, is there some simple way to disable QString (and > eventually other data structures) implicit sharing to make some real > world benchmarks ? There is no easy way. My guess is that if you were to disable implicit sharing, the impact would be negative in almost all applications since they would suddenly do many more allocation. (they were developed with implicit sharing in mind) Also, we don't share data structures among threads so much in a typical application. So the arguments given against implicit sharing are not really valid. -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote: > +1. I’m ok with us making sure our headers are clean against warnings (if > possible), but I don’t see a real need to enforce it’s usage in > implementations. Fair enough. But how about allowing people to change zeroes to Q_NULLPTR? -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 10/02/2015 16:33, Knoll Lars wrote: > IMO there’s simply too many questions that this one example doesn’t answer > to conclude that what we are doing is bad. Two arguments : - implicit sharing is convenient, and really developer friendly. It is probably a good idea since strings are really present a lot in signals and slots (and afaik, passed by value in these context) - implicit sharing is implicit, you don’t have the choice not to pay for it, which is a bad thing. From my experience, QStrings are slow. About two times slower than using plain std::string in our use cases, but the culprit for this slowness is, as far as we know, the internal 16 bits encoding, whereas our data sources are all using utf-8. We have no evidence that the implicit sharing cost is significant or not. Now the question is, is there some simple way to disable QString (and eventually other data structures) implicit sharing to make some real world benchmarks ? Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 09/02/15 22:50, "André Pönitz" wrote: >On Mon, Feb 09, 2015 at 01:28:18PM -0800, Thiago Macieira wrote: >> On Monday 09 February 2015 22:10:09 André Pönitz wrote: >> > On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote: >> > > On Monday 09 February 2015 21:21:12 André Pönitz wrote: >> > > > I don't think the argument of whitespace changes making the >>history >> > > > hard to read carries a lot of weight in a git world. >> > > >> > > Whitespaces can be ignored in git diff and git blame. >> > >> > This sounds a bit like 'whitespace changes in passing are Mostly >> > Harmless'. Which I happen to be fine with. >> > >> > > You can't do that with C++ keywords. >> > >> > Would that be an argument against replacing '= 0' by '= Q_NULLPTR' >> > under the 'fix whitespace in passing' rule? >> >> That was the original proposal I sent. But some people objected to it. >> >> I think we need to at the very least modernise our headers, since some >> users may compile we strict warning options. > >I think there is room for a not too contended resolution along the lines >of >"do whatever you think that's needed in the headers as long as there won't >be a Q_NULLPTR replacing a valid '0' in a .cpp file." +1. I’m ok with us making sure our headers are clean against warnings (if possible), but I don’t see a real need to enforce it’s usage in implementations. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 09/02/15 15:56, "Oswald Buddenhagen" wrote: >On Mon, Feb 09, 2015 at 03:30:06PM +0100, Marc Mutz wrote: >> On Monday 09 February 2015 14:21:44 Rutledge Shawn wrote: >> > But the advantage of Qt data structures is the implicit sharing. >> >> Cough, cough. >> >> http://www.gotw.ca/publications/optimizations.htm (watch the >>publication date) >> >and what exactly is this supposed to tell us? Not a whole lot? That Atomic COW is around 10% slower than a Plain string (does Atomic COW use a fast allocator?) in the use case where you copy strings once and modify them in 2/3 of the cases ;-) Now the questions come: How does this corresponds to real world use cases? How often on average do you modify a copied string? How often are our users taking a copy of a string unintentionally (because they e.g. pass it by value)? How does this overhead translate to more complex data structures than a string? What’s the memory savings we get from using implicit sharing and how does this help performance of the system as a whole? IMO there’s simply too many questions that this one example doesn’t answer to conclude that what we are doing is bad. Anyway, it’s mainly academic for now as we couldn’t change this before Qt 6. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
Marc Mutz schreef op 10-2-2015 om 14:19: > On Tuesday 10 February 2015 13:05:32 Olivier Goffart wrote: >> I think using a QMap is fine in most case. > Sorry, no. > > I know you don't believe me. Maybe you believe your own eyes: > > https://www.youtube.com/watch?v=ApLLVY6MZaI&list=PLHxtyCq_WDLXFAEA- > lYoRNQIezL_vaSX-&index=7 start at 30:00 > > for the result (it's a lengthy process, and the comparision has flaws): > https://www.youtube.com/watch?v=Bcu9ymklfM8&index=8&list=PLHxtyCq_WDLXFAEA- > lYoRNQIezL_vaSX- > > Start at 42:00. DO watch until the end of that lecture (less than 10min). > Mark, thank you for giving these (and the other earlier) links to some (at least to me) very instructional materials. Note to self: spend more time reading pieces like the "What every programmer should know about memory" and watching lectures like the ones you shared. It does make me think that I have probably made some quite bad mistakes in code that I wrote in the past that could have been a whole lot faster... Again, thank you. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 13:05:32 Olivier Goffart wrote: > I think using a QMap is fine in most case. Sorry, no. I know you don't believe me. Maybe you believe your own eyes: https://www.youtube.com/watch?v=ApLLVY6MZaI&list=PLHxtyCq_WDLXFAEA- lYoRNQIezL_vaSX-&index=7 start at 30:00 for the result (it's a lengthy process, and the comparision has flaws): https://www.youtube.com/watch?v=Bcu9ymklfM8&index=8&list=PLHxtyCq_WDLXFAEA- lYoRNQIezL_vaSX- Start at 42:00. DO watch until the end of that lecture (less than 10min). -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 12:37:28 Smith Martin wrote: > >For those guys, no amount of documentation will save them from writing > >bad code, so I don't think we should concern ourselves much with this > >case. > > > >I'm happy with the documentation if an educated developer reads it, and > >is able to make the correct decision on which container class to use. Just a disclaimer: Martin omitted the attribution of the lines he quotes here. They are _not mine_. > You're sort of nullifying the concept of recommending best practices at > all. > > We won't be asking the developers to include basic CS concepts when > documenting a new class, if that's a worry. In this case, I asked for > clarification of some points, so I could add a recommendation to QMap > myself. > > I use QMap all the time, and almost certainly in situations where a vector > would be better. Why? Because it's dead simple and I need to get it > running now. I suppose we get used to doing the same thing the same way > and don't always pay attention to these details when a deadline is fast > approaching. It helps to be reminded of best practice tips from time to > time when checking a class I use out of habit. > > martin -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 11:37:28 Smith Martin wrote: > >For those guys, no amount of documentation will save them from writing > >bad code, so I don't think we should concern ourselves much with this case. > > > >I'm happy with the documentation if an educated developer reads it, and > >is able to make the correct decision on which container class to use. > > You're sort of nullifying the concept of recommending best practices at all. > > We won't be asking the developers to include basic CS concepts when > documenting a new class, if that's a worry. In this case, I asked for > clarification of some points, so I could add a recommendation to QMap > myself. > > I use QMap all the time, and almost certainly in situations where a vector > would be better. Why? Because it's dead simple and I need to get it running > now. I suppose we get used to doing the same thing the same way and don't > always pay attention to these details when a deadline is fast approaching. > It helps to be reminded of best practice tips from time to time when > checking a class I use out of habit. I think using a QMap is fine in most case. You can sometimes get better performances with a QVector or QHash in some cases. However, using QVector in place of a QMap tends to lead to code that might be more complicated to write and understand. Also using a QVector when QMap would have been better might lead to O(n^2) complexity which is even worse. So I'd be careful recommending to use QVector over QMap. Regarding the documentation: The complexity of QList, QVector, QMap and QHash is already explain in the documentation. http://doc.qt.io/qt-5/containers.html . There are implementation details about QList which are not documented but probably should because they make the difference. About the best practice, there could perhaps be a wiki page with them. Just like the Qt coding style do not belong in the documentation. -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
10.02.2015, 14:37, "Smith Martin" : >> For those guys, no amount of documentation will save them from writing >> bad code, so I don't think we should concern ourselves much with this case. >> I'm happy with the documentation if an educated developer reads it, and >> is able to make the correct decision on which container class to use. > You're sort of nullifying the concept of recommending best practices at all. > > We won't be asking the developers to include basic CS concepts when > documenting a new class, if that's a worry. In this case, I asked for > clarification of some points, so I could add a recommendation to QMap myself. > > I use QMap all the time, and almost certainly in situations where a vector > would be better. Why? Because it's dead simple and I need to get it running > now. I suppose we get used to doing the same thing the same way and don't > always pay attention to these details when a deadline is fast approaching. It > helps to be reminded of best practice tips from time to time when checking a > class I use out of habit. FWIW, boost has flat_map container which provides sorted array with map's interface. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
>For those guys, no amount of documentation will save them from writing >bad code, so I don't think we should concern ourselves much with this case. >I'm happy with the documentation if an educated developer reads it, and >is able to make the correct decision on which container class to use. You're sort of nullifying the concept of recommending best practices at all. We won't be asking the developers to include basic CS concepts when documenting a new class, if that's a worry. In this case, I asked for clarification of some points, so I could add a recommendation to QMap myself. I use QMap all the time, and almost certainly in situations where a vector would be better. Why? Because it's dead simple and I need to get it running now. I suppose we get used to doing the same thing the same way and don't always pay attention to these details when a deadline is fast approaching. It helps to be reminded of best practice tips from time to time when checking a class I use out of habit. martin From: development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Smith Martin Sent: Tuesday, February 10, 2015 12:20 PM To: Marc Mutz Cc: development@qt-project.org Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.) >I'm not saying that the docs should not contain some information. I'm saying >that this is not about our users, it's about us, the developers. I'm just adding that for some of the points you raised, if they have to be raised for us, the developers, it's a good bet they our users will benefit from them as well. martin From: m...@kdab.com on behalf of Marc Mutz Sent: Tuesday, February 10, 2015 11:35 AM To: Smith Martin Cc: Ziller Eike; development@qt-project.org Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.) On Tuesday 10 February 2015 11:01:50 Smith Martin wrote: > >So, no, I don't think we should discuss everthing ever written about C++ > >efficiency in the Qt docs. But we need to point it out to each other in > >code reviews and become better at not writing sloppy code. > > The suggestion was not to discuss everything about C++ efficiency but to > discuss the traps for young players using a QMap when a sorted QVector > would be better. I'm not saying that the docs should not contain some information. I'm saying that this is not about our users, it's about us, the developers. > >IOW: We need to start thinking about our algorithms and data structures > >again[1], but this time in the new world of caches and multithreading > >where the only fast data structure is an array.[2] > > But if this is a new world, then the CS course and reference books you > suggested might not say much about it yet. http://www.akkadia.org/drepper/cpumemory.pdf Note the publication date. > I'll bet most of our customers are not the C++ equivalents of Bruce Lee you > imagine them to be. Some of them might be coming to C++ via trying to > create something in QML. Again, I'm not talking to or about our users, I'm talking to and about us, the developers. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
>I'm not saying that the docs should not contain some information. I'm saying >that this is not about our users, it's about us, the developers. I'm just adding that for some of the points you raised, if they have to be raised for us, the developers, it's a good bet they our users will benefit from them as well. martin From: m...@kdab.com on behalf of Marc Mutz Sent: Tuesday, February 10, 2015 11:35 AM To: Smith Martin Cc: Ziller Eike; development@qt-project.org Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.) On Tuesday 10 February 2015 11:01:50 Smith Martin wrote: > >So, no, I don't think we should discuss everthing ever written about C++ > >efficiency in the Qt docs. But we need to point it out to each other in > >code reviews and become better at not writing sloppy code. > > The suggestion was not to discuss everything about C++ efficiency but to > discuss the traps for young players using a QMap when a sorted QVector > would be better. I'm not saying that the docs should not contain some information. I'm saying that this is not about our users, it's about us, the developers. > >IOW: We need to start thinking about our algorithms and data structures > >again[1], but this time in the new world of caches and multithreading > >where the only fast data structure is an array.[2] > > But if this is a new world, then the CS course and reference books you > suggested might not say much about it yet. http://www.akkadia.org/drepper/cpumemory.pdf Note the publication date. > I'll bet most of our customers are not the C++ equivalents of Bruce Lee you > imagine them to be. Some of them might be coming to C++ via trying to > create something in QML. Again, I'm not talking to or about our users, I'm talking to and about us, the developers. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 11:01:50 Smith Martin wrote: > >So, no, I don't think we should discuss everthing ever written about C++ > >efficiency in the Qt docs. But we need to point it out to each other in > >code reviews and become better at not writing sloppy code. > > The suggestion was not to discuss everything about C++ efficiency but to > discuss the traps for young players using a QMap when a sorted QVector > would be better. I'm not saying that the docs should not contain some information. I'm saying that this is not about our users, it's about us, the developers. > >IOW: We need to start thinking about our algorithms and data structures > >again[1], but this time in the new world of caches and multithreading > >where the only fast data structure is an array.[2] > > But if this is a new world, then the CS course and reference books you > suggested might not say much about it yet. http://www.akkadia.org/drepper/cpumemory.pdf Note the publication date. > I'll bet most of our customers are not the C++ equivalents of Bruce Lee you > imagine them to be. Some of them might be coming to C++ via trying to > create something in QML. Again, I'm not talking to or about our users, I'm talking to and about us, the developers. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
>So, no, I don't think we should discuss everthing ever written about C++ >efficiency in the Qt docs. But we need to point it out to each other in code >reviews and become better at not writing sloppy code. The suggestion was not to discuss everything about C++ efficiency but to discuss the traps for young players using a QMap when a sorted QVector would be better. >IOW: We need to start thinking about our algorithms and data structures >again[1], but this time in the new world of caches and multithreading where >the only fast data structure is an array.[2] But if this is a new world, then the CS course and reference books you suggested might not say much about it yet. I'll bet most of our customers are not the C++ equivalents of Bruce Lee you imagine them to be. Some of them might be coming to C++ via trying to create something in QML. martin From: m...@kdab.com on behalf of Marc Mutz Sent: Tuesday, February 10, 2015 10:51 AM To: Ziller Eike Cc: Smith Martin; development@qt-project.org Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.) On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote: > > On Feb 9, 2015, at 3:40 PM, Marc Mutz wrote: > > > > On Monday 09 February 2015 09:54:12 Smith Martin wrote: > >> This is the kind of thing we should add to the documentation, but can > >> you elaborate? I mean, illustrate the meaning of "locality of > >> reference," "wildly mixing insertions, lookups, and removals," and > >> "batch updates and separate them from lookups, time-wise." > > > > There is a book, Effective STL, and an online paper, "What every > > programmer needs to know about memory". I don't think that it's the job > > of the Qt docs to explain "what every programmer needs to know about > > memory", because it is not specific to Qt. > > > > The Qt documentation also doesn't give many details on Unicode. It's > > assumed that people using it know the basics. > > > > You will also not find in the Qt docs that signed integer overflow is > > undefined behaviour. > > > > The Qt docs are not a CS text book :) > > That QMap is implemented based on a RB tree is mentioned in a single > sentence in the beginning of the description of the class, which is the > sentence that nobody ever reads (because it tends to contain useful > information like "The QList class is a template class that provides > lists.”). > > It is followed by a short (but longer) comparison between QMap and QHash, > which in turn is linked to a relatively long section that compares the > complexity of Qt’s different containers. So, fact is that the Qt docs *do* > explain more than “QMap is a RB tree” (and I think that is good so). And > since they talk a lot about algorithmic complexity, it would probably be > useful to mention a few other things that concern performance differences > as well. In ~5 sentences. I really can’t see how that could hurt. > > Actually you sounded like you’d like to educate people about this also > “outside of CS courses” (by sending them to their manager etc), so do you > have a different, realistic proposal? The topic of this thread is guidelines for Qt code, not code using Qt. We don't want to impose writing Q_DECL_CONSTEXPR everywhere possible for users of Qt. Likewise, if they want to use QMap, then that's fine. A profiler will tell them if they made a mistake that matters. The situation is different for Qt code: Consider a recent example: QString::multiArg(). It used a QMap. Now it uses a QVarLengthArray (introduced in 7b5ba56b0ab55fcaf79fbf9aad70bf767c938e15). A very naïve benchmark (I'm allowed to say that, it was my choice). was sped up by 30%. The naïviteé in the benchmark is that this includes repeated allocation of a handful of QString arguments from short (C) string literals each time through the loop, which probably dominates the result. We don't know what Qt is being used for, so we need to optimize everything. One user surely will run multiArg() in a tight loop and that will dominate his runtime. As every C++ library that's any good, we cannot be sloppy when it comes to efficiency. So, no, I don't think we should discuss everthing ever written about C++ efficiency in the Qt docs. But we need to point it out to each other in code reviews and become better at not writing sloppy code. IOW: We need to start thinking about our algorithms and data structures again[1], but this time in the new world of caches and multithreading where the only fast data structure is an array.[2] Thanks, Marc [1] http://www.amazon.com/Algorithms-Structures-Prentice-Hall-Automatic- Computation/dp/013022418
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote: > > On Feb 9, 2015, at 3:40 PM, Marc Mutz wrote: > > > > On Monday 09 February 2015 09:54:12 Smith Martin wrote: > >> This is the kind of thing we should add to the documentation, but can > >> you elaborate? I mean, illustrate the meaning of "locality of > >> reference," "wildly mixing insertions, lookups, and removals," and > >> "batch updates and separate them from lookups, time-wise." > > > > There is a book, Effective STL, and an online paper, "What every > > programmer needs to know about memory". I don't think that it's the job > > of the Qt docs to explain "what every programmer needs to know about > > memory", because it is not specific to Qt. > > > > The Qt documentation also doesn't give many details on Unicode. It's > > assumed that people using it know the basics. > > > > You will also not find in the Qt docs that signed integer overflow is > > undefined behaviour. > > > > The Qt docs are not a CS text book :) > > That QMap is implemented based on a RB tree is mentioned in a single > sentence in the beginning of the description of the class, which is the > sentence that nobody ever reads (because it tends to contain useful > information like "The QList class is a template class that provides > lists.”). > > It is followed by a short (but longer) comparison between QMap and QHash, > which in turn is linked to a relatively long section that compares the > complexity of Qt’s different containers. So, fact is that the Qt docs *do* > explain more than “QMap is a RB tree” (and I think that is good so). And > since they talk a lot about algorithmic complexity, it would probably be > useful to mention a few other things that concern performance differences > as well. In ~5 sentences. I really can’t see how that could hurt. > > Actually you sounded like you’d like to educate people about this also > “outside of CS courses” (by sending them to their manager etc), so do you > have a different, realistic proposal? The topic of this thread is guidelines for Qt code, not code using Qt. We don't want to impose writing Q_DECL_CONSTEXPR everywhere possible for users of Qt. Likewise, if they want to use QMap, then that's fine. A profiler will tell them if they made a mistake that matters. The situation is different for Qt code: Consider a recent example: QString::multiArg(). It used a QMap. Now it uses a QVarLengthArray (introduced in 7b5ba56b0ab55fcaf79fbf9aad70bf767c938e15). A very naïve benchmark (I'm allowed to say that, it was my choice). was sped up by 30%. The naïviteé in the benchmark is that this includes repeated allocation of a handful of QString arguments from short (C) string literals each time through the loop, which probably dominates the result. We don't know what Qt is being used for, so we need to optimize everything. One user surely will run multiArg() in a tight loop and that will dominate his runtime. As every C++ library that's any good, we cannot be sloppy when it comes to efficiency. So, no, I don't think we should discuss everthing ever written about C++ efficiency in the Qt docs. But we need to point it out to each other in code reviews and become better at not writing sloppy code. IOW: We need to start thinking about our algorithms and data structures again[1], but this time in the new world of caches and multithreading where the only fast data structure is an array.[2] Thanks, Marc [1] http://www.amazon.com/Algorithms-Structures-Prentice-Hall-Automatic- Computation/dp/0130224189 [2] http://vimeo.com/97337258 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
> On Feb 9, 2015, at 3:40 PM, Marc Mutz wrote: > > On Monday 09 February 2015 09:54:12 Smith Martin wrote: >> This is the kind of thing we should add to the documentation, but can you >> elaborate? I mean, illustrate the meaning of "locality of reference," >> "wildly mixing insertions, lookups, and removals," and "batch updates and >> separate them from lookups, time-wise." > > There is a book, Effective STL, and an online paper, "What every programmer > needs to know about memory". I don't think that it's the job of the Qt docs > to > explain "what every programmer needs to know about memory", because it is not > specific to Qt. > > The Qt documentation also doesn't give many details on Unicode. It's assumed > that people using it know the basics. > > You will also not find in the Qt docs that signed integer overflow is > undefined > behaviour. > > The Qt docs are not a CS text book :) That QMap is implemented based on a RB tree is mentioned in a single sentence in the beginning of the description of the class, which is the sentence that nobody ever reads (because it tends to contain useful information like "The QList class is a template class that provides lists.”). It is followed by a short (but longer) comparison between QMap and QHash, which in turn is linked to a relatively long section that compares the complexity of Qt’s different containers. So, fact is that the Qt docs *do* explain more than “QMap is a RB tree” (and I think that is good so). And since they talk a lot about algorithmic complexity, it would probably be useful to mention a few other things that concern performance differences as well. In ~5 sentences. I really can’t see how that could hurt. Actually you sounded like you’d like to educate people about this also “outside of CS courses” (by sending them to their manager etc), so do you have a different, realistic proposal? -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Mon, Feb 09, 2015 at 01:28:18PM -0800, Thiago Macieira wrote: > On Monday 09 February 2015 22:10:09 André Pönitz wrote: > > On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote: > > > On Monday 09 February 2015 21:21:12 André Pönitz wrote: > > > > I don't think the argument of whitespace changes making the history > > > > hard to read carries a lot of weight in a git world. > > > > > > Whitespaces can be ignored in git diff and git blame. > > > > This sounds a bit like 'whitespace changes in passing are Mostly > > Harmless'. Which I happen to be fine with. > > > > > You can't do that with C++ keywords. > > > > Would that be an argument against replacing '= 0' by '= Q_NULLPTR' > > under the 'fix whitespace in passing' rule? > > That was the original proposal I sent. But some people objected to it. > > I think we need to at the very least modernise our headers, since some > users may compile we strict warning options. I think there is room for a not too contended resolution along the lines of "do whatever you think that's needed in the headers as long as there won't be a Q_NULLPTR replacing a valid '0' in a .cpp file." Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Monday 09 February 2015 22:10:09 André Pönitz wrote: > On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote: > > On Monday 09 February 2015 21:21:12 André Pönitz wrote: > > > I don't think the argument of whitespace changes making the history > > > hard to read carries a lot of weight in a git world. > > > > Whitespaces can be ignored in git diff and git blame. > > This sounds a bit like 'whitespace changes in passing > are Mostly Harmless'. Which I happen to be fine with. > > > You can't do that with > > C++ keywords. > > Would that be an argument against replacing '= 0' by '= Q_NULLPTR' > under the 'fix whitespace in passing' rule? That was the original proposal I sent. But some people objected to it. I think we need to at the very least modernise our headers, since some users may compile we strict warning options. -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote: > On Monday 09 February 2015 21:21:12 André Pönitz wrote: > > I don't think the argument of whitespace changes making the history > > hard to read carries a lot of weight in a git world. > > Whitespaces can be ignored in git diff and git blame. This sounds a bit like 'whitespace changes in passing are Mostly Harmless'. Which I happen to be fine with. > You can't do that with > C++ keywords. Would that be an argument against replacing '= 0' by '= Q_NULLPTR' under the 'fix whitespace in passing' rule? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Monday 09 February 2015 21:21:12 André Pönitz wrote: > I don't think the argument of whitespace changes making the history > hard to read carries a lot of weight in a git world. Whitespaces can be ignored in git diff and git blame. You can't do that with C++ keywords. -- 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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Mon, Feb 09, 2015 at 09:11:54PM +0100, Marc Mutz wrote: > On Monday 09 February 2015 19:49:19 André Pönitz wrote: > > I am fairly sure that we won't reach consensus on what the set of such > > selected places exactly look like, that's why the plan to reach some > > conclusion was to restrict a part of the discussion to one case where I > > think there's a chance to get consensus that the use of the Q_NULLPTR > > macro is "obvious" nonsense. > > I find it confusing that in one mail you argue that introducing Q_NULLPTR in > passing (= the way we do formatting changes) introduces inconsistency, and in > another mail you're looking for "selected places" where "Q_NULLPTR makes > sense". > > Which one should it be? It simply depends on the location. And .cpp vs .h is a pretty good first approximation for a sensible rule in this case. > If there's one universal rule, it's that less rules are easier to follow. So: > > "Q_NULLPTR everywhere" instead of "in headers or [list of selected places]". The universal rule is 'use it when it has an obvious advantage', not 'use it whenever the compiler accepts it'. Pretty much the same rule as for any other feature of the language. And it's not a new rule for Qt either. There are a lot of things that are not acceptible in the public interface but completely fine in the implementation. > KIS, dude :) Will you propose to use 'auto' instead of 'int' whenever it compiles? Just because 'auto' *sometimes* makes sense? Wait. I don't think I am ready for your answer. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Mon, Feb 09, 2015 at 09:05:09PM +0100, Marc Mutz wrote: > On Monday 09 February 2015 20:10:44 André Pönitz wrote: > > On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote: > > > I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I > > > know at some point we will be able to just s/Q_NULLPTR/nullptr/. That's > > > not possible with 0 (not even with NULL (could be C code)), so I don't > > > see the point in continuing to use 0. > > > > At some time you will be able to ran clang-modernize with the Use-Nullptr > > transformation or something similar. > > > > Until then your attempts your tic to replace 0 by Q_NULLPTR as "white space > > fixes" will only convert a tiny fraction of the code base, introduce > > yet-another-non-uniformly-used-idiom. > > > > Diversity is good in biology. Less so in code. > > By the same token, we should stop fixing code formatting "mistakes" in > passing, since we could just run clang-format. Incidently, that is something I think should be done and also something that's at least conceptually and partially done in the Qt Creator code base. Code style changes there tend to start with a "allowed to be fixed in passing", only to be followed up with a few "now all-in" dedicated changes after a while. "In passing" alone never worked sufficiently well, not even within single plugins. A currently ongoing example of such activities is conversion of Qt4-style connects to Qt5-style. I don't think the argument of whitespace changes making the history hard to read carries a lot of weight in a git world. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Monday 09 February 2015 19:49:19 André Pönitz wrote: > I am fairly sure that we won't reach consensus on what the set of such > selected places exactly look like, that's why the plan to reach some > conclusion was to restrict a part of the discussion to one case where I > think there's a chance to get consensus that the use of the Q_NULLPTR > macro is "obvious" nonsense. I find it confusing that in one mail you argue that introducing Q_NULLPTR in passing (= the way we do formatting changes) introduces inconsistency, and in another mail you're looking for "selected places" where "Q_NULLPTR makes sense". Which one should it be? If there's one universal rule, it's that less rules are easier to follow. So: "Q_NULLPTR everywhere" instead of "in headers or [list of selected places]". KIS, dude :) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Monday 09 February 2015 20:10:44 André Pönitz wrote: > On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote: > > I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I > > know at some point we will be able to just s/Q_NULLPTR/nullptr/. That's > > not possible with 0 (not even with NULL (could be C code)), so I don't > > see the point in continuing to use 0. > > At some time you will be able to ran clang-modernize with the > Use-Nullptr transformation or something similar. > > Until then your attempts your tic to replace 0 by Q_NULLPTR as "white > space fixes" will only convert a tiny fraction of the code base, > introduce yet-another-non-uniformly-used-idiom. > > Diversity is good in biology. Less so in code. By the same token, we should stop fixing code formatting "mistakes" in passing, since we could just run clang-format. The difference is that in the in-passing model, the code history isn't clobbered with "reformat" commits. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote: > I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I know > at some point we will be able to just s/Q_NULLPTR/nullptr/. That's not > possible with 0 (not even with NULL (could be C code)), so I don't see the > point in continuing to use 0. At some time you will be able to ran clang-modernize with the Use-Nullptr transformation or something similar. Until then your attempts your tic to replace 0 by Q_NULLPTR as "white space fixes" will only convert a tiny fraction of the code base, introduce yet-another-non-uniformly-used-idiom. Diversity is good in biology. Less so in code. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Mon, Feb 09, 2015 at 08:36:53AM +0100, Bo Thorsen wrote: > > > > For the sake of keeping this part of the discussion simple, I specifically > > mean 'Q_NULLPTR, the macro', _not_ 'nullptr', and I specifically mean the > > context of initializing a local pointer variable. So: Any advantage? Any > > advantage outweighing the disadvantages? > > For this simple example, there is absolutely no benefit. Not even if you > had replaced Q_NULLPTR with nullptr. Good. Thanks for answering the question. > But you forget that it isn't about this simple case. It's about the V > harder cases, which makes you want to compile your code with warnings > about 0 for pointers. And that's impossible if at least the Qt headers > are not clean for it. I am *not* forgetting about the other cases. I am trying to restrict this part of the discussion on *one* case were everybody might agree. Accepting/rejecting the use of some idiom in one case does not mean anything about any other case. If I accept a hammer as a useful tool to drive a nails it does not mean I have to accept it as a useful tool to clean clothes. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Mon, Feb 09, 2015 at 12:07:15AM +0100, Allan Sandfeld Jensen wrote:
> On Sunday 08 February 2015, André Pönitz wrote:
> > On Sun, Feb 08, 2015 at 10:17:40PM +0100, Allan Sandfeld Jensen wrote:
> > > What would be the point of macros if they always expanded? The entire
> > > point and usefulness of these macros is that they expand to standard
> > > keywords when those standard keywords exists.
> >
> > What's the point of using a macro in circumstances where a portable,
> > standard conforming, safe-to-use, shorter-to-type, version _without_ using
> > a macro exists?
> >
> > I.e. in case of a simple pointer initialization, why should one *ever*
> > prefer
> >
> > void something() { Foo *f = Q_NULLPTR; ... }
> >
> > over
> >
> > void something() { Foo *f = 0; ... }
> >
> > ?
> >
> > For the sake of keeping this part of the discussion simple, I specifically
> > mean 'Q_NULLPTR, the macro', _not_ 'nullptr', and I specifically mean the
> > context of initializing a local pointer variable. So: Any advantage? Any
> > advantage outweighing the disadvantages?
> >
> If you use in the wrongly in a function call where integers are supposed to
> be used, we will get an error on the C++11 enabled builds even it if passes
> on C++98. Could also expose wrong implied constructors being used.
>
> I am not a big fan of nullptr, but it makes sense in a few places, and can
> see the point in use Q_NULLPTR there.
I already mentioned earlier in this thread ("last year") that I agree that
nullptr makes sense in a few, selected places, and I might agree that until
nullptr can be used, using Q_NULLPTR in those selected places _might_ make
sense.
I am fairly sure that we won't reach consensus on what the set of such selected
places exactly look like, that's why the plan to reach _some_ conclusion was to
restrict a part of the discussion to one case where I think there's a chance to
get consensus that the use of the Q_NULLPTR macro is "obvious" nonsense.
I wrote:
For the sake of keeping this part of the discussion simple, I specifically
mean 'Q_NULLPTR, the macro', _not_ 'nullptr', and I specifically mean the
context of initializing a local pointer variable. So: Any advantage? Any
Again, the case under consideration is
"{ Foo *f = Q_NULLPTR; ... }" vs "{ Foo *f = 0; ... }"
Initialization of a pointer variable. Using preprocessor vs. perfectly
valid, unambiguous use of the C++ core languange.
The answers are, order of increasing surprise factor:
1) "I am not a big fan of nullptr, but it makes sense in a few places,
and can " see the point in use Q_NULLPTR there."
-- That's not (fully?) matching the case condition.
2) "it takes me a couple of milliseconds extra to comprehend what the
tooltip for QVariant's toInt() means:
int toInt(bool *ok = 0) const;
instead, if qvariant.h could be written using nullptr or Q_NULLPTR:
It would increase the quality of Qt for me, at least."
-- That's not matching the case condition at all.
3) "I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), "
-- That's _could be_ meant to be matching the case condition (Thanks,
Marc, for reading) but it is also the first time in the last 20
years I saw someone calling the use of the preprocessor instead of
a perfectly legal C++ idiom
By now I have a hard time to understand how conflict resolution in this
model is supposed to work.
Any two approvers can commit whatever they want, introducing whatever personal
coding style they feel like? Discussions that are meant to get consensus at
least about part of the problem are watered down by adding more and more
off-topic side track until "hopefully nobody cares anymore"?
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Monday 09 Feb 2015 16:12:06 Marc Mutz wrote: > On Monday 09 February 2015 15:56:28 Sean Harmer wrote: > [...] > > > I guess depending upon the sizes of your key and value types and number of > > elements and typical frequencies of operations (inserts vs lookups vs > > removals) it may also possibly be better to use two vectors, one for the > > keys and one for the values. > > > > The rationale being that if your value type is large you reduce the number > > of key values that can be stored in a cache line and therefore incur more > > cache misses when performing lookups. Of course you would still incur at > > least one cache miss when loading in the value to return. > > > > It's surprising just how expensive cache misses are these days compared to > > traditionally thought-to-be-expensive CPU instructions. > > > > Anyway, if somebody does implement a nice wrapper around such sorted > > vectors with sufficient controls to force/not-force the sorted invariant > > to allow efficient insertion/removal vs efficient lookups, we have a ton > > of places in Qt3D where you could test such a beast. :) > > Ah, the pleasure! Someone not only understands the arguments, but lifts them > to the next level, too. > > This one is for you: > https://codereview.qt-project.org/105743 > > (completely unfinished, you can't even remove elements) Great! Looks very promising. If you want to try it out in Qt3D as private API to let it mature before moving it to QtCore, then please feel free. Thanks! Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Monday 09 February 2015 15:56:28 Sean Harmer wrote: [...] > I guess depending upon the sizes of your key and value types and number of > elements and typical frequencies of operations (inserts vs lookups vs > removals) it may also possibly be better to use two vectors, one for the > keys and one for the values. > > The rationale being that if your value type is large you reduce the number > of key values that can be stored in a cache line and therefore incur more > cache misses when performing lookups. Of course you would still incur at > least one cache miss when loading in the value to return. > > It's surprising just how expensive cache misses are these days compared to > traditionally thought-to-be-expensive CPU instructions. > > Anyway, if somebody does implement a nice wrapper around such sorted > vectors with sufficient controls to force/not-force the sorted invariant > to allow efficient insertion/removal vs efficient lookups, we have a ton > of places in Qt3D where you could test such a beast. :) Ah, the pleasure! Someone not only understands the arguments, but lifts them to the next level, too. This one is for you: https://codereview.qt-project.org/105743 (completely unfinished, you can't even remove elements) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Monday 09 Feb 2015 09:49:08 Marc Mutz wrote: > On Monday 09 February 2015 09:32:56 Marc Mutz wrote: > > > Something like this should work just as well on QVector, right? If you > > > are doing multiple inserts, perhaps you should keep the inserts outside > > > the main vector while you make them, and only at the end do a single > > > std::merge. > > > > Boom. Enter quadratic behaviour. > > > > There is Loki::AssociativeVector, but things like the above is why no-one > > is using it. You only gain if you don't contantly maintain the is_sorted > > invariant. > > To make my statement more precise: As soon as you provide insert_sorted, the > same people who now use QSet + toList + sort() will invariably use it in a > loop. > > Using a plain vector *is* fine. One just need to get over the fact that this > is not Python and one has to use std algorithms and function objects. > > It's not the syntax that's a problem. It's the semantics that need to be > understood. In this case, *both* algorithmic complexity *and* the cost of > non- locality of reference (which is why QMap is so bad). I guess depending upon the sizes of your key and value types and number of elements and typical frequencies of operations (inserts vs lookups vs removals) it may also possibly be better to use two vectors, one for the keys and one for the values. The rationale being that if your value type is large you reduce the number of key values that can be stored in a cache line and therefore incur more cache misses when performing lookups. Of course you would still incur at least one cache miss when loading in the value to return. It's surprising just how expensive cache misses are these days compared to traditionally thought-to-be-expensive CPU instructions. Anyway, if somebody does implement a nice wrapper around such sorted vectors with sufficient controls to force/not-force the sorted invariant to allow efficient insertion/removal vs efficient lookups, we have a ton of places in Qt3D where you could test such a beast. :) Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Mon, Feb 09, 2015 at 03:30:06PM +0100, Marc Mutz wrote: > On Monday 09 February 2015 14:21:44 Rutledge Shawn wrote: > > But the advantage of Qt data structures is the implicit sharing. > > Cough, cough. > > http://www.gotw.ca/publications/optimizations.htm (watch the publication date) > and what exactly is this supposed to tell us? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
Am 09.02.2015 um 15:40 schrieb Marc Mutz: > On Monday 09 February 2015 09:54:12 Smith Martin wrote: >> This is the kind of thing we should add to the documentation, but can you >> elaborate? I mean, illustrate the meaning of "locality of reference," >> "wildly mixing insertions, lookups, and removals," and "batch updates and >> separate them from lookups, time-wise." > > There is a book, Effective STL, and an online paper, "What every programmer > needs to know about memory". I don't think that it's the job of the Qt docs to > explain "what every programmer needs to know about memory", because it is not > specific to Qt. > > The Qt documentation also doesn't give many details on Unicode. It's assumed > that people using it know the basics. > > You will also not find in the Qt docs that signed integer overflow is > undefined > behaviour. > > The Qt docs are not a CS text book :) > I totally agree, but how about adding a section with recommended readings to some prominent place instead? Ciao, Mathias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Monday 09 February 2015 09:54:12 Smith Martin wrote: > This is the kind of thing we should add to the documentation, but can you > elaborate? I mean, illustrate the meaning of "locality of reference," > "wildly mixing insertions, lookups, and removals," and "batch updates and > separate them from lookups, time-wise." There is a book, Effective STL, and an online paper, "What every programmer needs to know about memory". I don't think that it's the job of the Qt docs to explain "what every programmer needs to know about memory", because it is not specific to Qt. The Qt documentation also doesn't give many details on Unicode. It's assumed that people using it know the basics. You will also not find in the Qt docs that signed integer overflow is undefined behaviour. The Qt docs are not a CS text book :) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Monday 09 February 2015 14:21:44 Rutledge Shawn wrote: > But the advantage of Qt data structures is the implicit sharing. Cough, cough. http://www.gotw.ca/publications/optimizations.htm (watch the publication date) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Monday 09 February 2015, Mathias Hasselmann wrote: > Am 09.02.2015 um 00:07 schrieb Allan Sandfeld Jensen: > > I am not a big fan of nullptr, > > Out of curiosity: What's wrong with nullptr in your opinion? > Nothing, except it is just usually not needed, so coding styles that enforce it are more harm than good, since using it is often just breaking C++98 compat for no good reason. The same as with using template> over template >. It is neat syntax, but also mostly pointless, and pisses me off when people autoreplace it an entire project, with the only consequence of breaking older compilers and tools and not improving anything except satisfying their OCD. `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 9 Feb 2015, at 13:42, Smith Martin wrote: >>> Everyone wishing to use a QMap should implement one before >>> using it for the first time. Then you'd see what you inflict on the world. > > If that sentiment is valid, then we owe it to our users who are contemplating > using a QMap to explain to them when and why a QMap should be used and when > and why a QVector should be used instead. > >> IMHO: A lot of this is information you find in a CS course or in a book. >> Not in the Qt documentation. > > I came out of a CS course, but I would find that information helpful. Plus, > we hope to attract users to Qt who didn't come out of a CS course. +1 to that. I also didn’t think that QMap was so bad, because O(log n) doesn’t sound bad; and I don’t remember having written a red-black tree from scratch before, either. The docs also say that QHash is faster but QMap is sorted. So my inclination is if I really want the built-in sorting (maybe because I want to be able to iterate the keys or values in a predictable order), and I want to map arbitrary keys to arbitrary values, where the two are not related, or when the value contains the key but also contains other stuff, then I’d tend to use a QMap. If the value does not contain the key, and you want to use a sorted vector instead, you would have to create an artificial “node” class (or use QPair) just to put the key together with the value so that you can put it into the vector, right? If that is a better way, maybe we should have a wrapper class to make it easy. The help about QVector does not even contain the word “sort”, so you have to know to use std::sort (or by reading the qSort doc where it says to use std::sort instead). Nor do we have any classes called QSortedSomething. Or should we recommend to use more STL structures instead of Qt ones? But the advantage of Qt data structures is the implicit sharing. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
>>Everyone wishing to use a QMap should implement one before >>using it for the first time. Then you'd see what you inflict on the world. If that sentiment is valid, then we owe it to our users who are contemplating using a QMap to explain to them when and why a QMap should be used and when and why a QVector should be used instead. >IMHO: A lot of this is information you find in a CS course or in a book. >Not in the Qt documentation. I came out of a CS course, but I would find that information helpful. Plus, we hope to attract users to Qt who didn't come out of a CS course. martin From: development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Bo Thorsen Sent: Monday, February 9, 2015 12:05 PM To: development@qt-project.org Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.) On 02/09/2015 09:54 AM, Smith Martin wrote: > > "In the vast majority of cases, a sorted vector is much faster, due to > locality-of-reference. A RB-tree is optimized for wildly mixing > insertions, > lookups, and removals. When you can batch updates and separate them from > lookups, time-wise, then a sorted vector is usually preferrable." > > This is the kind of thing we should add to the documentation, but can you > elaborate? I mean, illustrate the meaning of "locality of reference," "wildly > mixing insertions, lookups, and removals," and "batch updates and separate > them from lookups, time-wise." IMHO: A lot of this is information you find in a CS course or in a book. Not in the Qt documentation. That said, there is certainly room for more info on performance impact in the Qt documentation. The discussion a while ago about what calls removes the effect of reserve() was one example. Bo. > > From: development-bounces+martin.smith=theqtcompany@qt-project.org > on behalf > of Marc Mutz > Sent: Sunday, February 8, 2015 2:28 PM > To: development@qt-project.org > Cc: Thiago Macieira > Subject: Re: [Development] Upgrading the sources to C++11 keywords > (Q_NULLPTR, etc.) > > Hi, > > Sorry for being late, didn't see the thread before. > > On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> I think it's time to institute a policy that we should fix our sources to >> use the new C++11 keywords. I'd like to propose the following. > > I totally agree, with the following amendments: > > 1. override - before adding an overriding function to a class, add > Q_DECL_OVERRIDE to all members in a separate commit, to avoid said > warning. > > 2. noexcept/nothrow - the only difference between the two is that nothrow may > expand to throw() on compilers that implement semantics close to noexcept > for that, and not the C++98 standard behaviour. This is currently only the > case for MSVC, even though I believe GCC has a switch to emulate MSVC > here. > The semantic difference currently, is: when you violate noexcept, you're > getting C++11 behaviour (std::terminate is called) or the exception leaves > the function. If you violate nothrow, you're enterin undefined bahaviour. > So only use nothrow if functions _cannot possibly_ throw. If you want to > say "I'm fine with errors in this function terminating the process", which > you should be very carefully considering (it should be the exception), you > must use noexcept instead. Obviously, if you need conditionally-noexcept, > you must use noexcept_expr. > > Talking about warnings: there's -Wnoexcept, which warns when a > conditionally-noexcept function turns noexecpt(false) because of a > function > that isn't marked noexcept and where the compiler can prove it doesn't > throw. That's a bit of a mouthful, but this, too, should be added to the > headersclean check. > > Talking about narrow contracts: A function has a narrow contract if it has > preconditions (on it's arguments, or *this). If you have preciditions, you > may, in debug mode, assert them as an aid to the user of your function. > Assertions may be turned by the user (there's also a movement behind John > Lakos, yes, _the_ John Lakos that essentially gave us the d-pointer, to > make this standard functionality), into exception throwing (which I had > personally good experience with during Kleopatra development). But if your > users do this, they expect to receive those exceptions, and not terminate > the program without a hint that an assertion was triggered). > > That's why functions wit
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 02/09/2015 09:54 AM, Smith Martin wrote: > > "In the vast majority of cases, a sorted vector is much faster, due to > locality-of-reference. A RB-tree is optimized for wildly mixing > insertions, > lookups, and removals. When you can batch updates and separate them from > lookups, time-wise, then a sorted vector is usually preferrable." > > This is the kind of thing we should add to the documentation, but can you > elaborate? I mean, illustrate the meaning of "locality of reference," "wildly > mixing insertions, lookups, and removals," and "batch updates and separate > them from lookups, time-wise." IMHO: A lot of this is information you find in a CS course or in a book. Not in the Qt documentation. That said, there is certainly room for more info on performance impact in the Qt documentation. The discussion a while ago about what calls removes the effect of reserve() was one example. Bo. > > From: development-bounces+martin.smith=theqtcompany@qt-project.org > on behalf > of Marc Mutz > Sent: Sunday, February 8, 2015 2:28 PM > To: development@qt-project.org > Cc: Thiago Macieira > Subject: Re: [Development] Upgrading the sources to C++11 keywords > (Q_NULLPTR, etc.) > > Hi, > > Sorry for being late, didn't see the thread before. > > On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> I think it's time to institute a policy that we should fix our sources to >> use the new C++11 keywords. I'd like to propose the following. > > I totally agree, with the following amendments: > > 1. override - before adding an overriding function to a class, add > Q_DECL_OVERRIDE to all members in a separate commit, to avoid said > warning. > > 2. noexcept/nothrow - the only difference between the two is that nothrow may > expand to throw() on compilers that implement semantics close to noexcept > for that, and not the C++98 standard behaviour. This is currently only the > case for MSVC, even though I believe GCC has a switch to emulate MSVC > here. > The semantic difference currently, is: when you violate noexcept, you're > getting C++11 behaviour (std::terminate is called) or the exception leaves > the function. If you violate nothrow, you're enterin undefined bahaviour. > So only use nothrow if functions _cannot possibly_ throw. If you want to > say "I'm fine with errors in this function terminating the process", which > you should be very carefully considering (it should be the exception), you > must use noexcept instead. Obviously, if you need conditionally-noexcept, > you must use noexcept_expr. > > Talking about warnings: there's -Wnoexcept, which warns when a > conditionally-noexcept function turns noexecpt(false) because of a > function > that isn't marked noexcept and where the compiler can prove it doesn't > throw. That's a bit of a mouthful, but this, too, should be added to the > headersclean check. > > Talking about narrow contracts: A function has a narrow contract if it has > preconditions (on it's arguments, or *this). If you have preciditions, you > may, in debug mode, assert them as an aid to the user of your function. > Assertions may be turned by the user (there's also a movement behind John > Lakos, yes, _the_ John Lakos that essentially gave us the d-pointer, to > make this standard functionality), into exception throwing (which I had > personally good experience with during Kleopatra development). But if your > users do this, they expect to receive those exceptions, and not terminate > the program without a hint that an assertion was triggered). > > That's why functions with narrow contracts should not be noexcept. > > Aside: of course, you can often drop preconditions by tightening the > interface of the function. E.g. instead of taking a naked pointer, you > could take a non_null_ptr, which would explode when constructed with a > nullptr, thus making sure that every successfully constructed instance is > actually representing a non-null pointer. Another technique is to use > enums, because the standard says that you cannot load a value from an enum > variable that does not correspond to one of the enumerated values. Doing > otherwise constitutes undefined behaviour, and compilers are getting > oh-so- > good at exploiting UB that your only chance is to learn about and avoid > them. > > 3. nullptr - On top of the warning, which I wasn't aware about, I find the > code easier to read. It'
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
Hi, just my 2 cents: just coding some database stuff using QVariants,
and invariably (especially Monday mornings) it takes me a couple of
milliseconds extra to comprehend what the tooltip for QVariant's toInt()
means:
int toInt(bool *ok = 0) const;
instead, if qvariant.h could be written using nullptr or Q_NULLPTR:
int toInt(bool *ok = Q_NULLPTR) const;
It would increase the quality of Qt for me, at least.
Rgrds Henry
On 2015-02-09 08:36, Bo Thorsen wrote:
> Den 08-02-2015 kl. 22:42 skrev André Pönitz:
>> On Sun, Feb 08, 2015 at 10:17:40PM +0100, Allan Sandfeld Jensen wrote:
>>> What would be the point of macros if they always expanded? The entire point
>>> and usefulness of these macros is that they expand to standard keywords when
>>> those standard keywords exists.
>>
>> What's the point of using a macro in circumstances where a portable, standard
>> conforming, safe-to-use, shorter-to-type, version _without_ using a macro
>> exists?
>>
>> I.e. in case of a simple pointer initialization, why should one *ever* prefer
>>
>> void something()
>> {
>> Foo *f = Q_NULLPTR;
>> ...
>> }
>>
>> over
>>
>> void something()
>> {
>> Foo *f = 0;
>> ...
>> }
>>
>> ?
>>
>> For the sake of keeping this part of the discussion simple, I specifically
>> mean 'Q_NULLPTR, the macro', _not_ 'nullptr', and I specifically mean the
>> context of initializing a local pointer variable. So: Any advantage? Any
>> advantage outweighing the disadvantages?
>
> For this simple example, there is absolutely no benefit. Not even if you
> had replaced Q_NULLPTR with nullptr.
>
> But you forget that it isn't about this simple case. It's about the
> harder cases, which makes you want to compile your code with warnings
> about 0 for pointers. And that's impossible if at least the Qt headers
> are not clean for it.
>
> Whether we should use Q_NULLPTR in the cpp files is more of our own choice.
>
> Bo Thorsen,
> Director, Viking Software.
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
"In the vast majority of cases, a sorted vector is much faster, due to locality-of-reference. A RB-tree is optimized for wildly mixing insertions, lookups, and removals. When you can batch updates and separate them from lookups, time-wise, then a sorted vector is usually preferrable." This is the kind of thing we should add to the documentation, but can you elaborate? I mean, illustrate the meaning of "locality of reference," "wildly mixing insertions, lookups, and removals," and "batch updates and separate them from lookups, time-wise." martin From: development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Marc Mutz Sent: Sunday, February 8, 2015 2:28 PM To: development@qt-project.org Cc: Thiago Macieira Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.) Hi, Sorry for being late, didn't see the thread before. On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > I think it's time to institute a policy that we should fix our sources to > use the new C++11 keywords. I'd like to propose the following. I totally agree, with the following amendments: 1. override - before adding an overriding function to a class, add Q_DECL_OVERRIDE to all members in a separate commit, to avoid said warning. 2. noexcept/nothrow - the only difference between the two is that nothrow may expand to throw() on compilers that implement semantics close to noexcept for that, and not the C++98 standard behaviour. This is currently only the case for MSVC, even though I believe GCC has a switch to emulate MSVC here. The semantic difference currently, is: when you violate noexcept, you're getting C++11 behaviour (std::terminate is called) or the exception leaves the function. If you violate nothrow, you're enterin undefined bahaviour. So only use nothrow if functions _cannot possibly_ throw. If you want to say "I'm fine with errors in this function terminating the process", which you should be very carefully considering (it should be the exception), you must use noexcept instead. Obviously, if you need conditionally-noexcept, you must use noexcept_expr. Talking about warnings: there's -Wnoexcept, which warns when a conditionally-noexcept function turns noexecpt(false) because of a function that isn't marked noexcept and where the compiler can prove it doesn't throw. That's a bit of a mouthful, but this, too, should be added to the headersclean check. Talking about narrow contracts: A function has a narrow contract if it has preconditions (on it's arguments, or *this). If you have preciditions, you may, in debug mode, assert them as an aid to the user of your function. Assertions may be turned by the user (there's also a movement behind John Lakos, yes, _the_ John Lakos that essentially gave us the d-pointer, to make this standard functionality), into exception throwing (which I had personally good experience with during Kleopatra development). But if your users do this, they expect to receive those exceptions, and not terminate the program without a hint that an assertion was triggered). That's why functions with narrow contracts should not be noexcept. Aside: of course, you can often drop preconditions by tightening the interface of the function. E.g. instead of taking a naked pointer, you could take a non_null_ptr, which would explode when constructed with a nullptr, thus making sure that every successfully constructed instance is actually representing a non-null pointer. Another technique is to use enums, because the standard says that you cannot load a value from an enum variable that does not correspond to one of the enumerated values. Doing otherwise constitutes undefined behaviour, and compilers are getting oh-so- good at exploiting UB that your only chance is to learn about and avoid them. 3. nullptr - On top of the warning, which I wasn't aware about, I find the code easier to read. It's a mouthful, but it's what everyone will be using five years from now, so we might as well start it now. I treat this as a whitespace error, meaning I correct it whenever I touch a line of code for unrelated changes. I would add the following, unrelated to C++11, but found all over the place in Qt, and it's next to impossible to root out: Algorithmic ineffciency. That's a large blob, but the most important instances of it are: a. Not marking types as movable or primitive. We might actually want to have a policy to mark complex types explicitly as complex, to allow easier fixing of missing declarations. The rule here should be that every new class or struct that may at some point be held in a container must have a q_declare_typei
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
Am 09.02.2015 um 08:48 schrieb André Somers:
> Mathias Hasselmann schreef op 8-2-2015 om 22:28:
>>
>> Am 08.02.2015 um 14:28 schrieb Marc Mutz:
>>
>>> c. Using QMap. As Alex Stepanov put it: every use of a map should be
>>> discussed
>>> in a face-to-face meeting with your manager. Since we don't have that,
>>> I'd
>>> change this to: Everyone wishing to use a QMap should implement one
>>> before
>>> using it for the first time. Then you'd see what you inflict on the
>>> world.
>>>
>>> In the vast majority of cases, a sorted vector is much faster, due to
>>> locality-of-reference. A RB-tree is optimized for wildly mixing
>>> insertions,
>>> lookups, and removals. When you can batch updates and separate them
>>> from
>>> lookups, time-wise, then a sorted vector is usually preferrable.
>> I totally agree, thank you for raising this. Sadly a sorted vector isn't
>> as convenient to use as a map. Maybe there should some convenience API
>> added, Or does it exist already and I am just too ignorant to know it?
> How about this?
>
> |template< typename T>
> typename std::vector::iterator
> insert_sorted( std::vector & vec, Tconst& item)
> {
> return vec.insert
> (
> std::upper_bound( vec.begin(), vec.end(), item),
> item
> );
> }|
>
> (from http://stackoverflow.com/a/25524075/2151404)
>
> Something like this should work just as well on QVector, right? If you
> are doing multiple inserts, perhaps you should keep the inserts outside
> the main vector while you make them, and only at the end do a single
> std::merge.
Uh, seems you found one of the worse corners of Stackoverflow... :-)
To case of QMap vs. sorted vector really is, that QMap makes the
"mistake" of expensively sorting on each insert. In contrast to that,
when using sorted sorted vectors you simply append while building the
container and sort its content in a final step when done. Complexity
class for both approaches is O(n log n). I think you know that, but what
people often forget is, that Landau notation only describes the number
of iterations needed to execute an algorithm. What it hides is cost of
each iteration step, and that's where sorted vectors win over maps when
inserting during construction only: Swapping two elements is
significantly cheaper than rotating RB trees.
Finally there is the pathologic case where you receive elements in
sorted order already. In that case you can skip the final sorting step
for vectors, while maps still is sorting.
Also interesting is the case of merging two sorted vectors: Adopting
merge sort the problem implodes to O(n) while maps still do O(n log n).
Anyway, the real usability problem with sorted vectors is not with
building them:
foreach (Element x, input)
vector.append(x);
qSort(begin(vector), end(vector));
Is trivial to do. Similar:
c.reserve(a.size() + b.size());
for (auto itA = begin(a), itB = begin(b);
itA != end(a) && itB != end(b); )
c.append(*itA < *itB ? *itA++ : *itB++);
The convenience issue is for users of your sorted vector, who can't just
write "cout << sortedVector.value(key) << endl" anymore.
Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Monday 09 February 2015 09:32:56 Marc Mutz wrote: > > Something like this should work just as well on QVector, right? If you > > are doing multiple inserts, perhaps you should keep the inserts outside > > the main vector while you make them, and only at the end do a single > > std::merge. > > Boom. Enter quadratic behaviour. > > There is Loki::AssociativeVector, but things like the above is why no-one > is using it. You only gain if you don't contantly maintain the is_sorted > invariant. To make my statement more precise: As soon as you provide insert_sorted, the same people who now use QSet + toList + sort() will invariably use it in a loop. Using a plain vector *is* fine. One just need to get over the fact that this is not Python and one has to use std algorithms and function objects. It's not the syntax that's a problem. It's the semantics that need to be understood. In this case, *both* algorithmic complexity *and* the cost of non- locality of reference (which is why QMap is so bad). -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
