Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualroadysix

Posted 01 September 2012 - 05:51 PM


I could probably cast the non-const pointer to const but this isn't really desirable.

Overloading to the rescue (how ironic...):
template <typename T> void function(T x)
{ ... }

template <typename T> void function(const T* x)
{ ... }

template <typename T> void function(T* x)
{ function(static_cast<const T *>(x)); }


Incurring the overhead of a proxy function call is also undesirable, where simply being able to partially specialize a function would be favourable.
Alas, as pointed out it is not possible.


Of course, these are all hypothetical needs, and I don't imagine I will come across anything like this in the near future, if ever, though it is still interesting and worth knowing.

Perhaps not in a near future, but they certainly aren't hypothetical. I would say that your example with just an overload for pointer type is a fairly trivial and not totally unexpected example....


Hmm well I would still try to avoid this kind of thing some way or another.




You could try changing the specialization to:

template <> typename std::enable_if<std::is_arithmetic<mytype>::value, mytype>::type func(const mytype& x) noexcept;

I could try this but it would involve specializing is_arithmetic for mytype which is something I don't really want to do. Even still it would only evaluate to true and produce the same problems.

I really doubt you're going to be able to specialize the function if your type doesn't have is_arithmetic<mytype>::value==true . You are allowed to specialize templates in the standard library (under certain conditions). The following code compiles even though the mytype specialization of func doesn't use is_arithmetic:


I soon realized this after posting that reply and decided to go with the function overload. Extending the standard namespace is something I try to avoid, but I am interested in what these "certain conditions" are, if you could explain further.

#2roadysix

Posted 01 September 2012 - 05:46 PM


I could probably cast the non-const pointer to const but this isn't really desirable.

Overloading to the rescue (how ironic...):
template <typename T> void function(T x)
{ ... }

template <typename T> void function(const T* x)
{ ... }

template <typename T> void function(T* x)
{ function(static_cast<const T *>(x)); }


Incurring the overhead of a proxy function call is also undesirable, where simply being able to partially specialize a function would be favourable.
Alas, as pointed out it is not possible.


Of course, these are all hypothetical needs, and I don't imagine I will come across anything like this in the near future, if ever, though it is still interesting and worth knowing.

Perhaps not in a near future, but they certainly aren't hypothetical. I would say that your example with just an overload for pointer type is a fairly trivial and not totally unexpected example....


Hmm well I would still try to avoid this kind of thing some way or another.

#1roadysix

Posted 01 September 2012 - 05:40 PM


I could probably cast the non-const pointer to const but this isn't really desirable.

Overloading to the rescue (how ironic...):
template <typename T> void function(T x)
{ ... }

template <typename T> void function(const T* x)
{ ... }

template <typename T> void function(T* x)
{ function(static_cast<const T *>(x)); }


Incurring the overhead of a proxy function call is also undesirable, where simply being able to partially specialize a function would be favourable.
Alas, as pointed out it is not possible.


Of course, these are all hypothetical needs, and I don't imagine I will come across anything like this in the near future, if ever, though it is still interesting and worth knowing.

Perhaps not in a near future, but they certainly aren't hypothetical. I would say that your example with just an overload for pointer type is a fairly trivial and not totally unexpected example. The rules for determining parameter match to disambiguate a function call, and how templates and overloading interact, can be quite important to know once you start overloading functions even the slightest bit.


Hmm well I would still try to avoid this kind of thing some way or another.

PARTNERS