I've given this a little more thought...So, I am not sure that generic algorithms like you suggest would be very beneficial. Ultimately, the type erased object are effectively pointers to memory in the heap. I'd think that any tangible benefit of allowing the user to choose their own container would be wiped out by the fact that the actual data is stored discontiguously out in the heap and you still need to dereference pointers to get to it. In this case, I think that defining the container but allowing the user to insert any datatype into natively would be more user friendly than allowing the use of any container but requiring the use of a type erased datatype. Also, to me it just feels 'cleaner' to call a method on the container rather than pass the container to a function. My current 2 cents On Tue, May 5, 2015 at 3:37 PM, Boris Rasin <boris@pointx.org> wrote:
On 5/5/2015 9:04 PM, James Armstrong wrote:
You're correct in that a vector<boost::any> can achieve the same thing, and that would probably be the better way to implement this internally. I guess the proposal would be to provide the container interface to give some data modification functions and iterators which iterate over only a given type and such. That way there would be a standardized container with methods to deal with the data in a type specific way.
But why do you need special container type if all you want are algorithms and iterator adapters? Like I said before, this could be useful, but wouldn't it be better to write this as generic algorithms capable of working with any container of boost::any, not just vector? Better yet, any container of type erased or discriminated union objects (boost::any, boost::type_erasure::any, boost::variant, eggs::variant, etc.)?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- James Armstrong