[type_erasure]any(U,static_binding) stores wrong type
When the attached is run, it produces output: ./static_binding.exe std::is_copy_constructible<ph_erasee_type>=0 53:ph_ctor_arg<boost::type_erasure::_a>::CTOR.default:my_instance=0 creating a_fst from a_ctor_arg 64:ph_ctor_arg<boost::type_erasure::_a>::CTOR.copy:my_instance=1:(void*)this=0x66ab50 :*fst_cast=ph_erasee<boost::type_erasure::_a>.my_instance=0:(void*)fst_cast=0x66ab50 dynamic_cast<ph_ctor_arg_type*>(value_base_ptr)=0x66ab50 dynamic_cast<ph_erasee_type*>(value_base_ptr)=0 Indicating that a ph_ctor_arg_type is being stored in a_fst instead of the expected ph_erasee_type. -regards, Larry
On 07/29/12 08:06, Larry Evans wrote:
When the attached is run, it produces output:
./static_binding.exe std::is_copy_constructible<ph_erasee_type>=0 53:ph_ctor_arg<boost::type_erasure::_a>::CTOR.default:my_instance=0 creating a_fst from a_ctor_arg 64:ph_ctor_arg<boost::type_erasure::_a>::CTOR.copy:my_instance=1:(void*)this=0x66ab50 :*fst_cast=ph_erasee<boost::type_erasure::_a>.my_instance=0:(void*)fst_cast=0x66ab50 dynamic_cast<ph_ctor_arg_type*>(value_base_ptr)=0x66ab50 dynamic_cast<ph_erasee_type*>(value_base_ptr)=0
Indicating that a ph_ctor_arg_type is being stored in a_fst instead of the expected ph_erasee_type.
OOPS, reading more closely the requires from: it says: U is a model of Concept. and obviously ph_ctor_arg_type is not because it occurs nowhere in ConceptA; however, it would be clearer if the requirement were: U is a suitable argument to the copy constructor for mpl::map<Map, Tag>::type, where Tag is the 2nd template arg to the any to be constructed. -regards, Larry
On 07/29/12 09:48, Larry Evans wrote:
On 07/29/12 08:06, Larry Evans wrote:
When the attached is run, it produces output:
./static_binding.exe std::is_copy_constructible<ph_erasee_type>=0 53:ph_ctor_arg<boost::type_erasure::_a>::CTOR.default:my_instance=0 creating a_fst from a_ctor_arg 64:ph_ctor_arg<boost::type_erasure::_a>::CTOR.copy:my_instance=1:(void*)this=0x66ab50 :*fst_cast=ph_erasee<boost::type_erasure::_a>.my_instance=0:(void*)fst_cast=0x66ab50 dynamic_cast<ph_ctor_arg_type*>(value_base_ptr)=0x66ab50 dynamic_cast<ph_erasee_type*>(value_base_ptr)=0
Indicating that a ph_ctor_arg_type is being stored in a_fst instead of the expected ph_erasee_type.
OOPS, reading more closely the requires from:
it says:
U is a model of Concept.
and obviously ph_ctor_arg_type is not because it occurs nowhere in ConceptA; however, it would be clearer if the requirement were:
U is a suitable argument to the copy constructor for mpl::map<Map, Tag>::type, where Tag is the 2nd template arg to the any to be constructed.
OOPS again, because a ph_ctor_arg_type *is* a suitable arg to ph_erasee_type. Maybe the requirement should just be: U is same as mpl::at<Map, Tag>::type where Tag is 2nd template arg to the any being constructed and U is a model of Concept. I think that would cover all the cases; however, it's still worrisome that no diagnostic is provided when U is something other than mpl::at<Map,Tag>::type. Am I missing something? -regards, Larry
On 07/29/12 10:06, Larry Evans wrote:
On 07/29/12 09:48, Larry Evans wrote:
On 07/29/12 08:06, Larry Evans wrote:
When the attached is run, it produces output:
./static_binding.exe std::is_copy_constructible<ph_erasee_type>=0 53:ph_ctor_arg<boost::type_erasure::_a>::CTOR.default:my_instance=0 creating a_fst from a_ctor_arg 64:ph_ctor_arg<boost::type_erasure::_a>::CTOR.copy:my_instance=1:(void*)this=0x66ab50 :*fst_cast=ph_erasee<boost::type_erasure::_a>.my_instance=0:(void*)fst_cast=0x66ab50 dynamic_cast<ph_ctor_arg_type*>(value_base_ptr)=0x66ab50 dynamic_cast<ph_erasee_type*>(value_base_ptr)=0
Indicating that a ph_ctor_arg_type is being stored in a_fst instead of the expected ph_erasee_type.
OOPS, reading more closely the requires from:
it says:
U is a model of Concept.
and obviously ph_ctor_arg_type is not because it occurs nowhere in ConceptA; however, it would be clearer if the requirement were:
U is a suitable argument to the copy constructor for mpl::map<Map, Tag>::type, where Tag is the 2nd template arg to the any to be constructed.
OOPS again, because a ph_ctor_arg_type *is* a suitable arg to ph_erasee_type. Maybe the requirement should just be:
U is same as mpl::at<Map, Tag>::type where Tag is 2nd template arg to the any being constructed and U is a model of Concept.
I think that would cover all the cases; however, it's still worrisome that no diagnostic is provided when U is something other than mpl::at<Map,Tag>::type.
Am I missing something?
with the any diffs shown in 1st attachment, the output of 2nd attachment is: ./static_binding.exe std::is_copy_constructible<ph_erasee_type>=0 55:ph_ctor_arg<boost::type_erasure::_a>::CTOR.default:my_instance=0 creating a_fst from a_ctor_arg 101:ph_erasee<boost::type_erasure::_a>::CTOR.(const ph_ctor_arg<boost::type_erasure::_a>&):my_instance=0:(void*)this=0x19f4b50 :*fst_cast=ph_erasee<boost::type_erasure::_a>.my_instance=0:(void*)fst_cast=0x19f4b50 typeid(*fst_cast).name()=ph_erasee<boost::type_erasure::_a> Showing that the expected type, i.e. ph_erasee<_a>, is created. The any change makes sure to create the expected type, mpl::at<Map,T>::type with help of new template function: make_storage<Constructee, U&...> which constructs, a Constructee. I think this would avoid some nasty suprises with the wrong arg type, U, is accidentally passed to the any<U,static_binding>. If U is a valid CTOR arg to the expected type, no error would be issued, but type_cast would return a pointer to the expected type even though the actual type created was a U. HTH. -regards, Larry w
On 07/29/12 12:07, Larry Evans wrote:
On 07/29/12 09:48, Larry Evans wrote:
On 07/29/12 08:06, Larry Evans wrote: [snip] with the any diffs shown in 1st attachment,
On 07/29/12 10:06, Larry Evans wrote: the output of 2nd attachment is:
./static_binding.exe std::is_copy_constructible<ph_erasee_type>=0 55:ph_ctor_arg<boost::type_erasure::_a>::CTOR.default:my_instance=0 creating a_fst from a_ctor_arg 101:ph_erasee<boost::type_erasure::_a>::CTOR.(const ph_ctor_arg<boost::type_erasure::_a>&):my_instance=0:(void*)this=0x19f4b50 :*fst_cast=ph_erasee<boost::type_erasure::_a>.my_instance=0:(void*)fst_cast=0x19f4b50 typeid(*fst_cast).name()=ph_erasee<boost::type_erasure::_a>
Showing that the expected type, i.e. ph_erasee<_a>, is created. The any change makes sure to create the expected type, mpl::at<Map,T>::type with help of new template function:
make_storage<Constructee, U&...>
which constructs, a Constructee.
[snip] Moving this make_storage to within the any definition allows slightly less boilerplate coding, resulting in a diff with the svn any.hpp shown in attached. HTH. -regards, Larry
AMDG On 07/29/2012 06:06 AM, Larry Evans wrote:
When the attached is run, it produces output:
./static_binding.exe std::is_copy_constructible<ph_erasee_type>=0 53:ph_ctor_arg<boost::type_erasure::_a>::CTOR.default:my_instance=0 creating a_fst from a_ctor_arg 64:ph_ctor_arg<boost::type_erasure::_a>::CTOR.copy:my_instance=1:(void*)this=0x66ab50 :*fst_cast=ph_erasee<boost::type_erasure::_a>.my_instance=0:(void*)fst_cast=0x66ab50 dynamic_cast<ph_ctor_arg_type*>(value_base_ptr)=0x66ab50 dynamic_cast<ph_erasee_type*>(value_base_ptr)=0
Indicating that a ph_ctor_arg_type is being stored in a_fst instead of the expected ph_erasee_type.
I already noticed this bug, but I haven't figured out what the correct behavior should be yet. In Christ, Steven Watanabe
On 07/29/12 19:07, Steven Watanabe wrote:
AMDG
On 07/29/2012 06:06 AM, Larry Evans wrote:
When the attached is run, it produces output:
./static_binding.exe std::is_copy_constructible<ph_erasee_type>=0 53:ph_ctor_arg<boost::type_erasure::_a>::CTOR.default:my_instance=0 creating a_fst from a_ctor_arg 64:ph_ctor_arg<boost::type_erasure::_a>::CTOR.copy:my_instance=1:(void*)this=0x66ab50 :*fst_cast=ph_erasee<boost::type_erasure::_a>.my_instance=0:(void*)fst_cast=0x66ab50 dynamic_cast<ph_ctor_arg_type*>(value_base_ptr)=0x66ab50 dynamic_cast<ph_erasee_type*>(value_base_ptr)=0
Indicating that a ph_ctor_arg_type is being stored in a_fst instead of the expected ph_erasee_type.
I already noticed this bug, but I haven't figured out what the correct behavior should be yet.
Anything wrong with the behavior shown here: http://article.gmane.org/gmane.comp.lib.boost.devel/233093 ? -regards, Larry
participants (2)
-
Larry Evans -
Steven Watanabe