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:
>>
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
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
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
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
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.
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
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
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;
> -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
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,
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
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
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
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
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
16 matches
Mail list logo