Re: [boost] [type_erasure]any(const binding<Concept>&, ...) compile error

Subject: Re: [boost] [type_erasure]any(const binding<Concept>&, ...) compile error
From: Larry Evans (cppljevans_at_[hidden])
Date: 2012-07-28 11:25:01

On 07/27/12 14:27, Steven Watanabe wrote:
> AMDG
>
> On 07/27/2012 11:54 AM, Larry Evans wrote:
>> On 07/27/12 13:08, Steven Watanabe wrote:
>>>
>>> You're passing an argument of type ph_value<_a>.
>>> How would constructible<_a(const _a&)> (which
>>> is the copy constructor) be viable?
>>>
>>
>> Because, when _a in constructible<_a(const _a&)> is replaced by the
>> binding, it becomes, IIUC,
>>
>>   constructible<ph_value<_a>(const  ph_value<_a>&)>
>>
>
> This substitution happens in the dispatching layer.
> In the interface of any, constructible<_a(const _a&)>
> defines the constructor:
>
> any<C, _a>::any(any<C, const _a&>);
>
> It can't possibly define
> any<C, _a>::any(const ph_value<_a>&);
> because it doesn't know about ph_value<_a>.
>

Why doesn't it know about ph_value<_a>?  It's the contained type
corresponding to _a, and that must be available somewhere in the
binding<Concept> arg ; otherwise, it couldn't create the a_dup
even when the constructible is:

  constructible<_a(const a_type&)>

instead of:

  constructible<_a(const _a&)>

>> and this is the same as the compiling version of binding_of.cpp.
>> I thought this replacement is what would happen based on the example:
>>
>>   constructible<_a(const _b&, const _c&)>
>>
>> from:
>>
>>
>>
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/construction.html
>>
>> Why is the replacement done in the construction.html example and not
>> in bindings_of.cpp?  Hmmm... Ok, the example has any args, from which
>> the bindings<ConceptA> can be gotten.  But those same bindings are
>> available from the binding<ConceptA> arg in bindings_of.cpp creation
>> of a_dup.
>>
>> Obviously I'm still missing something, but I've no clue what :(
>>
>
> The library deals with either any's or
> with the contained types, but not both,
> depending on what layer you're looking at.
> You're trying to mix the two.
>

Initially, that made no sense to me.  Then, after further
experimentation with the attached, where I used every combination of
the defined or undefined for macros:

  HARDCODE_CTOR_ARG
  A_DUP_VALUE

I finally realized that a placeholder in a concept does not stand for
the contained type, instead it stands for a type_erasure::any of the
contained type.  If that's right, I can't remember seeing that
anywhere in the docs.  However, looking again at the examples:

  multi.html
  construction.html

that seems to fit.

Now the doc here:

  conceptdef.html

does say:

  When a concept is instantiated with a specific set of type bindings,
  each placeholder is bound to a cv-unqualified non-reference type

but it doesn't say the non-reference type must be an any.

Also, the doc here:

  placeholder.html

says:

  Placeholders act as a substitute for template parameters in
  concepts. The library automatically replaces all the placeholders
  used in a concept with the actual types involved when it stores an
  object in an any.

but it doesn't say the actual type must be a type_erasure::any of some
sort.  I thought (quit understandably, IMO) the actual type could be
the one specified by mpl::at<Map,Tag>::type where Map is the one used
in static_binding<Map>.

To help avoid future confusion, I suggest the docs make very clear
that the placeholder's in the concepts stand for a type_erasure::any
of some sort.  Also, the doc:

  any.html#id2445089-bb

contains:

     Requires:
       Concept must contain a matching instance of constructible.

but no definition of "matching".  So, again, to help avoid future
confusion, please provide a definition of "matching" (maybe in a
matching.html file, with a link to that file) which emphasizes that a
placeholder does stand for a type_erasure::any and *not* for the
contained type corresponding to the placeholder.

I'm apologize to take up so much of your time and I appreciate your
patience in helping me understand type_erasure.

-regards,
Larry