Re: [boost] [chrono] [dependence of common_type on Boost.TypeOf]
vicente.botet <vicente.botet <at> wanadoo.fr> writes:
Hi again, I have reached to manage with the ambiguous overloads and all the tests works as before. I have do it as follows: <snip code>
That doesn't seem very robust in the case that there is no common type (in terms of the compiler error anyway). Maybe I'm missing something regarding the required semantics, but couldn't something like the following be used, so at least you get a reasonable static assertion error instead? #include <boost/mpl/if.hpp> #include <boost/type_traits/is_base_of.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/static_assert.hpp> template<typename T1, typename T2> struct common_type { typedef typename boost::mpl::if_< boost::is_base_of<T1, T2>, T1, typename boost::mpl::if_< std::is_base_of<T2, T1>, T2, void >::type >::type type; // no common type BOOST_STATIC_ASSERT((!boost::is_same<type, void>::value)); }; template<typename T1> struct common_type<T1, void> { // void is not a valid type BOOST_STATIC_ASSERT(sizeof(T1) != sizeof(T1)); }; template<typename T2> struct common_type<void, T2> { // void is not a valid type BOOST_STATIC_ASSERT(sizeof(T2) != sizeof(T2)); }; (Apologies for messing up the message threading. I post via Gmane, and this thread isn't showing up there, presumably because of the encoding issues in the message subject.)
----- Original Message ----- From: "Adam Merz" <adammerz@hotmail.com> To: <boost@lists.boost.org> Sent: Sunday, August 15, 2010 9:44 AM Subject: Re: [boost][chrono] [dependence of common_type on Boost.TypeOf]
vicente.botet <vicente.botet <at> wanadoo.fr> writes:
Hi again, I have reached to manage with the ambiguous overloads and all the tests works as before. I have do it as follows: <snip code>
That doesn't seem very robust in the case that there is no common type (in terms of the compiler error anyway).
Could you send the compiler error so we can talk of concrete things? Thanks, Vicente
vicente.botet <vicente.botet <at> wanadoo.fr> writes:
----- Original Message ----- From: "Adam Merz" <adammerz <at> hotmail.com> To: <boost <at> lists.boost.org> Sent: Sunday, August 15, 2010 9:44 AM Subject: Re: [boost][chrono] [dependence of common_type on Boost.TypeOf]
vicente.botet <vicente.botet <at> wanadoo.fr> writes:
Hi again, I have reached to manage with the ambiguous overloads and all the tests works as before. I have do it as follows: <snip code>
That doesn't seem very robust in the case that there is no common type (in terms of the compiler error anyway).
Could you send the compiler error so we can talk of concrete things?
Thanks, Vicente
Really? You were just speaking of ambiguity errors yourself... Okay then, two issues I see with a sizeof-based approach as you've shown it: First, it requires that both types be default constructable; otherwise, you get errors like the following (using MSVC10): 1>error C2512: 'Bar::Bar' : no appropriate default constructor available 1> see reference to class template instantiation 'common_type2<T1,T2>' being 1> compiled 1> with 1> [ 1> T1=Foo, 1> T2=Bar 1> ] This can of course be worked around by working in terms of pointers to the provided types rather than the types themselves. Second, if there is no common type, you get potentially confusing ambiguity errors: 1>error C2446: ':' : no conversion from 'Baz' to 'Foo' 1> No constructor could take the source type, or constructor overload 1> resolution was ambiguous 1> see reference to class template instantiation 'common_type2<T1,T2>' being 1> compiled 1> with 1> [ 1> T1=Foo, 1> T2=Baz 1> ] 1>error C2070: ''unknown-type'': illegal sizeof operand Or, if you make the aforementioned pointer changes, you get the even more confusing: 1>error C2446: ':' : no conversion from 'Baz *' to 'Foo *' 1> Types pointed to are unrelated; conversion requires reinterpret_cast, 1> C-style cast or function-style cast 1> see reference to class template instantiation 'common_type2<T1,T2>' being 1> compiled 1> with 1> [ 1> T1=Foo, 1> T2=Baz 1> ] 1>error C2070: ''unknown-type'': illegal sizeof operand The approach I've shown yields a more-familiar static assertion error (which will of course vary in readability depending on your compiler's support for C++0x's static_assert (I've changed the code I posted to use a nested struct no_common_type rather than void for readability purposes): 1>error C2338: (!boost::is_same<type, no_common_type>::value) 1> see reference to class template instantiation 'common_type1<T1,T2>' being 1> compiled 1> with 1> [ 1> T1=Foo, 1> T2=Baz 1> ] Obviously, a named bool or BOOST_MPL_ASSERT_MSG could be used instead to potentially improve readability further.
----- Original Message ----- From: "Adam Merz" <adammerz@hotmail.com> To: <boost@lists.boost.org> Sent: Monday, August 16, 2010 7:23 AM Subject: Re: [boost][chrono] [dependence of common_type on Boost.TypeOf]
vicente.botet <vicente.botet <at> wanadoo.fr> writes:
----- Original Message ----- From: "Adam Merz" <adammerz <at> hotmail.com> To: <boost <at> lists.boost.org> Sent: Sunday, August 15, 2010 9:44 AM Subject: Re: [boost][chrono] [dependence of common_type on Boost.TypeOf]
vicente.botet <vicente.botet <at> wanadoo.fr> writes:
Hi again, I have reached to manage with the ambiguous overloads and all the tests works as before. I have do it as follows: <snip code>
That doesn't seem very robust in the case that there is no common type (in terms of the compiler error anyway).
Could you send the compiler error so we can talk of concrete things?
Thanks, Vicente
Really? You were just speaking of ambiguity errors yourself...
Okay then, two issues I see with a sizeof-based approach as you've shown it: First, it requires that both types be default constructable; otherwise, you get errors like the following (using MSVC10):
1>error C2512: 'Bar::Bar' : no appropriate default constructor available 1> see reference to class template instantiation 'common_type2<T1,T2>' being 1> compiled 1> with 1> [ 1> T1=Foo, 1> T2=Bar 1> ]
This can of course be worked around by working in terms of pointers to the provided types rather than the types themselves. Second, if there is no common type, you get potentially confusing ambiguity errors:
I will take care of this.
Or, if you make the aforementioned pointer changes, you get the even more confusing:
1>error C2446: ':' : no conversion from 'Baz *' to 'Foo *' 1> Types pointed to are unrelated; conversion requires reinterpret_cast, 1> C-style cast or function-style cast 1> see reference to class template instantiation 'common_type2<T1,T2>' being 1> compiled 1> with 1> [ 1> T1=Foo, 1> T2=Baz 1> ] 1>error C2070: ''unknown-type'': illegal sizeof operand
I find the message no so confusing: "Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast" and common_type2<T1,T2> appears also in the message. What others think? Best, Viecnte
vicente.botet wrote:
Adam Merz wrote:
Or, if you make the aforementioned pointer changes, you get the even more confusing:
1>error C2446: ':' : no conversion from 'Baz *' to 'Foo *' 1> Types pointed to are unrelated; conversion requires reinterpret_cast, 1> C-style cast or function-style cast 1> see reference to class template instantiation 'common_type2<T1,T2>' being 1> compiled 1> with 1> [ 1> T1=Foo, 1> T2=Baz 1> ] 1>error C2070: ''unknown-type'': illegal sizeof operand
I find the message no so confusing: "Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast" and common_type2<T1,T2> appears also in the message.
One issue is that the user may have written nothing in terms of Baz * or Foo *. The use of pointers in this context is an implementation detail. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (3)
-
Adam Merz -
Stewart, Robert -
vicente.botet