On Sun, 28 Nov 2010 10:48:46 -0500 bearophile <bearophileh...@lycos.com> wrote:
> generally I don't like to use find, empty and popFront to solve this problem, > it's quite unnatural. Here I have explained what I think is a good enough > solution to this performance problem: > http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=123044 What I would like is a just decent routine for comparing arrays of elements which _conceptually_ are values, whatever their complexity (meaning, possibly structs or nested arrays). This should always (*) use a default '==' comparison, which in turn may perform a kind of memcomp. I have no idea how to avoid bad perf such as shown by your tests, but this is really necessary. Tons of routines and algorithms use '==', and among the most used; str.find will perform an arbitrary number of '==' checks; and I don't even want to think at pattern matching ;-) Denis (*) I think that: * If an element type is a value type, it should not overide opEquals. '==' should translate to equality of every sub-element. Else, there is something wrong in the design. But there may be use cases I overlook. (Eg metadata stored on the element itself?) * A plain value may well refer to a "thing"/object, eg a wiget's outlook pointing to a color palette, in which case reference comparison is the right choice -- so, no complication. * Real things (referenced objects, entities with self/id) should not have opEquals at all. They should be compare only by id, meaning using 'is'. This shows again the ambivalence of dyn arrays... -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
