std.gregorian contribution

Steven Schveighoffer schveiguy at
Mon May 17 14:16:09 PDT 2010

On Mon, 17 May 2010 17:01:22 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at> wrote:

> On 05/17/2010 03:16 PM, Steven Schveighoffer wrote:
>> Comparing splitByOneOf(str, "; ")) to splitter(str, set(';', ' ')), I
>> see one major difference here -- "; " is a literal, set(';', ' ') is  
>> not.
>> I would expect that 'set' as a generic set type would implement it's
>> guts as some sort of tree/hash, which means a lot of overhead for a
>> simple argument. With the literal version, the notation is in the
>> function, not the type. While it seems rather neat, the overhead should
>> be considered.
>> A compromise:
>> foreach(x; splitter(str, either("; ")))
>> Which can be implemented without heap activity.
> These are good points. They have gone through my mind as well, but  
> lately I've started to take a somewhat more liberal view of containers.  
> For example, I'm thinking that Set!T (which would be the type returned  
> by set()) could automatically use arrays and linear search for small  
> sets. Other special cases come to mind, such as the small array  
> optimization. In other words Set!T would not have a guaranteed  
> implementation, but instead exploit magnitude to choose among a spectrum  
> of implementation alternatives.

These are good ideas.

> Of course using a different name such as either() is even better for the  
> implementation because it can make additional implementation dictated by  
> the restricted use of either(). For example either() could return a  
> FixedSet!T that does not accept adding new members and is optimized  
> accordingly.

FixedSet!T would be easily implemented as a sorted array for any number of  
members (unsorted for under some threshold number of members).

My point was simply that all input parameters besides the string literal  
require heap activity to maintain the set.  Much less if you allocate one  
array, but for something like "; ", I would like to see zero heap activity  


More information about the Digitalmars-d mailing list