Re: [Development] Raising the minimum to C++20

be ruled out of the equation. With the key to sometimes more readable code and a certain gain in productivity. Philippe -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

> This is a common problem with wikis. Lightning Talk: Wikis Are Bad - Roger Orr - ACCU 2023 https://youtu.be/WKpB4gUS9fM?si=XHb1nBMWyZOJgjJG -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] Raising the minimum to C++20

>> header Not yet available with Apple CLang (I did not test today, but a fews ago). Philippe On Tue, 02 May 2023 17:39:01 -0700 Thiago Macieira wrote: > C++23 is on the way, so maybe it's time for us to raise our minimum to the > one > version before that. Let's aim for

Re: [Development] How qAsConst and qExchange lead to qNN

ch API and ease of use. This has to be respected. Philippe > On 15.11.22 08:14, Ulf Hermann via Development wrote: > >>> So, if the method immediately converts whatever it gets to QList or > >>> QString, then there is no point in passing it

Re: [Development] How qAsConst and qExchange lead to qNN

> Volker Hilsheimer via Development wrote: nice pragmatic overview :) Philippe On Wed, 9 Nov 2022 09:15:16 + Volker Hilsheimer via Development wrote: > Hi, > > > On 8 Nov 2022, at 22:20, Marc Mutz via Development > > wrote: > > To summarize: > > -

Re: [Development] QPushButton: drag and drop

o solution. And without a good excuse to give to these users... Philippe On Fri, 3 Jun 2022 13:20:31 +0100 Laszlo Papp wrote: Hi, > > > It seems that QWidget::mouseReleaseEvent does not get triggered after > QDrag::exec. This causes the following issue that the QPushButton instance > ge

Re: [Development] Proposing to officially allow C++20 types in Qt 6 ABIs

foremost among them are coroutines Note that on OSX / Clang, coroutines is still in wrote: Hi, > > > C++20 brings several new library features that would be great to use in the > Qt API, foremost among them are coroutines and std::span. > > > > Yet, both of these are, in a sense,

Re: [Development] Qt Compilation Speed

tching to C++20 (but not using ranges). I am using PCH, which has always been a big winner, at least with MSVC. Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] Windows Timer Resolution: The Great Rule Change

don't get signaled during that period). Philippe On Thu, 8 Oct 2020 14:02:49 -0700 Thiago Macieira wrote: > On Thursday, 8 October 2020 01:43:38 PDT Philippe wrote: > > On Wed, 7 Oct 2020 17:34:43 -0700 > > > > Thiago Macieira wrote: > > > Now, the question is h

Re: [Development] Windows Timer Resolution: The Great Rule Change

yes, both WaitForSingleObject and WaitForMultipleObjects wait at least 15 milliseconds when the events are not signaled :( Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

[Development] Windows Timer Resolution: The Great Rule Change

PIs with a timeout (?) https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] qsizetype and classes working with QStrings or QList

, then I can agree. But if you mean there is no usage need, I disagree. Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] qsizetype and classes working with QStrings or QList

re than 2 billions audio samples (long recordings). I had the wish to display to the user the level of individual audio samples, for analysis purposes. Philippe On Mon, 24 Aug 2020 22:49:42 -0700 Thiago Macieira wrote: > On Monday, 24 August 2020 22:24:52 PDT Philippe wrote: > > > Do we

Re: [Development] qsizetype and classes working with QStrings or QList

need to make QAbstractSlider be able to handle 64 bit quantities too. Philippe On Mon, 24 Aug 2020 16:09:57 -0700 Thiago Macieira wrote: > On Monday, 24 August 2020 15:10:24 PDT ?? wrote: > > It would be nice if QAbstractItemModel will support qsizetype instead of > &g

Re: [Development] QAnyStringView

ly/readable than QUtf16StringView Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] [Interest] Windows 7 support will be dropped in Qt 6

. Philippe On Thu, 11 Jun 2020 14:41:34 +0200 Oliver Wolff wrote: > Hi, > > with Qt 6 approaching it is time to have a look at our set of supported > platforms. > > One candidate for removal of support was Windows 7. Some considerations > about dropping this support have been

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

