> On Mar 24, 2017, at 10:33 PM, André Pönitz wrote:
>
> 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 r
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/ap
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 typic
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 quinta-feira, 23 de março de 2017 02:36:06 PDT Marc Mutz wrote:
> Second, that member functions always get their *this argument passed by
> reference. A free function can take the argument by value instead.
The example for this is actually in the other thread: QStringView::indexOf().
If you wr
On quinta-feira, 23 de março de 2017 00:32:14 PDT Olivier Goffart wrote:
> 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:
[cut]
I li
On Thursday, March 23, 2017 11:12:31 AM CET Giuseppe D'Angelo wrote:
> Il 23/03/2017 10:50, Philippe ha scritto:
> > I hardly imagine a "container" api without a "contains()" member. What I
> > would call good sense. Qt already has this, std not.
> >
> > The other member that makes sense, if "inde
Il 23/03/2017 10:36, Marc Mutz ha scritto:
> Exactly. Bring back qSort(Container &), calling std::sort(std::begin(c),
> std::end(c)). But leave the container interface alone.
This could be done "right now" if we add them in a separate namespace.
Whether changing qSort itself -- back in the day I
I agree, but Marc actually just said that creator could suggest
functions with signature f(T) when one presses . after an object o of
type T. That's not the same as allowing the syntax o.f() to call f(o).
On 23.03.2017 11:51, Konrad Rosenbaum wrote:
> On Thursday, March 23, 2017 10:36:06 Marc Mut
On Thursday, March 23, 2017 10:36:06 Marc Mutz wrote:
> There're
> proposals floating around for years to make o.f() fall back to f(o) for std
> C++.
Those are a lot more pain than you'd think! This construct already exists in
C# (static extension classes/methods) and it is causing major headache
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
Il 23/03/2017 10:50, Philippe ha scritto:
> I hardly imagine a "container" api without a "contains()" member. What I
> would call good sense. Qt already has this, std not.
>
> The other member that makes sense, if "indexOf()"... Qt already has this.
Bikeshedding: this implies that your container
On 2017-03-23 11:01, Ville Voutilainen wrote:
On 23 March 2017 at 11:36, Marc Mutz wrote:
That said, there's a reason why there's no std::sort(Container &).
It's
because you need Concepts to disambiguate the various overloads. Well,
that
and because Eric Niebler doesn't manage to limit the sco
On 23 March 2017 at 11:36, Marc Mutz wrote:
> That said, there's a reason why there's no std::sort(Container &). It's
> because you need Concepts to disambiguate the various overloads. Well, that
> and because Eric Niebler doesn't manage to limit the scope of his range
> proposals.
The TS proposa
I hardly imagine a "container" api without a "contains()" member. What I
would call good sense. Qt already has this, std not.
The other member that makes sense, if "indexOf()"... Qt already has this.
For the rest, free functions provide more flexibility.
>> I realize that QtCreator already has h
On Thursday 23 March 2017 09:27:53 Eike Ziller wrote:
> I do not think that these belong into the API of the containers though, or
> at least if (some of) this API gets into the containers itself, the
> implementation should just call generic functions. There is no reason why
> the convenience shou
> On Mar 23, 2017, at 8:32 AM, Olivier Goffart wrote:
>
> 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();
> //
Hi,
I love this idea and how it goes into the direction of making life easier (more
convenient) for developers.
Simon
> On 23 Mar 2017, at 08:32, Olivier Goffart wrote:
>
> Hi everyone,
>
> I have been wondering if we should enhance Qt container with member functions
> to help using some of
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 (
20 matches
Mail list logo
