Paralysis of analysis

[Andrei Alexandrescu]

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