rating system * some databases * principle behind any immutable data structure Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

Almost all the time I second your positions, but not this time ;) QList is historically a cause of ambiguity, and Qt6 is the chance to get rid of that. Philippe On Thu, 23 Apr 2020 07:53:04 + Lars Knoll wrote: I’ve had similar thoughts lately as well. I can see a few more reasons to keep

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

; This notation is so intuitive that I often forget to write "emit" before the call. Philippe On Wed, 26 Feb 2020 12:30:09 + Lars Knoll wrote: > > > > On 26 Feb 2020, at 10:38, Alex Blasche wrote: > > > > > > > >> -Original Message- &g

Re: [Development] QHash for Qt 6

mportance of map performance topic: https://youtu.be/ncHmEUmJZf4?t=209 Philippe On Fri, 20 Dec 2019 11:47:55 +0100 Giuseppe D'Angelo via Development wrote: > Il 20/12/19 09:23, Lars Knoll ha scritto: > > The result was that QHash has clear weaknesses compared to other > > imp

Re: [Development] QHash for Qt 6

the fact that maps are used in so many places, this would be a major addtion to Qt6 Though this is not the same thing, your optimized memory layout design recalls me the recent ordered map implementation of abseil https://abseil.io/blog/20190812-btree Philippe On Fri, 20 Dec 2019 08:23:34 +

Re: [Development] The age-old T* foo vs. T *foo

For sure, one very rarely sees T *foo in C++ projects. Not without a reason. Philippe On Thu, 17 Oct 2019 21:04:36 +0300 Ville Voutilainen wrote: > Since we are about to do a major version upgrade, should be stop being > a special snowflake in the C++ world and start attaching pointer

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

. Philippe On Fri, 23 Aug 2019 10:31:20 +0200 "Mutz, Marc via Development" wrote: > On 2019-05-29 12:53, Mutz, Marc via Development wrote: > > === QWaitCondition -> std::condition_variable(_any) === > > > > Plumbing that std::condition_variable can do better. >

Re: [Development] HEADS-UP: QStringLiteral

> There's no mutex. On Visual Studio 2017 15.8.8, there is a mutex on the 1st call (checked today when step tracing the assembly code). Again, for block scope, that is: void foo() { QString s = QStringLiteral("abc"); ... } Philippe On Tue, 20 Aug 2019 14:11:59

Re: [Development] HEADS-UP: QStringLiteral

another Drawback : it causes a global mutex to be executed on first use inside a block scope (c++11 static variable thread safety). Philippe On Tue, 20 Aug 2019 12:04:12 +0200 "Mutz, Marc via Development" wrote: > Hi, > > In light of a recent attempt to re-introduce QStri

Re: [Development] atomic reference counting implementation

>>Hence, why can't we just add new QAtomicInteger::refRelaxed and >> QAtomicInteger::derefRelaxed Not 'derefRelaxed', but 'derefOrdered' Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.

Re: [Development] QIntrusiveSharedPointer

Interesting and subtle indeed. This also relates to constant-ness AFAIU... When a method is non-const, then we can assume the object can't be concurrently accessed. Therefore we can assume the state can't pass from detached to shared while the method is executed. Philippe On Thu, 8 Aug 2019

Re: [Development] atomic reference counting implementation

is not used in QSharedData (QSharedData uses a "QAtomicInt ref") All implicitly shared class should rely on a single optimized QtPrivate::RefCount on the line of https://codereview.qt-project.org/c/qt/qtbase/+/66118 Philippe On Wed, 7 Aug 2019 22:26:11 +0200 Giuseppe D'Angelo via Develo

Re: [Development] QIntrusiveSharedPointer

on the same > object. Mutators must get exclusive access. Absolutly right, but a method "isDetached()" which is const has no usefulness on its own, independently from a detach() procedure. This is the purpose of my orginal remark. Philippe On Thu, 08 Aug 2019 12:00:11 +0300 &q

Re: [Development] QIntrusiveSharedPointer

