Boost logo

Boost :

Subject: Re: [boost] [type_erasure]any(const binding<Concept>&, ...) compile error
From: Larry Evans (cppljevans_at_[hidden])
Date: 2012-07-26 19:44:31

On 07/26/12 15:32, Steven Watanabe wrote:
> On 07/26/2012 09:21 AM, Larry Evans wrote:
>> However, in my defense, I couldn't see any reason why,
>> if:
>> any<Concept,_a> a_any
>> can be created with static_map<Concept>, it couldn't be
>> created with a binding<Concept>; thus, I guess I just
>> glossed over the any.html#id2445089-bb doc.
> The reason I didn't provide it, is that I
> assumed that if the type you're constructing
> is known statically, the entire set of type
> bindings would be known statically.
>> BTW what *is* the reason for the restriction on the Concept in the
>> binding<Concept> CTOR. It's obviously not needed for creating
>> an instance of AnyA with a value<_a>::type even when ConceptAB does
>> not "contain a matching instance of constructible".
> Yes it is.

Then why can an AnyA be created with the
static_binding<bindings_map_t> CTOR *without* the need for any
constructible concept?

The fact that AnyA can't be created with the binding<ConceptAB> CTOR
is a an unnecessary restriction since, obviously, it can be created
with the static_binding CTOR

> You're not understanding what
> this constructor does properly.
> template<class... T>
> explicit any(binding<Concept>, T&& ...);
> calls a type erased constructor.
> The stored type is whatever the binding
> says, /not/ T. constructible<...> is
> required, because it is used to construct
> the contained object.

But this:

  constructible<...> is
  required, because it is used to construct
  the contained object.

constradicts what happens with the static_binding CTOR because
an AnyA *is* constructed with that CTOR when ConceptAB does *not*
contain constructible<a_(...)>. Now it's obviously required by the
binding<ConceptAB> CTOR, but that is, AFAICT, an unneeded restriction.

Now if you made the 2 constructors consistent (i.e. both requiring
constructible<a_(...)>, I could see your point; however, as long as
the static_binding allows creation with constructible<a_(...)>, then
the other one should also.

One way to achieve consistency is shown in my other post:

That post contains a revised detail/construct.hpp. It's the same as
the one in svn except, in case there's just one U, it behaves the same
as the static_binding CTOR. IOW, with just one U arg, no
construct<a_(...)> is needed either with the static_binding
CTOR(obviously because there is only one CTOR arg besides the
static_binding one) or with the binding<ConceptAB> CTOR.


Boost list run by bdawes at, gregod at, cpdaniel at, john at