"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