are safe to be called concurrently (any method that does not implicitly call detach()). Therefore, qIntrusiveDetached() which is const, would be an exception that needs outside synchronization to get a reliable result. Philippe On Thu, 08 Aug 2019 10:46:17 +0200 Allan Sandfeld Jensen wrote: > On

Re: [Development] QIntrusiveSharedPointer

Yet, what is the usefullness of qIntrusiveDetached()? Because the result depends on a relaxed load, hence the moment after qIntrusiveDetached() was evaluated, rechecking qIntrusiveDetached() could give a different result. Philippe On Thu, 08 Aug 2019 11:09:57 +0300 "Mutz, Marc via Develo

Re: [Development] QIntrusiveSharedPointer (was: Re: atomic reference counting implementation)

Looks good, except that your proposed qIntrusiveDetached() has (apparently) the same "uncertainty" that caused shared_ptr::unique() to be deprecated. https://en.cppreference.com/w/cpp/memory/shared_ptr/unique Philippe On Wed, 07 Aug 2019 23:09:54 +0300 "Mutz, Marc via Deve

Re: [Development] atomic reference counting implementation

This is a perfect example of why I believe that to >> be fundamentally true. +1 Philippe On Wed, 07 Aug 2019 21:00:30 +0300 "Mutz, Marc" wrote: > Hi Philippe, > > This was discussed in https://codereview.qt-project.org/c/qt/qtbase/+/66118. > See, in

[Development] atomic reference counting implementation

, and atomic operations are a bit expensive). Is there a requirement at some stage that the reference counter must be ordered for increments? Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo

Re: [Development] How to port from Q_FOREACH to range-based for

student should be aware of :) https://en.wikipedia.org/wiki/Copy-on-write Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] Views

than 'std::vector + std::lower_bound' etc. simply because QDictionnary would be more of an abstraction. Philippe On Thu, 06 Jun 2019 09:05:31 +0200 "Mutz, Marc via Development" wrote: > On 2019-06-06 08:24, Joerg Bornemann wrote: > > On 6/5/19 5:49 PM, Mutz, Marc vi

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

ty rather than design flaw. Several of your proposals are about removing some "very-Qt" classes, to replace them by std classes. On the contrary, I believe these Qt classes, when they have no flaw, should better continue to be improved compared to std. Philippe __

Re: [Development] Deprecation/removal model going into Qt 6

difficult to use API for those 95% of the code. And I wish to add: the vast majority of Qt developers I have met, are not C++ wizards. Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

For Windows, I am sure QMutex wins (with Visual Studio 2017). Not only I got much better figures, but tracing the assembly code of QMutex vs std::mutex shows you why QMutex is better. Easy to check. In release mode of course. Philippe On Wed, 29 May 2019 20:12:05 +0200 Mikhail Svetkin wrote

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

>I think we could get rid of QThread and get along with std::thread and >std::thread::id QThread being a QObject, lot of user code depends on that. And that's a good dependency IMHO. I don't see any interest of getting rid of QThread, on the contrary. Ph

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

uggest using boost to replace some Qt parts, -10... Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

almost twice as fast than std::mutex. This is much appreciated for performing code. >== QSet / QHash -> std::unordered_set/map == >== QMap -> std::map == No. Many find these Qt classes easier to use. Philippe On Wed, 29 May 2019 12:53:35 +0200 "Mutz, Marc via Development"

Re: [Development] QList for Qt 6

> People tend to use QList as a deque because of the fast prepend/take first Simply, QArrayList should not be deprecated. It is also useful to store large objects that needs to be sorted. Philippe On Wed, 22 May 2019 18:25:18 +0200 ?? wrote: > 4. Use QVector to implement

Re: [Development] Views

ace, not a same implementation, according to the compiler's supplied library. Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] Views

seil/abseil-cpp/blob/master/absl/container/inlined_vector.h > There is no readability difference between the use of a Qt container > and that of an STL container. I have a different opinion of this. And this is what I mean when I say that Qt con

Re: [Development] Views

