Re: [boost] [TypeErasure] Composing Concepts & some notes

Subject: Re: [boost] [TypeErasure] Composing Concepts & some notes
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-07-19 19:02:59

AMDG

On 07/19/2012 03:35 PM, Fabio Fracassi wrote:
> Hi Steven,
> 
> I am going through the documentation and simultaneously try out some
> things that weren't immediately obvious to me. When I came to the
> paragraph about composing concepts the last sentence "We can even
> specialize concept_interface for it." tripped me up. My thought was "but
> do I have to?

No.  It is only needed if you want to
add extra functionality in the composite
concept.

> and how do composed concepts interact with manually
> composed any's?" so I gave it a try:
> 
> <snip>
> 
> great everything works as expected, and no, I did not have to define a
> concept_interface for the composite interface. Now the first question is
> why would I want to?
> 

Take a look at the iterator concepts.
forward_iterator is a composite of
several operators.  The specialization
of concept_interface adds
typedef std::forward_iterator_tag iterator_category;

> now the main reason for the exercise was how do these interact with each
> other and while I am at it how do they interact with the concepts they
> are composed of? Well I can freely interact as I hoped:
> 
>    any_vecconcept acvec2(alvec);
>    any_manual_vecconcept alvec2(acvec);
> 
>    any_push_back pb3(alvec);
>    any_push_back pb4(acvec);
> 
>    any_size s2(alvec);
>    any_size s3(acvec);
> 
> This is great! I might have missed it in the documentation, but I think
> this is really an important feature that deserves special mention.
> 

It is documented in the reference.
I agree that conversions deserve a
separate section.  (There is a subsection
of Design Notes detailing the different
constructors)

> Now I gather that there is no way to do the opposite, something along
> the lines of
> any_vecconcept acvec3 = dynamic_any_cast<any_vecconcept>(s3);
> Well over the next days I will dive a bit deeper into the internals to
> see if implementing such a feature would be feasible. (because I need it
> before I could replace my current solution with type erasure)
> 

It's possible in principle, but it would
require extra global tables, some
extensions to the binding interface,
and some kind of registration mechanism.

In Christ,
Steven Watanabe