Steven Schveighoffer wrote:
On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke <rain...@eldwood.com>
wrote:
I can't say I've ever cared about the big-O complexity of an operation.
Then you don't understand how important it is. Here is an example of
how caring about the big O complexity cut the runtime of dmd to about 1/3:
http://d.puremagic.com/issues/show_bug.cgi?id=4721
big O complexity is very important when you are writing libraries. Not
so much when you are writing applications -- if you can live with it in
your application, then fine. But Phobos should not have these problems
for people who *do* care.
What I'd suggest is to write your own function that uses in when
possible and find when not possible. Then use that in your code.
Personally, I'd vote for inclusion of such a function in Phobos. The big
problem with C++ containers was and is an absence of uniform interface.
Typedefing those templates to save typing was good, but it didn't
completely solve the problem of interchangeability. E.g., you make a
change from list to vector and suddenly realize that remove() doesn't
work anymore.
Having uniform interface for insertion/removal/lookup is plainly awesome.
What if Phobos defined a function, say, E* contains(C,E)(C container, E
element) that'd behave as 'in' operator as best it could for type C?
It'd fit frequent demands without making big promises - in other words,
would still be largerly useful.
Yes, I understand that good (performance-wise) generic solution isn't
that simple to discover and implement. But having an easily accessible
(i.e. standard), though maybe not all that efficient solution is a good
thing nevertheless.
