Jump to content

  • Log In with Google      Sign In   
  • Create Account


Metafunction to check whether a template specialization exists


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 kloffy   Members   -  Reputation: 882

Like
0Likes
Like

Posted 14 March 2013 - 01:06 PM

This should be pretty basic template meta programming, but everything I have found on Google isn't quite the thing I am looking for. Suppose I have a template with an empty body that users can specialize: 

template<typename Target, typename Source, typename Enable = void>
struct conversion
{
	static const bool value = false;

	static Target to(Source const& value);
	static Source from(Target const& value);
};

 

And a possible specialization might look like this:

template<typename Target>
struct conversion<Target, std::string>
{
	static const bool value = true;

	static Target to(std::string const& value)
	{
		return boost::lexical_cast<Target>(value);
	}

	static std::string from(Target const& value)
	{
		return boost::lexical_cast<std::string>(value);
	}
};

 

Now, I can check whether a conversion exists by checking conversion<Target, Source>::value. However, I would like to simplify this further, eliminating the need to explicitly define the integral value constant. This can probably be done using a check like sizeof(?) == sizeof(char). However, since there are a few pitfalls, I wonder if someone could point me towards the "best practice" approach.


Edited by kloffy, 14 March 2013 - 01:08 PM.


Sponsor:

#2 SiCrane   Moderators   -  Reputation: 9490

Like
1Likes
Like

Posted 14 March 2013 - 01:10 PM

I don't know about best practice, but one way you can do this is have the non specialized template inherit from a class, and not have the specialized versions inherit from this class. Then you can check if a conversion to this base exists in place of checking the value member.

#3 kloffy   Members   -  Reputation: 882

Like
0Likes
Like

Posted 14 March 2013 - 01:23 PM

 don't know about best practice, but one way you can do this is have the non specialized template inherit from a class, and not have the specialized versions inherit from this class. Then you can check if a conversion to this base exists in place of checking the value member.

 

Ok, makes sense! It still feels like there should be a more "direct" solution, but that would certainly work.



#4 kloffy   Members   -  Reputation: 882

Like
0Likes
Like

Posted 14 March 2013 - 02:58 PM

Ok, so here is an alternative. The static member function check is still pretty ugly (a lot of code duplication). Luckily, the "client" never has to look at it.

template<typename Target, typename Source>
struct is_convertible_to
{
private:
	template<class U, class Enable = typename std::enable_if<!std::is_member_pointer<decltype(&U::to)>::value>::type>
	static std::true_type check(int);
	template<class U>
	static std::false_type check(...);

public:
	typedef decltype(check<conversion<Target, Source>>(0)) type;
	static const bool value = type::value;
};

template<typename Target, typename Source>
struct is_convertible_from
{
private:
	template<class U, class Enable = typename std::enable_if<!std::is_member_pointer<decltype(&U::from)>::value>::type>
	static std::true_type check(int);
	template<class U>
	static std::false_type check(...);

public:
	typedef decltype(check<conversion<Target, Source>>(0)) type;
	static const bool value = type::value;
};

 

Now, one can write the following functions:

template<typename Target, typename Source, typename Enable = void>
struct conversion
{
	//static Target to(Source const& value);
	//static Source from(Target const& value);
};

template<typename Target, typename Source>
typename std::enable_if<is_convertible_to<Target, Source>::value, Target>::type
conversion_cast(Source const& value)
{
	return conversion<Target, Source>::to(value);
}

template<typename Target, typename Source>
typename std::enable_if<!is_convertible_to<Target, Source>::value && is_convertible_from<Source, Target>::value, Target>::type
conversion_cast(Source const& value)
{
	return conversion<Source, Target>::from(value);
}

 

Finally, all this work is to allow the user to write conversions as specializations of the conversion template. Here is a trivial example:

template<>
struct conversion<int, float>
{
	static int to(float const& value)
	{
		return static_cast<int>(value);
	}

	static float from(int const& value)
	{
		return static_cast<float>(value);
	}
};

 

Which would be used as follows:

conversion_cast<int>(1.0f);
conversion_cast<float>(1);

 

So, the point of conversion_cast is to be extensible to arbitrary user defined types. The motivation was that I was integrating different libraries, which required conversions back and forth between types within those libraries. This seems like pretty basic stuff. Am I reinventing the wheel?


Edited by kloffy, 14 March 2013 - 03:07 PM.


#5 kloffy   Members   -  Reputation: 882

Like
0Likes
Like

Posted 14 March 2013 - 03:29 PM

Of course, now that I think about it, this might be a much more elegant solution:
template<typename Target, typename Source, typename Enable = void>
struct conversion
{
	static_assert(sizeof(Target) == 0 || sizeof(Source) == 0, "Must specialize conversion!");

	Target operator()(Source const& value) const;
};

template<typename Target, typename Source, typename Conversion = conversion<Target, Source>>
Target conversion_cast(Source const& value, Conversion conversion = Conversion())
{
	return conversion(value);
}

template<>
struct conversion<int, float>
{
	int operator()(float const& value) const
	{
		return static_cast<int>(value);
	}
};

template<>
struct conversion<float, int>
{
	float operator()(int const& value) const
	{
		return static_cast<float>(value);
	}
};
 
The only "downside" is that the "to" and "from" conversions are no longer grouped together. I guess both operations go hand in hand, so I wanted to motivate users to write both. However, it caused more problems than it solved (especially since the previous code does not enforce that both functions are present either).

Edited by kloffy, 14 March 2013 - 04:48 PM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS