On Tue, Jun 30, 2009 at 11:14 AM, Simonson, Lucanus J < lucanus.j.simonson@intel.com> wrote:
[snip] Deriving from a common ancestor base class is contrary to generic programming. Knowing all your types ahead of time (at compile time) is not unreasonable, it is the common case for generic programming.
Sure, but as much as we'd perhaps like to forget about it, it is true that C++ supports OO style as well as generic programming, especially in GUIs and other object hierarchies. In these cases, you either cannot know or don't want to know all the types that may be used ahead of time. This is the basic premise of loose coupling.
Saying it is contrary to your idea is like saying it is different from what you implemented. That isn't exactly a strong argument for why people should use heterogenous::vector instead of vector<variant<> >.
What I implemented came from discussions with Thorsten about how to deal with cloning in ptr_containers. To solve that, I ended up with a system that I saw may be of general interest and could possibly stand orthogonally to ptr_container. Using variant<> instead is certainly possible, but you could then also argue that ptr_container is pointless over a vector<variant>. But the truth is that a ptr_container is much more flexible than a vector<variant>. Given that heterogenous is based largely on ptr_container, the same is true there. Even so, I can't see how associative containers can work with variant<>, and it also doesn't provide a means to have a custom clone operation.
I can tell you people will not be happy to derive from your common base class.
I understand and empathise with that position. That is why, in my initial email, I stated: "One initial issue that may break any interest is that instances put into the container must be of a type T that derives from heterogenous::base<T>." However, I do not see any possible way to provide correct cloning of types, given just a base pointer, without having this constraint. That said, the system allows you to your own base, rather than heterogenous::common_base. template <class Derived, class Base = common_base> struct base But even here, currently common_base is needed at the bottom somewhere. Perhaps this too could be conceptualised, rather than using a fixed abstract base class supplied by the library.
This kind of design relegates it to being useful only to new classes that people write, and not to legacy classes that people use. That hugely narrows the scope of where it can be useful.
Christian> This excludes adding builtin types, and means that you either have to change your existing class definitions to put them into such a container, or use a supplied heterogenous::adaptor<T> system. The idea of heterogenous::adaptor<T> is to make a 'heterogenous type' from an existing type T which you cannot modify.
It may be pretty particular to what you want to do and not generally useful in a context where people aren't so picky about which allocator they use and all types in an application tend to use the same one.
Perhaps you are right and this is too specific. Even so, isn't there a general need for a heterogenous containers (both sequence- and associative-types) that have proper value semantics, can be cloned correctly, use a single allocator, and uses emplace construction for object insertion? There are some interesting properties of real heterogenous containers that I think you may find surprising.
Regards, Luke
Cheers, Christian