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