Kinds of containers

Brad Anderson via Digitalmars-d digitalmars-d at puremagic.com
Wed Oct 21 09:36:44 PDT 2015


On Wednesday, 21 October 2015 at 11:05:12 UTC, Andrei 
Alexandrescu wrote:
[snip]
> 2. Reference containers.
>
> These have classic reference semantics (à la Java). Internally, 
> they may be implemented either as class objects or as reference 
> counted structs.
>
> They're by default mutable. Qualifiers should apply to them 
> gracefully.
>
> 3. Eager value containers.
>
> These are STL-style. Somewhat surprisingly I think these are 
> the worst of the pack; they expensively duplicate at the drop 
> of a hat and need to be carefully passed around by reference 
> lest performance silently drops. Nevertheless, when used as 
> members inside other data structures value semantics might be 
> the appropriate choice. Also, thinking of them as values often 
> makes code simpler.
>
> By default eager value containers are mutable. They should 
> support immutable and const meaningfully.

Having both reference and value semantics for containers would be 
great. I don't understand why reference semantics would be 
implemented by the container themselves though. Why not a general 
purpose RC! (or RefCounted! if the current design is deemed 
sufficient) that can apply to anything, including containers? 
Then you'd only need to implement the value semantic containers 
(and maybe throw in some RC version aliases to promote the use of 
the RC versions so the option isn't overlooked). It seems kind of 
crazy that anything in D that wants to be reference counted would 
need to implement the logic themselves.

If there are performance advantages (I haven't thought of any but 
perhaps there are) to bake the RC right into the container it 
might also be possible to use DbI take advantage of it in RC! 
when appropriate.

It just seems so wrong to implement reference counting dozens of 
times independently, especially when that means implementing all 
the containers twice too.

Perhaps I'm misreading what you meant though and this is what you 
intended all along.

> 4. Copy-on-write containers.
>
> These combine the advantages of value and reference containers: 
> you get to think of them as values, yet they're not expensive 
> to copy. Copying only occurs by necessity upon the first 
> attempt to change them.
>
> The disadvantage is implementations get somewhat complicated. 
> Also, they are shunned in C++ because there is no proper 
> support for COW; for example, COW strings have been banned 
> starting with C++11 which is quite the bummer.
>
> Together with Scott Meyers, Walter figured out a way to change 
> D to support COW properly. The language change consists of two 
> attributes.

Nice to have this option. I don't think I'd use it much though.


More information about the Digitalmars-d mailing list