std.container and classes

Peter Alexander peter.alexander.au at gmail.com
Sat Dec 17 17:50:17 PST 2011


On 17/12/11 11:31 PM, Andrei Alexandrescu wrote:
> The most important thing I noticed is that people expect standard
> containers to have sophisticated memory management. Many ask not about
> containers as much as "containers with custom allocators". Second,
> containers tend to be large memory users by definition. Third,
> containers are self-contained (heh) and relatively simple in terms of
> what they model, meaning that they _never_ suffer from circular
> references, like general entity types might.
>
> All of these arguments very strongly suggest that many want containers
> to be types with deterministic control over memory and accept
> configurable allocation strategies (regions, heap, malloc, custom). So
> that would mean containers should be reference counted structs.

My thoughts on this:

Allocators are a must, and need to handled better than they were in C++.

Classes are simpler than ref-counted structs, and ref-counting is a 
massive performance drain and code-bloater anyway, so just go with final 
classes.


> Safety is also an issue. I was hoping I'd provide safety as a policy,
> e.g. one may choose for a given container whether they want safe or not
> (and presumably fast). I think it's best to postpone that policy and
> focus for now on defining safe containers with safe ranges. This
> precludes e.g. using T[] as a range for Array!T.

IMO they should just be safe and not provide the option of non-safe. It 
just complicates things to cater to people that won't use them anyway 
C++ standard library containers are unsafe and relatively lean, yet are 
rarely used when performance really matters.


More information about the Digitalmars-d mailing list