[type_erasure]any(const binding<Concept>&, ...) compile error
The attached, when compiled with with gcc4.8-20120624, produces compile error: ../../../boost/type_erasure/detail/construct.hpp: In instantiation of 'boost::type_erasure::any<Concept, T>::any(const boost::type_erasure::binding<Concept>&, U0&) [with U0 = value<boost::type_erasure::_a>; Concept = boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_a>, boost::type_erasure::copy_constructible<boost::type_erasure::_b> >; T = boost::type_erasure::_a]': binding_of.cpp:71:32: required from here ../../../boost/type_erasure/detail/construct.hpp:99:9: error: invalid use of void expression ) ^ Am I doing something wrong? TIA. -Larry
AMDG On 07/26/2012 05:29 AM, Larry Evans wrote:
The attached, when compiled with with gcc4.8-20120624, produces compile error:
../../../boost/type_erasure/detail/construct.hpp: In instantiation of 'boost::type_erasure::any<Concept, T>::any(const boost::type_erasure::binding<Concept>&, U0&) [with U0 = value<boost::type_erasure::_a>; Concept = boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_a>, boost::type_erasure::copy_constructible<boost::type_erasure::_b> >; T = boost::type_erasure::_a]': binding_of.cpp:71:32: required from here ../../../boost/type_erasure/detail/construct.hpp:99:9: error: invalid use of void expression ) ^
Am I doing something wrong?
The concept doesn't contain anything that matches an argument of type value<_a>. In Christ, Steven Watanabe
On 07/26/12 09:02, Steven Watanabe wrote:
AMDG
On 07/26/2012 05:29 AM, Larry Evans wrote:
The attached, when compiled with with gcc4.8-20120624, produces compile error:
../../../boost/type_erasure/detail/construct.hpp: In instantiation of 'boost::type_erasure::any<Concept, T>::any(const boost::type_erasure::binding<Concept>&, U0&) [with U0 = value<boost::type_erasure::_a>; Concept = boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_a>, boost::type_erasure::copy_constructible<boost::type_erasure::_b> >; T = boost::type_erasure::_a]': binding_of.cpp:71:32: required from here ../../../boost/type_erasure/detail/construct.hpp:99:9: error: invalid use of void expression ) ^
Am I doing something wrong?
The concept doesn't contain anything that matches an argument of type value<_a>.
Then why isn't a similar compile error produced when b_any is constructed? A revised test driver(attached) uses double instead of value<_a> and value<_b> and it still produces the same error. In addition, when bindings_made instead of b_bindings is used to make a_any, it compiles and runs without problem whether value<_a> or value<_a>::type (i.e. double) is used as the value arg to AnyA. -regards, Larry
AMDG On 07/26/2012 07:40 AM, Larry Evans wrote:
On 07/26/12 09:02, Steven Watanabe wrote:
On 07/26/2012 05:29 AM, Larry Evans wrote:
The concept doesn't contain anything that matches an argument of type value<_a>.
Then why isn't a similar compile error produced when b_any is constructed?
This calls a different constructor which has different requirements. Have you read the reference for any? I tried to cover the constructors thoroughly.
A revised test driver(attached) uses double instead of value<_a> and value<_b> and it still produces the same error.
Why would that make a difference?
In addition, when bindings_made instead of b_bindings is used to make a_any, it compiles and runs without problem whether value<_a> or value<_a>::type (i.e. double) is used as the value arg to AnyA.
In Christ, Steven Watanabe
On 07/26/12 09:57, Steven Watanabe wrote:
AMDG
On 07/26/2012 07:40 AM, Larry Evans wrote:
On 07/26/12 09:02, Steven Watanabe wrote:
On 07/26/2012 05:29 AM, Larry Evans wrote:
The concept doesn't contain anything that matches an argument of type value<_a>.
Then why isn't a similar compile error produced when b_any is constructed?
This calls a different constructor which has different requirements. Have you read the reference for any? I tried to cover the constructors thoroughly.
My mistake. I didn't notice: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/... had: Concept must contain a matching instance of constructible. 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. 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".
A revised test driver(attached) uses double instead of value<_a> and value<_b> and it still produces the same error.
Why would that make a difference?
None, now that I've read the doc's more closely. Thanks for pointing me to which doc to read. [snip]
On 07/26/12 11:21, Larry Evans wrote:
On 07/26/12 09:57, Steven Watanabe wrote:
AMDG
On 07/26/2012 07:40 AM, Larry Evans wrote:
On 07/26/12 09:02, Steven Watanabe wrote:
On 07/26/2012 05:29 AM, Larry Evans wrote:
The concept doesn't contain anything that matches an argument of type value<_a>.
Then why isn't a similar compile error produced when b_any is constructed?
This calls a different constructor which has different requirements. Have you read the reference for any? I tried to cover the constructors thoroughly.
My mistake. I didn't notice:
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/...
had:
Concept must contain a matching instance of constructible.
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.
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".
[snip] If detail/construct.hpp is changed as in the attached, then the compile problem in the attached goes away. Is there any reason why construct.hpp shouldn't be changed as shown in the attached? -regards, Larry
AMDG 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. 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. In Christ, Steven Watanabe
On 07/26/12 15:32, Steven Watanabe wrote:
AMDG
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: http://article.gmane.org/gmane.comp.lib.boost.devel/233032 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. -regards, Larry
AMDG On 07/26/2012 04:44 PM, Larry Evans wrote:
On 07/26/12 15:32, Steven Watanabe wrote:
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.
contradicts 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.
The two constructors in question have different requirements because they serve fundamentally different purposes. There are three kinds of constructors: - Constructors that capture an object and create a new set of type bindings. - Constructors that are dispatched using an existing set of type bindings. - Constructors that convert between anys. In Christ, Steven Watanabe
On 07/26/12 11:21, Larry Evans wrote:
On 07/26/12 09:57, Steven Watanabe wrote:
AMDG
On 07/26/2012 07:40 AM, Larry Evans wrote:
On 07/26/12 09:02, Steven Watanabe wrote:
On 07/26/2012 05:29 AM, Larry Evans wrote:
The concept doesn't contain anything that matches an argument of type value<_a>.
Then why isn't a similar compile error produced when b_any is constructed?
This calls a different constructor which has different requirements. Have you read the reference for any? I tried to cover the constructors thoroughly.
My mistake. I didn't notice:
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/...
had:
Concept must contain a matching instance of constructible.
The attached, when compiled with: #define CONSTRUCTIBLE_PH fails compilation despite satisfying this Concept constraint mentioned above. However, when: //#define CONSTRUCTIBLE_PH it compiles & runs OK. The compiling version just doesn't use a placeholder in the args to Sig of constructible. Why doesn't the one with the placeholder in the Sig args compile? Maybe I'm not understanding what's meant by: Concept must contain a matching instance of constructible. Could you please explain what I'm missing? -regards, Larry
AMDG On 07/27/2012 09:49 AM, Larry Evans wrote:
The attached, when compiled with:
#define CONSTRUCTIBLE_PH
fails compilation despite satisfying this Concept constraint mentioned above.
It doesn't satisfy the requirements.
However, when:
//#define CONSTRUCTIBLE_PH
it compiles & runs OK. The compiling version just doesn't use a placeholder in the args to Sig of constructible.
Why doesn't the one with the placeholder in the Sig args compile? Maybe I'm not understanding what's meant by:
Concept must contain a matching instance of constructible.
Could you please explain what I'm missing?
You're passing an argument of type ph_value<_a>. How would constructible<_a(const _a&)> (which is the copy constructor) be viable? In Christ, Steven Watanabe
On 07/27/12 13:08, Steven Watanabe wrote:
AMDG
On 07/27/2012 09:49 AM, Larry Evans wrote:
The attached, when compiled with:
#define CONSTRUCTIBLE_PH
fails compilation despite satisfying this Concept constraint mentioned above.
It doesn't satisfy the requirements.
However, when:
//#define CONSTRUCTIBLE_PH
it compiles & runs OK. The compiling version just doesn't use a placeholder in the args to Sig of constructible.
Why doesn't the one with the placeholder in the Sig args compile? Maybe I'm not understanding what's meant by:
Concept must contain a matching instance of constructible.
Could you please explain what I'm missing?
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>&)> 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/... 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 :( Any help would be appreciated. -regards, Larry
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>.
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/...
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. In Christ, Steven Watanabe
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/...
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
participants (2)
-
Larry Evans -
Steven Watanabe