On 12/14/10 1:42 PM, Dmitry Olshansky wrote:
On 14.12.2010 22:02, Andrei Alexandrescu wrote:
I also continue to believe that controlled lifetime (i.e.
reference-counted implementation) is important for a container.
Containers tend to be large compared to other objects, so exercising
strict control over their allocated storage makes a lot of sense. What
has recently shifted in my beliefs is that we should attempt to
implement controlled lifetime _outside_ the container definition, by
using introspection. (Currently some containers use reference counting
internally, which makes their implementation more complicated than it
could be.)
What challenges do we face with this approach? Can you please outline
the mechanics of that controlled lifetime outside the container part,
e.g. is it by usage of some tricky wrappers?
Usage of wrappers, yes. Essentially you'd use e.g. RBTree as a class or
RefCounted!RBTree, which calls clear() against the object when the
reference count goes down to zero.
Finally, I continue to believe that sealing is worthwhile. In brief, a
sealing container never gives out addresses of its elements so it has
great freedom in controlling the data layout (e.g. pack 8 bools in one
ubyte) and in controlling the lifetime of its own storage. Currently
I'm not sure whether that decision should be taken by the container,
by the user of the container, or by an introspection-based wrapper
around an unsealed container.
Your change looks like going with third option, am I correct?
Steve correctly pointed out that sealing must belong in the container.
- Containers must be dynamically allocated to do anything - even
calling empty requires allocation.
I was of impression that you could allocate class instances almost
anywhere (with help of emplace), it's just that heap being the safe
default.
Most people would simply call new.
- There's a two-words overhead associated with any class object.
- Containers cannot do certain optimizations that depend on
container's control over its own storage.
That must have something to do with sealed container being wrappers over
unsealed ones, so as I observe your change implies not only a change to
final classes. Clearly something is missing in your post can you please
be more specific on that change?
I withdraw that comment because I don't have good examples aside from
deterministic memory release, which I already discussed.
Andrei
