Re: [boost] Interest in a "Heterogenous Container" system?

Subject: Re: [boost] Interest in a "Heterogenous Container" system?
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2009-07-31 15:14:49

Stewart, Robert wrote
>>
>>> Yes, containers of shared_ptrs would work, but they add
>>> overhead that isn't always wanted.
>> Then use containers of unique_ptr, like you should (shared_ptr
> 
> "like you should" is a rather strong statement.

If you want a container of pointers with the container owning the 
pointees, in order to use inclusion polymorphism for example, then a 
container of unique_ptr is the standard solution, while a container of 
shared_ptr is not only overkill since it adds a lot of useless overhead, 
it also gives the wrong semantics.
A container of clone_ptr is a more elegant solution if you can't use 
move semantics, since it actually has the right ones. You may want to 
implement it using COW however since non move-aware containers can do a 
lot of spurious copies.

> All of those schemes mean that the container interface is in terms of those wrapper types rather than raw pointers.  They will work, but they complicate the code using the elements.  I'm not suggesting that is onerous, but the interface isn't as simple.

How are smart pointers, smart references or smart objects (whatever you 
want to call them) any more difficult to use than pointers or objects?

> 
>>> The heterogeneous containers, being implemented as class
>>> templates, need only be defined in terms of operations
>>> supported by its parameterizing types.
>> This merely looks like a container of Adobe.Poly.
> 
> I've never used anything from the Adobe library.  You may be right, but why shouldn't Boost provide a clean solution for itself?

Adobe.Poly is a generic type erasure tool, that can implement any type 
erasure for a given interface given as a parameter.
boost::function, boost::any, and a few others from boost are simply 
special cases of Adobe.Poly (function with a callable interface, any 
with an empty interface).

Boost could have something similar to Adobe.Poly (and I believe it 
eventually will -- the real issue is how to specify the interface), but 
this should be completely separate from the very idea of a container, 
since coupling the two has less advantages than making them separate and 
is actually harder to design, write and maintain.