Re: [boost] Abstract STL Container Adaptors

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
> 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?