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