[typeof] Determining if a type has been registered or not at compile time
Is there any way one can determine whether a type has been registered or not with Boost.Typeof at compile time so that the information can be used in TMP ? I am thinking, of course, of the use of typeof in a template, where a template parameter may or may not be aregistered type when the template has been instantiated. I would like to provide my own TMP fallback code if the type has not been registered rather than see an immediate compiler error generated. Something like: boost::mpl::eval_if < boost::typeof::registered<T>, // this would be nice to have boost::mpl::identity<BOOST_TYPEOF_TPL(some_expression)>, boost::mpl::identity</* use another facility to get the type I want into a metafunction*/>
2009/12/22 Edward Diener <eldiener@tropicsoft.com>
Is there any way one can determine whether a type has been registered or not with Boost.Typeof at compile time so that the information can be used in TMP ? I am thinking, of course, of the use of typeof in a template, where a template parameter may or may not be aregistered type when the template has been instantiated. I would like to provide my own TMP fallback code if the type has not been registered rather than see an immediate compiler error generated. Something like:
Here is a possible implementation of boost::typeof::is_registered:
namespace boost { namespace type_of { class AllTypesRegisteredVector {}; class NotAllTypesRegisteredVector {}; template<typename V> struct vector_handler { template<typename Type_Not_Registered_With_Typeof_System> struct handle_unregistered_type; }; template<> struct vector_handler<AllTypesRegisteredVector> { template<typename T> struct handle_unregistered_type { typedef NotAllTypesRegisteredVector type; }; }; template<> struct vector_handler<NotAllTypesRegisteredVector> { template<typename T> struct handle_unregistered_type { typedef NotAllTypesRegisteredVector type; }; }; template<class T> struct push_back<NotAllTypesRegisteredVector,T> { typedef NotAllTypesRegisteredVector type; }; template<class T> struct push_back<AllTypesRegisteredVector,T> { typedef AllTypesRegisteredVector type; }; }} BOOST_TYPEOF_BEGIN_ENCODE_NS template<class V,class T> struct encode_type_impl { typedef typename boost::type_of::vector_handler<V>::handle_unregistered_type<T>::type type; }; BOOST_TYPEOF_END_ENCODE_NS namespace boost {namespace type_of { template<typename T> struct is_registered : boost::is_same<AllTypesRegisteredVector,typename encode_type<AllTypesRegisteredVector,T>::type> {}; }}
boost::mpl::eval_if < boost::typeof::registered<T>, // this would be nice to have boost::mpl::identity<BOOST_TYPEOF_TPL(some_expression)>, boost::mpl::identity</* use another facility to get the type I want into a metafunction*/>
The problem is that BOOST_TYPEOF_TPL is evaluated even if is_registered is false. One way to workaroun this is to allow the user to add a default type: typedef BOOST_TYPEOF_WITH_DEFAULT(some_expression,some_backup_type_if_some_expression_not_registered) type; Is this acceptable? _______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt wrote:
2009/12/22 Edward Diener <eldiener@tropicsoft.com>
Is there any way one can determine whether a type has been registered or not with Boost.Typeof at compile time so that the information can be used in TMP ? I am thinking, of course, of the use of typeof in a template, where a template parameter may or may not be aregistered type when the template has been instantiated. I would like to provide my own TMP fallback code if the type has not been registered rather than see an immediate compiler error generated. Something like:
Here is a possible implementation of boost::typeof::is_registered: snipped...
boost::mpl::eval_if < boost::typeof::registered<T>, // this would be nice to have boost::mpl::identity<BOOST_TYPEOF_TPL(some_expression)>, boost::mpl::identity</* use another facility to get the type I want into a metafunction*/>
The problem is that BOOST_TYPEOF_TPL is evaluated even if is_registered is false.
You are right and I had not realized this until you mentioned it. So 'registered' metafunction does little good for my proposed situation.
One way to workaroun this is to allow the user to add a default type: typedef BOOST_TYPEOF_WITH_DEFAULT(some_expression,some_backup_type_if_some_expression_not_registered) type;
Is this acceptable?
Yes, that seems the best solution. An excellent idea. Should I create a Trac suggestion for it or will you remember to implement it if you decide to do it ? If you do this, I think you will want to do it for TYPEOF_TPL also. I see much less use for AUTO and AUTO_TPL defaults if the type is not registered but I think you should also implement it for these two also both to be orthogonal and for the possibility that someone will find a use there also.
One way to workaroun this is to allow the user to add a default type:
typedef
BOOST_TYPEOF_WITH_DEFAULT(some_expression,some_backup_type_if_some_expression_not_registered) type;
Is this acceptable?
Yes, that seems the best solution. An excellent idea. Should I create a Trac suggestion for it or will you remember to implement it if you decide to do it ? If you do this, I think you will want to do it for TYPEOF_TPL also. I see much less use for AUTO and AUTO_TPL defaults if the type is not registered but I think you should also implement it for these two also both to be orthogonal and for the possibility that someone will find a use there also.
I will remember :) I am, however, not sure about the proper name for this beast. Also, I am a bit uncertain about the best behaviour: I see mainly two options: 1) typedef BOOST_TYPEOF_WITH_DEFAULT(expression,typename some_alternative_expression::type) type; 2) typedef BOOST_TYPEOF_WITH_DEFAULT(expression,no_type) deduced_type; typedef mpl::eval_if< boost::is_same<deduced_type,no_type>, boost::mpl::identity<deduced_type>, some_alternative_expression
::type type;
In the second alternative we could simplify the name to BOOST_SAFE_TYPEOF(expression) or BOOST_NONFAILING_TYPEOF(expression) or BOOST_TYPEOF_OR_NONE(expression) or BOOST_Your_idea_goes_here(expression) And, yes, I agree that this should be implemented for TPL. Only the first alternative can be implemented with AUTO... Another alternative is to implement alternative 1 an then alternative 2 by using alternative 1. I am still unsure about the name. BOOST_TYPEOF_WITH_DEFAULT seems a very long name, and not overly descriptive either. Regards Peder
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt wrote:
One way to workaroun this is to allow the user to add a default type:
typedef
BOOST_TYPEOF_WITH_DEFAULT(some_expression,some_backup_type_if_some_expression_not_registered) type;
Is this acceptable?
Yes, that seems the best solution. An excellent idea. Should I create a Trac suggestion for it or will you remember to implement it if you decide to do it ? If you do this, I think you will want to do it for TYPEOF_TPL also. I see much less use for AUTO and AUTO_TPL defaults if the type is not registered but I think you should also implement it for these two also both to be orthogonal and for the possibility that someone will find a use there also.
I will remember :) I am, however, not sure about the proper name for this beast. Also, I am a bit uncertain about the best behaviour:
I see mainly two options: 1) typedef BOOST_TYPEOF_WITH_DEFAULT(expression,typename some_alternative_expression::type) type;
I assume the second parameter is any user-specified type.
2) typedef BOOST_TYPEOF_WITH_DEFAULT(expression,no_type) deduced_type; typedef mpl::eval_if< boost::is_same<deduced_type,no_type>, boost::mpl::identity<deduced_type>, some_alternative_expression
::type type;
In the second alternative we could simplify the name to BOOST_SAFE_TYPEOF(expression) or BOOST_NONFAILING_TYPEOF(expression) or BOOST_TYPEOF_OR_NONE(expression) or BOOST_Your_idea_goes_here(expression)
And, yes, I agree that this should be implemented for TPL. Only the first alternative can be implemented with AUTO...
Another alternative is to implement alternative 1 an then alternative 2 by using alternative 1. I am still unsure about the name. BOOST_TYPEOF_WITH_DEFAULT seems a very long name, and not overly descriptive either.
I would suggest 1) to allow the end-user to specify the default type if the expression's type can not be deduced. I would also suggest in 2) the BOOST_SAFE_TYPEOF(expression) where you supply a 'boost::typeof::no_type' type ( as an empty struct ) automatically if the expression's type can not be deduced. This way you give the end-user the most flexibility. Needless to say the 'boost::typeof::no_type' should be available for the end-user to use also in the BOOST_TYPEOF_WITH_DEFAULT case if he chooses ( within a boost::mpl::identity of course ). I think BOOST_TYPEOF_WITH_DEFAULT is fine as a name and BOOST_SAFE_TYPEOF is decent also. I personally always seek clarity in a name and never a clever shortness, but whatever names you choose I am sure will be fine. For the TPL names I would simply append _TPL to the end of the TYPEOF word in both cases, giving you BOOST_TYPEOF_TPL_WITH_DEFAULT and BOOST_SAFE_TYPEOF_TPL. As far as the BOOST_AUTO and BOOST_AUTO_TPL cases, although I see little practical use for the generation of a variable of the fallback type, I do not see technically why you can not have both cases with that also, as long as 'boost::typeof::no_type' is a valid type, but I am guessing you see something that I do not see. So I see no reason why you could not have BOOST_AUTO_WITH_DEFAULT(var,expression,alternative_type) and BOOST_SAFE_AUTO(var,expression) along with their TPL forms of BOOST_AUTO_TPL_WITH_DEFAULT(var,expression,alternative_type) and BOOST_SAFE_AUTO_TPL(var,expression).
participants (2)
-
Edward Diener -
Peder Holt