On Mon, Mar 18, 2013 at 11:30 AM, Andy Jost
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen
Well, I don't see a need for all the allocator stuff. What the point? Do you have a similar need when using boost::function<> or boost::any? reference/const_reference can be T& and T const&. Perhaps we don't need pointer. One may choose a difference_type that is 64 bit to be generic.
Maybe looking at some code would help clarify the answers to these questions. I have about 300 lines partially implementing an adaptor for std::set using Boost.TypeErasure, plus a list of questions and problems I encountered. Is that too large to put into an email for this list? If so, where can I drop it?
-Andy
My opinions on all of this, starting with the beginning question of "any interest", etc: - yes - "sort of" - I have had a number of occasions where I felt, for various reasons, that the trade offs between run time and compile time polymorphism favoured run-time, and thus would use - in some sense - a run time polymorphic container. - "sort of" - what do I mean by sort of? Well, I *never* needed a complete container abstraction - I only ever needed a small subset of a container's API to be polymorphic. If I needed to iterate over the container I may have used/written any_iterator or similar. If I needed to add to the container, maybe I abstracted a push-back interface or used a boost::function that could only add. Etc. So 1) I think many of the responses given so far fit into the above answer. ie responses like "yes I could use something like that" really mean I would use *part* of an abstract interface; and "no, why not use any_iterator or function<> or ..." mean I would only use *part* of the abstract interface. 2) I lean toward thinking a full abstract interface is not very useful. To the point of being *wrong*. If I see a function like: determine_foo(AbstractSet * set); Does it really need the *complete* set interface? I highly doubt it. I'd prefer, and as a general rule almost always prefer, interfaces to be defined by the code that *calls* the interface. I would like to know which functions of AbstractSet the function actually calls and requires. (ie interfaces on functions should be like concepts/requirements on templates) So unless you want to break down AbstractSet into its smaller sub-interfaces, I doubt I'd ever use your abstractions. I see with Boost.TypeErasure you have them groups into sections. Maybe those should each be separate interfaces, and then AbstractSet would be the combination of interfaces. Tony P.S. The interfaces should probably match the C++ concepts that the containers model. Maybe once we get concepts (lite?) into C++, we could make an automatic concept-to-runtime-interface mechanism?