Kinds of containers

[Timon Gehr via Digitalmars-d]

On 10/21/2015 11:02 PM, Jonathan M Davis wrote:
>
> Static arrays are a bit of a special case, because they're essentially a
> chunk of memory on the stack. They can be extremely useful and
> efficient, but you have to be careful with them. Most containers don't
> act anything like them.
>
> But like I said, there are some container types which inherently make
> sense on a stack, but most don't. For the most part, the kinds of
> containers that we're talking about here - vectors/array lists, linked
> lists, maps, sets, etc. - have to have most of their guts living on the
> heap. You'd have to _really_ contort things to put them entirely on the
> stack,

In many applications, most containers are small. Small containers can 
have all their guts on the stack.

> and you'd be seriously limiting how many elements that they could
> hold if you did.

Not really. Just allocate on the heap only if there are too many elements.

> If you make a vector or a linked list a value type,
> then it'll have a few members on the stack, but most of them will be on
> the heap, and it'll be a value type only because its postblit
> constructor explicitly copies the portion that's on the heap. It's not
> really naturally a value type.

Value semantics does not mean slow copy, I assume you conflate value 
semantics and eager copy?

> It's naturally more of a reference type
> or pseudo-reference type.

What you describe is "naturally" (which I interpret to mean: if postblit 
must be O(1)) a unique reference type. I.e. the most natural way out 
would be to add @disable this(this). But implicit copy can be 
convenient. Maybe have implicit copy as a wrapper?