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
On 5/5/2015 9:04 PM, James Armstrong wrote:
You're correct in that a vectorboost::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