Re: [Development] QList
Hi Thiago,
You misunderstand me.
I listed _the_ three use-cases where inheritance is the tool of choice:
1. modelling is-a
2. inheriting to reuse
3. reimplementing virtual functions
If your use-case is not one of the three, then inheritance is not the right
tool.
Clearly, by now, it's neither (1) nor (3). So if anything, it needs to be (2).
And I'm arguing that it's not (2), either, because you can only re-use a
subset of QStringView API, and need to wrap the other half anyway. (2) is
really only interesting for pure OO languages with no concept of free
functions. In C++, we have free functions.
On Thursday 23 March 2017 22:22:36 Thiago Macieira wrote:
> > > A naïve implementation of QString::mid() could be:
> > >
> > >
> > > QString QString::mid(int start, int len) const
> > > {
> > > return QString(QStringView::mid(start, len));
> > > }
> >
> > Which is no different from
> >
> >return QString(QStringView(*this).mid(start, len));
> >
> >
> > so does not provide a case supporting using inhertance.
>
> Actually, the code generation could be slightly different. If
> QStringView::mid() isn't inlined, then the difference is whether we need
> to create a temporary QStringView in the stack and pass its this pointer
> as a parameter.
If QStringView::mid() isn't inline, then it doesn't matter which
implementation we choose. The implicit this in QStringView::mid is still
there, forcing the object on the stack.
So what I take away from this discussion is "avoid having to go though *this
(into out-of-line code)". And to avoid having to go through *this, you need
free functions, not member functions of some private base class.
And this is what I intend to do: QStringView::mid is inline. And I'm proposing
to make all QString/View member functions inline non-exported, either
implemented directly or by calling a free function (exported or not).
As an aside: going through *this has obviously so far not been an issue with
QString's myriads of member functions, so I guess even on Win64 calling
performance will increase with QStringView taken by value.
Ville: are there any proposals for making *this passable by value? Like
struct QLineF {
Q_CORE_EXPORT QPointF intersection(QLineF other) =;
// =: pass *this by value, mimicking & and && for (l|r)value ref
};
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
On 24 March 2017 at 10:34, Marc Mutz wrote:
> Ville: are there any proposals for making *this passable by value? Like
>
>struct QLineF {
>Q_CORE_EXPORT QPointF intersection(QLineF other) =;
> // =: pass *this by value, mimicking & and && for (l|r)value ref
>};
No, I have never seen such an idea being suggested before this discussion.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
Earlier, Thiago said: >>> The point however is that if libstdc++ does break its ABI, then >>> you'll have to rebuild half the world anyway. The few libraries and >>> applications that did use Qt and were not affected would be the >>> minority. Telling them apart could be a higher cost than just >>> rebuilding -- remember, ALL C++ code links to libstdc++, regardless >>> of whether it was subject to the ABI break or not. >>> >>> And if libstdc++ changes its soname, then you HAVE to rebuild Qt and >>> everything, anyway. On quinta-feira, 23 de março de 2017 12:13:09 PDT Lisandro Damián Nicanor Pérez Meyer wrote: >> Right, but without a proper SONAME change we can not track what needs >> to get rebuilt and what doesn't (because it already was), what can >> migrate from unstable to testing, what binary is compatible with >> another and so on. Let me just check I've understood this one correctly: you need the SONAME change as soon as we introduce any stl type in our API because, regardless of it being new API, during the lifetime of that version of Qt, there may be changes to the stl ABI, that would break Qt. So the existing Qt SONAME needs to express the stl ABI version so that, after the update, things built before pick up the old Qt while things built after pick up the new. Did I understand that correctly ? I'm a little unclear on why that can't be changed with the first stl ABI break; but I guess having Qt's build infrastructure (which hasn't changed) express the stl ABI version (which has) in its SONAME would mean you *only* have to rebuild, without also hacking Qt's build infrastructure to modify the SONAME - which is why different distros would end up with different SONAMEs, because each hacks that its own way. So, once Qt contains any stl in its ABI, it would be courteous to distros to incorporate the stl ABI version in the Qt SONAME, so that any stl ABI break requires *only* a recompile of Qt and any other packages directly affected by the stl ABI break, rather than propagating to all packages. I'm a little unclear on why that won't still be all packages; can you elaborate ? Thiago Macieira (23 March 2017 20:50) > Understood, but that's not Qt's problem. If libc or libstdc++ cause a > BC break, it's their responsibility to update the SONAME. If they > don't, you (Debian) get to complain to them. If my guess above is near the mark, an update to stl's SONAME won't help us here. Qt's SONAME would also need to change when stl's ABI breaks. > Either way, the benefit of keeping Qt immune to those breaks is so > small to the point that it's not worth it. As long as stl ABI breaks are rare, yes. The tricky part is that everyone makes mistakes ... >>> > Oh, and if some non-other Qt api is exposed it should also become >>> > part of the SONAME. >>> >>> Again, why? We've exposed C and Xlib API for years and have never >>> had "X11" in the name (or "xcb" now). My understanding was that the only exposure we give to that is passing an opaque handle through, from the library to our client. As long as the client is only ever using it to pass back to the same library, without looking inside the black box - and as long as the opaque type hasn't changed (void* was the example ISTR) - this isn't really an ABI dependency. The issue would arise if we, or the client, were to look inside that opaque type, possibly by calling some inline of the library; but I doubt this happens for the types involved. They come from the X or xcb library and travel back to it; any given run-time process only deals with one version of that library, so all's well. That would even imply a need to link Qt against the library, of course; so I suspect my understanding is incomplete ... how *are* we using X/xcb types ? >> Maybe because they never broke? At least in the time I've been >> maintaining Qt in Debian we have never encountered an issue with >> this. This is from the last Qt 4 releases before Qt5. > > Right and that's the entire point: there are some libraries (a > whitelist) whose types we'll have in our public ABI, so Qt's ABI is > then dependent on theirs. We'll only add libraries that have a good > track record of keeping BC. Surely Qt's API can use any library-derived type that's opaque (void*, most obviously, via whatever typedefs), as long as the library has no inlines that unwrap it. That means the client's only possible use of it is to pass it back to the same library we got it from, with no risk of incompatibility. Eddy (not an expert on shared libraries). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QMenu::addSection() across platforms
Hi,
I continue to find it strange that Qt would introduce a convenience method to
add labelled sections to menus if that feature isn't available on all
platforms. I understand there are limitations to what native menus in native
menubars can show but not the step from that fact to an official attitude "just
don't use QMenu::addSection on those platforms". Yet that's exactly how a bug
report I filed on this topic was closed (a while back). I read that as "just
don't use QMenu::addSection in cross-platform code", which in practice
translates to "just don't use QMenu::addSection" - at all.
Is this still the official stance or has it been mellowed with time and insight
that organising menus with labelled sections can be useful in applications with
a rich (complex) GUI?
Again, I can understand that "texted separators" created with something like
`menu->addSeparator()->setText("this may be a section label")` don't have the
same appearance everywhere. A dedicated method `menu->addSection("This will be
a section")` suggests otherwise, though.
I've been playing around with the code after I discovered the existence of the
corresponding style hint and am testing a patch that attempts to provide a
reasonable rendition of a "texted separator":
if SH_Menu_SupportsSections is false, use the emulation
else:
if the menu belongs to a native menubar on Mac (or MS Windows?), use emulation
else texted separators should work just fine.
IOW, on Mac emulation is only necessary when using the native widget style or
else for menus attached to the native menubar.
Emulation is really quite simple: if the above check indicates it's required,
add an additional regular but deactivated QAction to the menu holding the
section text before adding the texted separator action. It would be nice if
there were a way to centre the text of the disabled menu item but the result is
close enough to a style that renders the section entry with underlined text. In
either case it's up to the application to use a section text label that doesn't
make the user think the menu entry should actually do something.
This emulation is done when the menu is constructed so the overhead associated
with determining if the menu belongs to a native menubar should be acceptable.
R.
PS: am I right that even the Macintosh style could actually support texted
separators in context menus and nonnative-menubar-menus?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug
Latest Qt 5.9.0 beta snapshot src tarballs here: http://download.qt.io/snapshots/qt/5.9/5.9.0-beta/1489997285/ (or directly from online installer) br, Jani From: Development on behalf of Ed Leaver Sent: Thursday, March 23, 2017 10:57 PM To: development@qt-project.org Subject: Re: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug On 03/23/2017 01:43 PM, Thiago Macieira wrote: On quinta-feira, 23 de março de 2017 10:59:25 PDT Ed Leaver wrote: will attempt gcc-4.8.2 -no-std=c++11 in the next few days. If you think this worthwhile, have you a Qt-5.9.0-beta source tarball? You can't turn C++11 off since 5.7.0. Thanks. Saved me some time and confusion. I didn't personally wish to turn off C++11 anyway. I'll try 5.7.0 then against gcc-4.8.2, but am still interested in a 5.9.0-beta source tarball to test with gcc-5.4.0 and later, if such beta tarball becomes available. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
Marc Mutz (23 March 2017 20:41) > Do I need to mention QPolygon and what pain it's inheritance from > QVector has caused? (FTR: cf. end of qvector.h and > qvector_msvc.cpp). well, I - for one - can only see a minor problem; so, since you *have* mentioned it, perhaps you could elaborate ? I hadn't realised QVector wasn't public - I can see how that would be an argument for the inheritance to be private. Is there more to the problem than that ? You make it sound a bigger deal than anything I can see in the source - so please educate me, Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QUIP-7: qt_attribution.json File Format
Hi, This is a heads-up that I've moved parts of QUIP-4 (Third-Party Components in Qt) a while ago into a separate Implementation QUIP. The details about the qt_attribution.json file format are now described in proposed QUIP-7: https://codereview.qt-project.org/#/c/147271/ Comments welcome, both for the document as well as the format itself :) Kai -- Kai Köhne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. 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] QUIP-7: qt_attribution.json File Format
> -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Kai Koehne > Sent: Friday, March 24, 2017 12:25 PM > To: development@qt-project.org > Subject: [Development] QUIP-7: qt_attribution.json File Format > > Hi, > > This is a heads-up that I've moved parts of QUIP-4 (Third-Party Components > in Qt) a while ago into a separate Implementation QUIP. The details about > the qt_attribution.json file format are now described in proposed QUIP-7: > > https://codereview.qt-project.org/#/c/147271/ Copy/paste error. Correct link is https://codereview.qt-project.org/#/c/185792/ Sorry about this Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
On Friday 24 March 2017 11:34:37 Edward Welbourne wrote: > Marc Mutz (23 March 2017 20:41) > > > Do I need to mention QPolygon and what pain it's inheritance from > > QVector has caused? (FTR: cf. end of qvector.h and > > qvector_msvc.cpp). > > well, I - for one - can only see a minor problem; so, since you *have* > mentioned it, perhaps you could elaborate ? I hadn't realised QVector > wasn't public - I can see how that would be an argument for the > inheritance to be private. Is there more to the problem than that ? > You make it sound a bigger deal than anything I can see in the source - > so please educate me, Well, where should I start? There are two principles that interact to cause all kinds of mayhem, both of them on Windows: 1. When a class is exported, all of its members are exported. That includes the base class' members, regsardless of whether they were exported themselves or not. 2. When an inline function is exported (by itself or via a class-level export), MSVC calls the copy in the DLL. I don't know whether it places a copy in the user's executable at all. You can prevent this behaviour by marking each such function with Q_ALWAYS_INLINE. (2) means we can't change signatures of exported inline functions, because that would be BiC on Windows/Debug. On all other platforms, incl. Windows/Release, renaming, removing, changing the signature of, an inline function, exported or not, is always BC. It may be SiC, but it's always BC. We have many use-cases that assume that inline functions do not form part of the ABI: a. QVector and other container change the signature of begin() etc to implement QT_STRICT_ITERATORS. As a consequence, QT_STRICT_ITERATORS fails for (at least) QXmlStreamAttributes, inheriting QVector, because only one of the two overloaded functions gets exported while the other one is not. You may disregard this as a container-only thing, but it's far more widespread: b. We also assume we can #if Q_COMPILER away functions as long as they are inline. You see where this is going? Once MS actually keeps BC themselves, and afaiu, they plan to do so for 2015 -> 2017, this will cause BiC in all exported classes whenever 2015 lacks a feature that 2017 provides. I don't know why Thiago thinks these reasons are not worth stopping exporting non-polymorphic classes for, but I'm absolutely convinced that exporting only non-inline functions in such classes is the only correct way to deal with the Microsoft platform. Non-polymophic classes should decide what they want to be: I. if they want to be pimpl'ed, they should have most functions out-of-line. In this case, it's ok to export the whole class, but all inline functions should have to be marked as Q_ALWAYS_INLINE from the outset. II. if they want to be thin abstractions, most functions should be inline. The class should not be exported, only out-of-line functions should be. To prevent inheriting such classes, thereby exporting their inline functions, such classes should be agressively marked as final. Polymophic classes should follow the rules of (I) (class-level exporting them is required here) plus have all their virtuals (incl. esp. their dtor) defined out-of-line. HTH, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
Em sexta-feira, 24 de março de 2017, às 01:34:18 PDT, Marc Mutz escreveu: > I listed _the_ three use-cases where inheritance is the tool of choice: > > 1. modelling is-a > 2. inheriting to reuse > 3. reimplementing virtual functions > > If your use-case is not one of the three, then inheritance is not the right > tool. > > Clearly, by now, it's neither (1) nor (3). So if anything, it needs to be > (2). > > And I'm arguing that it's not (2), either, because you can only re-use a > subset of QStringView API, and need to wrap the other half anyway. (2) is > really only interesting for pure OO languages with no concept of free > functions. In C++, we have free functions. Marc, philosophical question then: Are you of the opinion that private inheritance has no purpose and should never be used? -- 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] QList
Em sexta-feira, 24 de março de 2017, às 05:31:32 PDT, Marc Mutz escreveu: > Well, where should I start? There are two principles that interact to cause > all kinds of mayhem, both of them on Windows: > > 1. When a class is exported, all of its members are exported. That includes >the base class' members, regsardless of whether they were exported >themselves or not. > 2. When an inline function is exported (by itself or via a class-level >export), MSVC calls the copy in the DLL. I don't know whether it places a > copy in the user's executable at all. You can prevent this behaviour by > marking each such function with Q_ALWAYS_INLINE. Note: you may force a local copy with Q_ALWAYS_INLINE, but that does not stop the DLL from exporting the function in the first place. > (2) means we can't change signatures of exported inline functions, because > that would be BiC on Windows/Debug. On all other platforms, incl. > Windows/Release, renaming, removing, changing the signature of, an inline > function, exported or not, is always BC. It may be SiC, but it's always BC. That still has exceptions, like inlines that have statics inside or if the address of the inline is taken. So we should still apply regular our rules for BC to those inline functions, with the extra requirement that "it must be ok for old code to call the old version". So inlines are actually harder on BC than non-inlines... > We have many use-cases that assume that inline functions do not form part of > the ABI: > > a. QVector and other container change the signature of begin() etc to >implement QT_STRICT_ITERATORS. As a consequence, QT_STRICT_ITERATORS > fails for (at least) QXmlStreamAttributes, inheriting QVector, because only > one of the two overloaded functions gets exported while the other one is > not. > > You may disregard this as a container-only thing, but it's far more > widespread: > > b. We also assume we can #if Q_COMPILER away functions as long as they are >inline. You see where this is going? Once MS actually keeps BC > themselves, and afaiu, they plan to do so for 2015 -> 2017, this will cause > BiC in all exported classes whenever 2015 lacks a feature that 2017 > provides. > > I don't know why Thiago thinks these reasons are not worth stopping > exporting non-polymorphic classes for, but I'm absolutely convinced that > exporting only non-inline functions in such classes is the only correct way > to deal with the Microsoft platform. Because (1) was very restricted and (2) hadn't happened until now. You're probably right: all the constexpr (thus inline) functions in our exported classes are not present in the MSVC 2015 binaries. So if you compile against MSVC 2017, the compiler will expect them to be there and the link will fail. We need to verify this is the case. There's an easy way out: provide an MSVC 2017 binary, so people don't try to mix. We need to reevaluate what to do. I still think the export-each-function-in- the-class is mighty ugly and should be avoided. > Non-polymophic classes should decide what they want to be: > > I. if they want to be pimpl'ed, they should have most functions out-of-line. > In this case, it's ok to export the whole class, but all inline functions > should have to be marked as Q_ALWAYS_INLINE from the outset. I disagree with that on style purposes and in the causing of inlining when the compiler didn't really want it (even in release mode). But as I said above: need reevaluation. -- 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] QList
On Friday 24 March 2017 16:34:17 Thiago Macieira wrote: > Em sexta-feira, 24 de março de 2017, às 01:34:18 PDT, Marc Mutz escreveu: > > I listed _the_ three use-cases where inheritance is the tool of choice: > > > > 1. modelling is-a > > 2. inheriting to reuse > > 3. reimplementing virtual functions > > > > If your use-case is not one of the three, then inheritance is not the > > right tool. > > > > Clearly, by now, it's neither (1) nor (3). So if anything, it needs to be > > (2). > > > > And I'm arguing that it's not (2), either, because you can only re-use a > > subset of QStringView API, and need to wrap the other half anyway. (2) is > > really only interesting for pure OO languages with no concept of free > > functions. In C++, we have free functions. > > Marc, philosophical question then: > > Are you of the opinion that private inheritance has no purpose and should > never be used? No, and if you look at code I have written over the years, you will see that I do use it. One thing I've looked into in the past is this: Q6Polygon should inherit a Q6VectorBase that also Q6Vector inherits. This will allow easy specialisation of QVector by inheriting QBasicVector. I can even think of a similar pattern for QStringView/QLatin1(String| View)/QUtf8(String|View), though I guess that just enable_if'ing functions out of the primate template will do the job just fine, so the three classes would be mere typedefs of the template. But in these cases, we're reusing next to 100% of the functionality, by way of lots of using Base::foo; This is not the case for QString : QStringView. They're completely unrelated, because one if owning and the other is non- owning. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Containers member functions for algorithm
Is std::algo(std::begin(container), std::end(container) ... ) troublesome
enough that it warrants a wrapper ?
I have a few concerns:
* There is a large momentum behind the range proposal, and, if it wont
be in the standard before 2-4 years, I would expect the TS to be usable
long before that. For simple iterator abstractions like sort, find, etc,
range-v3 is certainly already pretty stable from an api standpoint.
* C++17 bring parallel version of some algorithms. I haven't look what
the requirements for a containers are to be compatible with those parallel
algorithms are, but I would prefer Qt to focus on that.
* I'm afraid it won't be a popular opinion, but I wouldn't mind seing
constBegin() / constEnd() deprecated, as they are redundant
Your last example is simplified by the Library Fundamentals TS
https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#container.erasure
erase_if(std::begin(myList), std::end(myList), [&](const auto &elem) {
elem.field > someValue; });
If we fast forward to say, 5 years in the future, people will be confused
as to whether use std2::sort or Qt::sort (and if Qt::sort do not relies on
concept, it won't be as trivial to use )
If there is an immediate urgent need, a solution would be to have an api
that matches as close as possible the range TS, so that the migration path
can be as simple as changing "Qt" by "std2"
Le jeu. 23 mars 2017 à 08:32, Olivier Goffart a écrit :
> Hi everyone,
>
> I have been wondering if we should enhance Qt container with member
> functions
> to help using some of the standard algorithm.
> a peace of code is better than many words. We would be able to do:
>
> myList.sort();
> //or
> myList.sort([](auto &a, auto &b){ return a.member < b.member; });
>
> if (myList.contains([&value](const auto &elem){ return elem.id == value;
> }))
>doSomething();
>
> myList.removeIf([&](const auto &elem) { elem.field > someValue; })
>
>
> And these are a tad more convenient than using the standard library
> directly.
> Compare to:
> myList.erase(std::remove_if(myList.begin(), myList.end(),
> [&](const auto &elem) { elem.field > someValue; }),
> myList.end());
>
> Of course, myList can be a QList, a QVector, or a QVarLenghtArray
>
> Here is an overview in how this could be implemented, should we want this:
> https://codereview.qt-project.org/#/c/189313/
>
>
> Anyway, before I continue working on this patch, I want to know if this is
> even something what the Qt Project wants.
>
> The reason we would want it are obvious: convenience.
>
> In the mean time, the standard is working on the so called range library.
> So
> in C++20, you could maybe just write std::sort(myList).
> But that's in the far future, and I want to be able to use it now.
> There are already convenient range libraries that makes things convenient
> available on github, but that's another dependency and the compatibility
> guarantee are not the same.
>
>
> The reason we would not want this is because this makes our containers too
> convenient. The implementation of QVector is inferior to the one of
> std::vector. (for example, it cannot contains move-only types).
> Right now, it is quite easy to replace QVector by std::vector. But adding
> nice
> feature to QVector may mean a reason to keep QVector longer in Qt6 instead
> of
> changing to standard containers.
>
> Marc already expressed his opinion on the gerrit change, pointing out that
> we
> deprecated qSort and the qt algorithm for a reason: the quality of the std
> algorithm was better than the naive implementation in Qt. However this is
> just
> a helper around the std algorithm implementation.
>
>
> Why did we not added these function already in Qt 4.0? I was not there
> yet,
> but I believe this might have been for technical reason: MSVC 6 was still
> supported until Qt 4.5, which mans no template member functions.
> Also sort needs an operator<, and non-template function might be
> instantiated
> even if not used.
>
> So with this mail I would like to know what you think. If you think this
> is a
> good idea or a terrible one.
>
>
> Once we agreed the general idea is good, we can go into the details of the
> API
> or implementation.
>
> On this WIP patch, I only took the algorithm that were most used within Qt
> and
> QtCreator. I realize that QtCreator already has helper functions:
> https://code.woboq.org/qt5/qt-creator/src/libs/utils/algorithm.h.html
> That's I think one proof that shows that this would be useful.
>
> I am wondering if findIf shoud return a pointer or an iterator.
> Returning a pointer allow things like
> if (auto *elem = myContainer.findIf([&](const auto &elem)
> { return elem.foo == bar; }))
> elem->plop = myPlop;
>
> But does not work well if you want to find-then-remove:
> auto it = std::find(myContainer.begin(), myContainer.end(),
> [&](const auto &elem) { return elem.foo == bar; });
Re: [Development] RFC: Containers member functions for algorithm
Michael Winkelmann wrote: > The reason why STL is using free function is because it separates data > structures (aka containers) and algorithms. > A bad example what happens if you dont separate can be seen here: > https://www.imagemagick.org/api/Magick++/Image_8h_source.html > > ...and your data structure will be bloated with member functions. Why is that bad? It is convenient and object-oriented. Moving everything to freestanding functions goes against the principles of OOP. That said, even freestanding functions would be better than the current boilerplate myContainer.begin(), myContainer.end() copypasta. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug
Ed Leaver wrote: > I'll try 5.7.0 then against gcc-4.8.2 5.7.0 is actually the first release that will NOT work without C++11. You will have to try 5.6.x instead. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
Em sexta-feira, 24 de março de 2017, às 09:18:05 PDT, Marc Mutz escreveu: > > Are you of the opinion that private inheritance has no purpose and should > > never be used? > > No, and if you look at code I have written over the years, you will see that > I do use it. > > One thing I've looked into in the past is this: Q6Polygon should inherit a > Q6VectorBase that also Q6Vector inherits. This will allow > easy specialisation of QVector by inheriting QBasicVector. Can you elaborate on your thinking? What's QBasicVector and what's QVector? In my tree, I have QVector deriving from QGenericArray only because at the time we were considering doing QList still be a pointer array if sizeof(T) > 32. > I can even think of a similar pattern for QStringView/QLatin1(String| > View)/QUtf8(String|View), though I guess that just enable_if'ing functions > out of the primate template will do the job just fine, so the three classes > would be mere typedefs of the template. > > But in these cases, we're reusing next to 100% of the functionality, by way > of lots of using Base::foo; This is not the case for QString : QStringView. > They're completely unrelated, because one if owning and the other is non- > owning. I still disagree. Yes, there's a difference in ownership, but I don't see that as a deal-breaker. In fact, I see that as a plus: that's why we derive, to add functionality, like owning. And like I said, every QString is a view to itself and the pure inspection functions like indexOf() and contains() are exactly the same. -- 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] RFC: Containers member functions for algorithm
On Fri, Mar 24, 2017 at 04:25:34PM +, Corentin wrote:
> Is std::algo(std::begin(container), std::end(container) ... ) troublesome
> enough that it warrants a wrapper ?
Yes.
1. It is more to read, and more to verify during reading, e.g.
that bother 'container' are the same.
This typically implies that 'container' is just a simple
identifier for a local variable (i.e. usuall an extra line for
a definition) or a member of the current object (rare).
Even seeing
std::algo(std::begin(foo), std::end(foo) ... )
*verbatim* with a plain 'foo' does not guarantee that both
'foo' refer to the same container, i.e. potentially needs
verification when bug hunting.
For
std::algo(std::begin(foo()), std::end(foo()) ... )
chances are high that it is wrong. Except when it isn't.
But for that you need to consult the declaration, and
even possibly the implementation of 'foo'.
2. It more to type.
std::algo(std::begin(container), std::end(container) ... )
vs
foo::algo(container, ... )
Depending on your project's coding style there are additional
complications, e.g. that the ~55 chars of the first are 'a lot'
in a 80 char-per-line setup.
> Your last example is simplified by the Library Fundamentals TS
> https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#container.erasure
> erase_if(std::begin(myList), std::end(myList), [&](const auto &elem) {
> elem.field > someValue; });
100 chars, vs 70 chars for a no-begin-end-cluttered
erase_if(myList, [&](const auto &elem) { elem.field > someValue; });
and some hope that it going from 'myList' to 'myList()' is really
just two chars change.
Not Nice (TM).
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Containers member functions for algorithm
On 25 March 2017 at 07:00, Kevin Kofler wrote: > Michael Winkelmann wrote: >> The reason why STL is using free function is because it separates data >> structures (aka containers) and algorithms. >> A bad example what happens if you dont separate can be seen here: >> https://www.imagemagick.org/api/Magick++/Image_8h_source.html >> >> ...and your data structure will be bloated with member functions. > > Why is that bad? It is convenient and object-oriented. Moving everything to > freestanding functions goes against the principles of OOP. "OO was hip in the 80s and 90s, but its time we moved beyond!". >From http://www.boost.org/doc/libs/1_63_0/libs/graph/doc/faq.html item 3, last paragraph. I'm not advocating for free functions, i really hate them. I have been working with boost graph recently and find this technique awful to write, awful to read and counter intuitive. I hope Qt won't become like boost. Chris > > That said, even freestanding functions would be better than the current > boilerplate myContainer.begin(), myContainer.end() copypasta. > > Kevin Kofler > > ___ > 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
