Subject: Re: [boost] Abstract STL Container Adaptors
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2013-03-18 15:53:32
On Mon, Mar 18, 2013 at 11:30 AM, Andy Jost <Andrew.Jost_at_[hidden]>wrote:
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Thorsten
> > 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?
My opinions on all of this, starting with the beginning question of "any
- 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.
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
P.S. The interfaces should probably match the C++ concepts that the
Maybe once we get concepts (lite?) into C++, we could make an automatic
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk