Paralysis of analysis

[Nick Sabalausky]

"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message 
news:op.vnpx3oioeav7ka at steve-laptop...
> On Tue, 14 Dec 2010 14:02:34 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> Advantages of the change:
>>
>> - Clear, self-documented reference semantics
>>
>> - Uses the right tool (classes) for the job (define a type with 
>> reference semantics)
>>
>> - Pushes deterministic lifetime issues outside the containers 
>> (simplifying them) and factors such issues into reusable wrappers a la 
>> RefCounted.
>
> - exposes the issue of default initialization by disallowing that.  This 
> is the problem of passing an uninitialized struct into a function and 
> having the function not be able to affect the original.  A class has a 
> more defined and better understood lifetime cycle -- nothing exists until 
> new is used.
>
> - no more need to "check if it's valid" in every member function.
>
>> Disadvantages:
>>
>> - Containers must be dynamically allocated to do anything - even calling 
>> empty requires allocation.

(First of all, Disclaimer: I might not even know what the hell I'm talking 
about...)

I'd be surprised if typical usage would cause this to be an issue. It's not 
like people are going to be allocating a new container *every* time 
something like "empty" is called. And there's always checking if the 
reference itself is null - that doesn't require allocation.

>> - There's a two-words overhead associated with any class object.

Since, like you said, containers usually carry a fair amount of data, I'd be 
surprised if this would really be an issue. If there is ever a need for lots 
of containers with very small data one could still just do it all manually 
with structs. And maybe some wrappers could be used to get it to play nice 
with existing stuff that expects a standard class-based container?

Although, if this overhead would be associated with, for instance, every 
node in a tree or graph, then it might be more of an issue.

>> - Containers cannot do certain optimizations that depend on container's 
>> control over its own storage.

This seems like it could be more of an issue than the other two drawbacks. I 
wonder how often those optimizations would be needed? If only on occasion, 
then forcing a manual solution in those cases might be worth it for the 
rather compelling advantages.