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

2017-03-24 Thread Ch'Gans
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: >>

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

2017-03-24 Thread André Pönitz
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

Re: [Development] QList

2017-03-24 Thread Thiago Macieira
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

Re: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug

2017-03-24 Thread Kevin Kofler
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

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

2017-03-24 Thread Kevin Kofler
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

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

2017-03-24 Thread Corentin
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.

Re: [Development] QList

2017-03-24 Thread Marc Mutz
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

Re: [Development] QList

2017-03-24 Thread Thiago Macieira
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

Re: [Development] QList

2017-03-24 Thread Marc Mutz
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;

Re: [Development] QUIP-7: qt_attribution.json File Format

2017-03-24 Thread Kai Koehne
> -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

[Development] QUIP-7: qt_attribution.json File Format

2017-03-24 Thread Kai Koehne
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,

Re: [Development] QList

2017-03-24 Thread Edward Welbourne
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

Re: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug

2017-03-24 Thread Jani Heikkinen
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

Re: [Development] Use of std::function in Qt API

2017-03-24 Thread Edward Welbourne
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

Re: [Development] QList

2017-03-24 Thread Ville Voutilainen
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

Re: [Development] QList

2017-03-24 Thread Marc Mutz
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