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 "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]
I'm very much with Peppe here. Olivier, please take these points into consideration. Bloating the API of a generic container with methods that are only usable for special circumstances is imo not a good idea. I am not opposed to having free functions which are giving you convenience. That's also what many of the existing convenience functions should have been in the first place, btw. Like QStringList::join etc. -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development