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 | [email protected] | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