oes not (correct me if I am wrong): QVarLengthArray (even if, here again, they are faster implementations when one (rarely) need move semantics support). Philippe On Fri, 17 May 2019 07:47:55 +0200 "Mutz, Marc via Development" wrote: > On 2019-05-16 23:41, Konstantin Shegunov wrote

Re: [Development] Coding style for lambdas with empty parameter list

I like the shorter form, but keep in mind that when the return type needs to be specified, [] ->foo { // lambda content } is not possible, and following is needed: []() -> foo { // lambda content } Philippe On Wed, 9 Jan 2019 19:08:46 +0100 "André Hartmann" wrote: > Hi a

Re: [Development] QList for Qt 6 (was: Re: Build system for Qt 6)

that are not implicit-shared classes. Ok anyway. But keeping the old QList under a new name, cannot harm. Much of Qt was built with QList, so QList can't be that bad ;) Philippe On Fri, 2 Nov 2018 07:51:22 + Lars Knoll wrote: Renaming the subthread (it’s got nothing to do with build systems

Re: [Development] QtConcurrent replacement candidate

> and also sometimes > using the private-ish QFutureInterface to be able to use QFuture to > its full extent, which makes us feel a little dirty :) Good not to feel alone :) Philippe On Thu, 1 Nov 2018 10:42:36 +0100 Elvis Stansvik wrote: > There were some discussions last yea

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

> C++17 required (and I didn't know this specific syntax worked). AFAIR, this is in fact a C++20 proposal. Hence best is: for (auto : std::as_const(container)) Philippe On Wed, 31 Oct 2018 08:30:28 -0700 Thiago Macieira wrote: > On Wednesday, 31 October 2018 03:35:32 PDT Giuseppe D'

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

Good post, but: >> * if you have a container and you want to do non-mutating iteration, use >> for (const auto = container; const auto : c) This is enough: for (auto : std::as_const(container)) and for the rvalue reference case: for (const auto = container; auto : c) Phil

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

> For this kind of work I'd recoment QNanoPainter, it's another Qt paint engine > built on top of modern openGL, > very efficient for what you want (polylines) : > https://github.com/QUItCoding/qnanopainter Interesting, the demo works out of the box and is impressiv

Re: [Development] override keyword on destructors

tand code. Philippe On Mon, 20 Aug 2018 13:08:36 +0100 Sérgio Martins via Development wrote: > Hi, > > > Looks like some 'override' keywords crept into a few destructors. This > is probably because clang-tidy warns about it (and now QtCreator). > > IMO we should avoi

Re: [Development] clang-format

s would defeat any productivity goal. Philippe On Tue, 3 Jul 2018 10:13:06 + Tor Arne Vestbø wrote: > > > > On 3 Jul 2018, at 10:26, Lars Knoll wrote: > > > >> On 2 Jul 2018, at 16:52, Tor Arne Vestbø wrote: > >> > >> > >> > &g

Re: [Development] clang-format

> It doesn't help me all that much to have > familiar formatting and naming in a translation > unit This is a good skill. But the idea is to help developers that don't have this skill. Philippe On Fri, 22 Jun 2018 19:47:14 +0300 Ville Voutilainen wrote: > On 22 June 2018 at 19:39,

Re: [Development] clang-format

ductivity, hence benefits to customers at the end. Not having to take care of code-formatting, thanks to clang-format, eases programming. And looking at someone else code with a familiar format, gives the feeling "I am home" (provided some naming guideline is respected). Philippe On Fr

Re: [Development] clang-format

ator, but clang-format does it as you describe for QtCreator. And this works very nicely (...most of the time). Now, I don't remember which one of the many settings is responsible for this. Philippe On Wed, 20 Jun 2018 15:08:29 +0200 Allan Sandfeld Jensen wrote: > On Mittwoch, 20. Juni 2018

Re: [Development] clang-format

> For the above reasons I'd lean towards not running it globally and just using > it > on new changes. +1, based on my clang-format experience on a big application. BTW, keep in mind that you can disable clang-format on code sections with: // clang-format off // clang-format on

Re: [Development] QSharedPointer specialization

n was: I need to have shared ownership on QObject derived objects, and there is already built-in support in QObject for this. But thanks for your answer, I can do with the existing. Philippe ___ Development mailing list Development@qt-project.org http://

[Development] QSharedPointer specialization

, is a QSharedPointer specialization feasible? Philippe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Fornux C++ Superset

>> memory leaks are the most difficult problems to solve Really NOT ! Philippe On Wed, 25 Apr 2018 08:02:54 -0400 Phil Bouchard <philipp...@gmail.com> wrote: > On 04/25/2018 04:46 AM, Edward Welbourne wrote: > > Phil Bouchard (24 April 2018 19:05) > >> I’m n

Re: [Development] Setters: Clarifying the ownership

+20 years ago, the (good) Taligent crossplatform project, in its guideline, proposed: adopt() aka "take ownership" orphan() aka "release ownership" Philippe On Fri, 19 Jan 2018 16:09:21 + Jaroslaw Kobus <jaroslaw.ko...@qt.io> wrote: > "give" may b

Re: [Development] QtCS 2017 QtCore sessions

ter to deal with one implementation than many. When a bug only happens on one platform, and you ship a cross-platform application, this it not cool! Philippe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS 2017 QtCore sessions

to be used for an interface with another library, then let's use is. No big deal. Philippe On Sat, 02 Dec 2017 17:48:19 +0100 Marc Mutz <marc.m...@kdab.com> wrote: > On 2017-12-01 23:12, Philippe wrote: > >>> it's existential for Qt to get off its own container classes. > >

Re: [Development] QtCS 2017 QtCore sessions

of use / intuitive api, is of primary importance... std does not always shine here. Philippe On Fri, 01 Dec 2017 20:57:33 +0100 Marc Mutz <marc.m...@kdab.com> wrote: > On 2017-12-01 19:26, Thiago Macieira wrote: > > On Friday, 1 December 2017 01:31:18 PST Marc Mutz

Re: [Development] QtCS 2017 QtCore sessions

), it is clearly stated that it's generally a mistake to use unsigned... Check these extracts! https://www.youtube.com/watch?v=Puio5dly9N8#t=12m12s https://www.youtube.com/watch?v=Puio5dly9N8#t=42m40s https://www.youtube.com/watch?v=Puio5dly9N8#t=1h2m50s Philippe On Wed, 01 Nov 2017 18:25:01

