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