"in" everywhere
Stanislav Blinov
stanislav.blinov at gmail.com
Thu Oct 7 13:50:45 PDT 2010
Steven Schveighoffer wrote:
> On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke <rainerd at 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.
More information about the Digitalmars-d
mailing list