Re: [Development] QtCS 2017 QtCore sessions

atch?v=nZNd5FjSquk https://www.youtube.com/watch?v=CFzuFNSpycI=8s Personnaly (and with a long experience with custom memory allocation), I am convinced about this new C+++17 approach. Philippe On Wed, 01 Nov 2017 15:32:23 +0300 Konstantin Tokarev <annu...@yandex.ru> wrote: > > > 01.11.2

Re: [Development] QtCS 2017 QtCore sessions

. Philippe On Wed, 1 Nov 2017 15:23:04 +0300 ?? <abba...@gmail.com> wrote: Sorry for digging the thread, but how is > * use qssize_t > and > ** Wrapping std::{unordered_}map may be acceptable > combines? > > std::*map uses size_t in it's API (size, max_size,

Re: [Development] Dropping of MSVC 2013

> We were. I'm asking for a quicker decision now, to decide whether I need to > invest time making QRandomGenerator deterministic mode work on MSVC 2013. Did you consider having a policy such as "Feature X is only available for compilers that suports Y" ? (to use sparingly, of c

Re: [Development] Future of QBS

's only fair for the people involved to > acknowledge that qbs is the most likely contender. +1 Philippe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

Maybe even deprecate startTimer and killTimer? -1 I like this low level insight, which gives me a higher sense of control about what's going on. Philippe On Wed, 30 Aug 2017 08:06:35 + Lars Knoll <lars.kn...@qt.io> wrote: >> On 30 Aug 2017, at 09:30, Olivier Goffart <ol

Re: [Development] Let's please drop MSVC 2013 for 5.10

