[Development] RFC: Containers member functions for algorithm

[Giuseppe D'Angelo]

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 contains a type
comparable for equality, but no sequential container enforces that (nor
it should), so this is effectively API pollution.

Bikeshedding²: this also means more symbols exported (if you end up
exporting an instantiation of the container), or similarly more totally
unnecessary requirements on the type (cf. the QItemSelection example)

Bikeshedding³: contains()/indexOf() use a linear scan, where's my member
function for binary search, if I know the container is sorted? How can I
decide the direction of the linear scan?

Bikeshedding⁴: what are the parameters of contains()/indexOf() for a
Container<T>? T / const T &? But why not any K that you can compare
against a T?

Bikeshedding⁵: if there's indexOf() (returning an index), should there
it be also a find() (returning an iterator)? If there's find(), should
it there also be an indexOf()? Is it OK to have fundamentally duplicated
APIs, and not strive for a good degree of minimality and simplicity?

[we can go forward]

> For the rest, free functions provide more flexibility.

This statement is in contradiction with the previous ones.

Containers are containers, and algorithms are algorithms; the library
provides both as enabling mechanisms, the users decide how to mix and
match them depending on the problem at hand.

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170323/164e19af/attachment.bin>