use with their old favorite compiler. Philippe On Sat, 17 Jun 2017 11:14:18 +0200 André Pönitz <apoen...@t-online.de> wrote: > On Fri, Jun 16, 2017 at 07:09:20PM -0700, Thiago Macieira wrote: > > On Friday, 16 June 2017 16:35:54 PDT André Pönitz wrote: > > > On Fri, Jun 16

Re: [Development] QList

On Fri, 31 Mar 2017 11:12:44 +0300 Konstantin Tokarev <annu...@yandex.ru> wrote: > 30.03.2017, 17:33, "Matthew Woehlke" <mwoehlke.fl...@gmail.com>: > > On 2017-03-29 18:33, Konstantin Tokarev wrote: > >>  30.03.2017, 00:17, "Philippe" <philw.

Re: [Development] QList

tor+=(const QVector ) Not to mention the many other convenient QVector methods. And being able to use a QVector with O(1) by-value assigment, thanks to COW, make it easy to use QVectors "as primitive types", with no reasonning effo

Re: [Development] QList

xperience is simple: unless performance is the priority (5% of the cases?), the convenience of Qt COW containers outclasses the "convenience" of STL containers. Value-semantics is optimally implemented with implicitly shared containers. And IMH

Re: [Development] QList

lt;std::unique_ptr<.>> When you need an index-based container, to insert and sort many big objects, a QList like container is ideal. Easier than std::vector<std::unique_ptr<.>> and with the benefit of cow. Philippe ___ Development maili

Re: [Development] QList

on is "implemented as a QVector" Hence from the OO common dialect, QPolygon is-a QVector Philippe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

ation if you use the QPointF version with the raster engine. Nor QPainterPath created with the raster engine. Philippe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

> Il 25/03/2017 23:23, Philippe ha scritto: > > Indeed, as a user of QPolygon, I do see and handle a QPolygon as a > > vector of points... > > None of these properties strictly depend on the fact that a QPolygon > _is-a_ QVector. > For sure, but where is the problem

Re: [Development] QList

On Thu, 23 Mar 2017 14:22:36 -0700 Thiago Macieira wrote: > > > > return qFindChar(*this, ch, from, cs); > > > > or > > > > return qFindString(*this, QStringView(, 1), from, cs); > > > > where only the qFoo() functions are exported, but none of the > >

Re: [Development] RFC: Containers member functions for algorithm

I realize that QtCreator already has helper functions: >>https://code.woboq.org/qt5/qt-creator/src/libs/utils/algorithm.h.html Similar convenience wrappers are found in many applications... It would not harm to have such wrappers in Qt. Philippe On Thu, 23 Mar 2017 08:32:14 +0100 Olivie

Re: [Development] QList

by user, I meant "application programmer using Qt" :) Philippe On Wed, 22 Mar 2017 13:08:19 +0200 Ville Voutilainen <ville.voutilai...@gmail.com> wrote: > On 22 March 2017 at 13:03, Philippe <philw...@gmail.com> wrote: > > Externalizing sharing brings more flexi

Re: [Development] QList

Externalizing sharing brings more flexibility indeed, but at the price of more complexity on the user side, ie. less convenience... Philippe On Wed, 22 Mar 2017 11:22:37 +0100 Marc Mutz <marc.m...@kdab.com> wrote: > On 2017-03-22 10:36, Edward Welbourne wrote: > > On Wednesday 2

Re: [Development] QList

that convenience. Philippe > > And when size matters, have this in mind: > > > > sizeof(std::vector) == 32 > > sizeof(QVector) == 8 > > sizeof(QList) == 8 > > To provide a more helpful response than Marc's: I assume that you are > aware that the Qt types

Re: [Development] QList

in mind: sizeof(std::vector) == 32 sizeof(QVector) == 8 sizeof(QList) == 8 (VC++ 64bit) Philippe On Mon, 20 Mar 2017 09:09:57 +0100 Marc Mutz <marc.m...@kdab.com> wrote: > On Sunday 19 March 2017 19:48:36 Thiago Macieira wrote: > > On sábado, 18 de março de 2017 15:32:55 PDT Marc Mu

Re: [Development] QList

s that raw performance should now prime over developer convenience? Philippe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

>> For me, the performance issue is pretty strong QVector is not always the best solution here. With QList, insertion and sorting will be faster for containers of large objects, as there is less memory to move around. QList is not to put to the trash. Philippe On Sat, 18 Mar 2017 10

Re: [Development] QMacCocoaViewContainer changes?

+ Qt sides), causing a crash in OSX code. Simply not releasing the NSView on the client side, is enough (apparently so far), to solve the problem. I did not report a bug, because this looks more like a behavior change (not documented), than a bug. Philippe On Thu, 16 Feb 2017 23:21:52 +0100 René

Re: [Development] Feature Freeze Exception: QStringView

On Thu, 02 Feb 2017 23:52:26 +0100 Kevin Kofler <kevin.kof...@chello.at> wrote: > > On Tuesday 31 January 2017 15:24:18 Philippe wrote: > >> I just want to highlight, that QStringView is not COW friendly. AFAIK. > > That alone makes it actually a pessimization. T

Re: [Development] Feature Freeze Exception: QStringView

friendly. AFAIK. Philippe On Tue, 31 Jan 2017 14:09:06 + Sergio Martins <sergio.mart...@kdab.com> wrote: > On 2017-01-31 12:50, Philippe wrote: > > As far as I understand, I see a performance regression with > > QStringView, for all the cases where copy-on-write can't take

Re: [Development] Feature Freeze Exception: QStringView

ingView sv) { QString str(sv);// malloc needed } void foo2(const QString& s) { QString str(s); // faster because of COW } Philippe On Mon, 30 Jan 2017 20:03:24 +0100 Marc Mutz <marc.m...@kdab.com> wrote: > Hi, > > QStringView is ready to be merged, but the mai

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

ers expects, at least. Philippe On Mon, 21 Nov 2016 09:04:59 +0100 Marc Mutz <marc.m...@kdab.com> wrote: > On Sunday 20 November 2016 23:20:11 Philippe wrote: > > On Sun, 20 Nov 2016 19:49:09 +0100 > > > > Marc Mutz <marc.m...@kdab.com> wrote: > > > I

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

her logic, and insertion/emplacement perform fewer element operations. (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes) >>>> Being the "standard library" does not mean "bug free and equal on all platforms". Dependencies

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

ver > > different behaviors of it on different platforms and compilers that I have > > a real hate on the STL. > > I am glad that I am not alone with that feeling. +1 Philippe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

[Development] std::atomic

std::atomic is used as underlying implementation for the the Qt atomic API with CLang on Mac. But why not with Visual Studio 2015? You will certainly mention some bug, but then where is the problem? (shortly) Thanks Philippe ___ Development mailing

Re: [Development] On deprecated APIs

This is a debate convenience vs performance; * Q_FOREACH will never detach, hence it is convenient. * A for-loop can be (a very little more) optimized, as long as you work on const containers or use qAsCont (and many will forget about that... which is *not* convenient) Philippe On Wed, 31 Aug

Re: [Development] Use of Standard Library containers in Qt source code

>>Actually, I disagree with that. As someone who has come to appreciate >>STL after growing up in the Qt world, Exact opposite here: I learned STL from its early days, and could never become at ease with its namings... and I started to breath with Qt containers

Re: [Development] Use of Standard Library containers in Qt source code

quot;getting used to". Option 3 has my vote. Philippe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.8 branching & Feature Freeze - Qt Speech TTS

+1 Philippe On Thu, 16 Jun 2016 12:22:02 +0200 Frederik Gladhorn <frederik.gladh...@qt.io> wrote: > On onsdag 15. juni 2016 07.15.16 CEST Tuukka Turunen wrote: > > Hi, > > > > I would also like to have all new modules (if any) of Qt 5.8 as well as > >

Re: [Development] commas in ctor-init-lists

but now I would not change. Philippe On Wed, 1 Jun 2016 16:10:34 -0700 Mandeep Sandhu <mandeepsandhu@gmail.com> wrote: > The leading comma's are also helpful if we have some part of the > initializer list protected by a preprocessor conditional (or might be > needed in the

  1   2   >