struct A
{
template <class U>
void f(U)
{
}
};
template <class T>
void f(T t)
{
A a;
a.template f<int>(t);
a.template f<>(t);
a.f<int>(t);
a.f<>(t);
a.f(t);
}
At least under MSVC2010 the above code compile fine.
Among all the manners to call A.f is there any preferentials way to do this?
Is there any differences ?
Well, a has type A, which is not a dependent type in this context. So the template keyword is not needed and only serves to obfuscate the code -- don't use it.
The version that invokes a template without supplying any arguments, again does nothing to change behavior and only makes the code less readable -- don't use it either.
Between the two remaining candidates, a.f(t) and a.f<int>(t), use the first in most cases, and the second if the compiler fails to deduce the type.
The last one seems easiest to write.
Otherwise there are no differences, unless you have to disambiguate between several f's.
No differences at all. If you don't have any reason to provide type information to the function, the last one is the best. But you may want your function to process arguments as if they are of the specified type, only then, should you need <>. For example
T Divide(T a, T b)
{
return a/b;
}
If you call Divide(5,2), you get 2. Only cases like this, should you specify type:
Divide<float>(5,2);
It returns 2.5.
Related
I can infer template parameters with function parameters
template <typename T>
void f(T a)
{ /* */ }
f(4); // T inferred to be `int`
However I can't use function parameters to infer template parameters, which aren't types:
template <int I>
void g(int I) // error: declaration of 'I' shadows template parameter
{ /* */ }
Let's say I want to write a function divive_dy_2(int number) and I want to make sure number is not zero.
I've seen a very simple way to do this, which would require me to pass the argument to a template parameter, which then would use SFINAE to disable it, if it was 0.
But it feels counter-intuitive to expose something like this in an API. Is there some workaround?
(And yes, I could use exceptions and what not, what would probably even be a better idea, but I'm learning SFINAE at the moment and want to know where it's limits are)
If your argument is known at compile time, you do not even need sfinae for your check - a simple assert will provide much better diagnostics.
However, if the argument is not known (which is more likely scenario) than you can not make it template argument, and you have to use exceptions or return error code to indicate that provided argument is outside of supported domain.
Think of template as smth the same as #define
If you want to use 4 as template argument, it's roughly
template <int I>
void g()
{ ... here use I as _value_, not type}
You can quickly look in Alexandrescu's C++ book for a longer discussion, how to use values in template arguments.
How can I in C++ make a function accept every Object, so I can give it numbers, String or other Objects. I am not very well in C++, I hope it's not a totally stupid question...
Edit: Ok, an example: if you want to try to wrap the std::cout streams into normal functions, that funtion should be able to accept everything - from Integers over Floats to complex Objects. I hope it's more clear now!
You can overload your function for different types, i.e.
size_t func(int);
size_t func(std::string);
Alternatively and/or additionally, you can provide a function template, which is a way to tell the compiler how to generate your function for any particular type, for example
template<typename T>
size_t func(T const&) { return sizeof(T); }
You may use more advanced techniques such as SFINAE to effectively overload those template functions, i.e. to use different templates for different kind of types T (i.e. integral types, pointer, built-in types, pod, etc). The compiler will then pick the best-fitting func() (if any) for any function call it encounters and, if this is a template, generate an appropriate function.
This requires no re-coding.
A completely different approach is to use a generic erasure type, such as boost::any, when the function will need to resolve the expected types at coding-time (as opposed to compile-time):
size_t func(boost::any const&x)
{
auto i = boost::any_cast<const int*>(x);
if(i) return func(*i);
// etc for other types, but this must be done at coding time!
}
You can use templates for this purpose:
template <typename T>
void foo(T const & value)
{
// value is of some type T, which can be any type at all.
}
What you can actually do with the value may be rather limited without knowing its type -- it depends on the goal of your function. (If someone attempts to call the function with an argument type that causes that function specialization to be ill-formed then your template function will fail to instantiate and it will be a compile-time error.)
I'm not sure what you're trying to accomplish, but you can pass a void pointer as a parameter.
void foo(void* bar);
If I understood you correctly you might wanna try using templates http://en.cppreference.com/w/cpp/language/function_template
You are probably looking for templates.
I suggest you read this.
I've been playing around with C++0x's auto keyword and tried the following.
std::unique_ptr<auto> ptr(new int(0));
I tried compiling it with g++ 4.4.5 and got
error: invalid use of auto
Judging by eye, auto can easily be inferred to int.
My guess is the type inference and the template engine don't talk to each other. Otherwise, the template engine would know to instantiate the template class with int as the type parameter.
Another guess is from the standard, I see this.
A member shall not be declared with auto, extern or register storage class.
But I thought that was the auto as in local variables, not as in auto used to deduce types.
And my last guess is that the compiler thinks this is an auto storage class, not auto for type deduction.
Is there a reason behind this stated in the standard?
That's because it has to determine the class on which to call a constructor before determining what to do with its arguments. If you make the constructor a template, it'll just work like any other template function - auto-deducing arguments.
#dascandy has correctly identified what's wrong with your code. I'll try to provide some rationale:
You're expecting the compiler to infer unique_ptr<int> because the argument is an int*, and unique_ptr<int> has a constructor which accepts int*. For a moment let's ignore the fact that we're using std::unique_ptr, and just talk about a template class we wrote (and can specialize).
Why should the compiler infer unique_ptr<int>? The argument isn't int, it's int*. Why shouldn't it guess unique_ptr<int*>? Of course that would result in a compiler error, since unique_ptr<int*>'s constructor won't accept an int*. Unless I add a specialization:
template<>
class unique_ptr<int*>
{
public:
unique_ptr(int*) {}
};
Now unique_ptr<int*> would compile. How should the compiler know which to choose, unique_ptr<int> or unique_ptr<int*>? What if I add another specialization?
template<>
class unique_ptr<double>
{
public:
unique_ptr(int*) {}
};
The compiler now has three options to choose from, and it has to instantiate the template with every possible argument in order to find them. Clearly this is not feasible, especially with multiple template arguments and template recursion.
What you can do, is make a factory function which connects the inferred type to exactly one template instance:
template<typename T>
std::unique_ptr<T> make_unique(T* arg) { return arg; }
(of course, this won't work because unique_ptr cannot be copied. But the idea is valid, and used in e.g.make_shared and make_pair.)
Some examples of extreme ugliness:
One could argue that unique_ptr<shared_ptr<int>> is a valid match for this code.
Or how about:
template<typename T>
class unique_ptr
{
public:
explicit unique_ptr(T* arg);
unique_ptr(int*, enable_if<(sizeof(T) > 16)>::type* = 0);
};
Just want to add that a solution already exists for most cases:
template <typename T>
std::unique_ptr<T> unique_ptr_auto(T* ptr)
{
// fails to handle std::unique_ptr<T[]>, not deducible from pointer
return std::unique_ptr<T>(ptr);
}
auto ptr = unique_ptr_auto(new int(0));
A bit more verbose, obviously, but you get the idea. These "generator functions" are quite common.
This (or similar) was proposed for the Standard. The proposed functionality looked something like:
std::vector<int> GetMahVector();
std::vector<auto> var = GetMahVector();
However, it was rejected. Why it was rejected, well, you'd have to dig up the relevant Standard process documents, if possible.
Look at the following test code:
template<class T> struct Wrap {};
template<typename T> inline
void fun (T *&Int) // **choice 1**
{}
template<typename T> inline
void fun (Wrap<T> *&Int) // **choice 2**
{}
int main()
{
int i = 6;
fun((char*&)(i)); // **call 1**
fun((Wrap<char>*&)(i)); // **call 2**
}
When I run this code in linux g++, it works as per expectations. When fun() is called with char*&, it calls function of choice 1 straight forward.
However, I am interested when we call fun() with Wrap< char >*& and it calls the choice 2. Even though choice 1 and 2 both appear valid for the 2nd call, compiler manages to choose little better contender -> choice 2 (because it exists).
Question: Is it guaranteed that, the same behavior will be retained for any other compiler for C++ ? If not, then is there any other alternative to make it deterministic?
The second choice is chosen because it's more specialized than the first- that is, T*& can bind to any non-temporary T*, but Wrap<T>*& can only bind to a non-temporary Wrap<T>*. This is Standard as far as I know and should be portable behaviour but what is and isn't portable in practice when it comes to this sort of thing is often not the definition of what's Standard.
Someone with a better knowledge of the spec can confirm this, but I believe that as Wrap<T> is a more specific type than simply T, call 2 will always resolve to 'choice 2', on all platforms compilers.
While the code might look like a template specialization, that is not the case. The language does not allow for partial template function specializations. The two are unrelated templates that happen to be overloads.
The compiler will lookup up the call to fun( (Wrap<char>*&) i ) with the usual lookup mechanisms, will find the two templates and will determine that there are two potential overloads:
template <typename T> void fun( T*& ); // with T == Wrap<char>
template <typename T> void fun( Wrap<T>*& ) // with T == char
Overload resolution will then determine that the second is a better match and instantiate it. This is guaranteed by the standard, but beware: they are not the same template, but rather different templates and you might run into undexpected results. Look at the article #LiKao linked for more insight.
One thing that might make this even more problematic is, that the rules for specializing template classes and template functions differ a lot. This is do to the possibility of overloading template functions while there is no possibility of overloading classes. Because I am not so firm on this topic I will just link to someone who is able to explain it in more depth:
Herb Sutter: "Why Not Specialize Function Templates?"
If we've this function template,
template<typename T>
void f(T param) {}
Then we can call it in the following ways,
int i=0;
f<int>(i);//T=int : no need to deduce T
f(i); //T=int : deduced T from the function argument!
//likewise
sample s;
f(s); //T=sample : deduced T from the function argument!
Now consider this variant of the above function template,
template<typename TArg, typename TBody>
void g(TArg param)
{
TBody v=param.member;
}
Now, can the compiler deduce the template arguments if we write,
sample s;
g(s); //TArg=sample, TBody=int??
Suppose sample is defined as,
struct sample
{
int member;
};
There are basically two questions:
Can the compiler deduce the template arguments in the second example?
If no, then why? Is there any difficulty? If the Standard doesn't say anything about "template argument deduction from function body", then is it because the argument(s) cannot be deduced? Or it didn't consider such deduction so as to avoid adding more complexity to the language? Or what?
I would like know your views on such deduction.
EDIT:
By the way, the GCC is able to deduce function arguments if we write this code:
template<typename T>
void h(T p)
{
cout << "g() " << p << endl;
return;
}
template<typename T>
void g(T p)
{
h(p.member); //if here GCC can deduce T for h(), then why not TBody in the previous example?
return;
}
Working demonstration for this example : http://www.ideone.com/cvXEA
Not working demonstration for the previous example: http://www.ideone.com/UX038
You probably already concluded that the compiler won't deduce TBody by examining the type of sample.member. This would add yet another level of complexity to the template deduction algorithm.
The template matching algorithm only considers function signatures, not their bodies. While not used too often, it's perfectly legal to simply declare a templated function without providing the body:
template <typename T> void f(T param);
This satisfies the compiler. In order to satisfy the linker, you must of course also define the function body somewhere, and ensure that all required instantiations have been provided. But the function body does not necessarily have to be visible to client code of the template function, as long as the required instantiations are available at link time. The body would have to explicitly instantiate the function, eg:
template <> void f(int param);
But this only partially applies to your questions, because you could imagine a scenario like the following, where a 2nd parameter could be deduced from the a provided default parameter, and which won't compile:
template<typename TArg, typename TBody>
void g(TArg param, TBody body = param.member); // won't deduce TBody from TArg
The template matching algorithm considers only the actual type, not any potential nested member types in case of classes or structs. This would have added another level of complexity which apparently was judged to be too complex. Where should the algorithm stop? Are members of members, and so forth, also to be considered?
Also, it's not required because there are other means of achieving the same intention, as shown in the example below.
Nothing prevents you from writing:
struct sample
{
typedef int MemberType;
MemberType member;
};
template<typename TArg>
void g(TArg param)
{
typename TArg::MemberType v = param.member;
}
sample s = { 0 };
g(s);
in order to obtain the same effect.
Regarding your sample you added after editing: whereas it seems that h(p.member) does depend on the member of the struct, and hence the template matching algorithm should fail, it doesn't because you made it a two-step process:
Upon seeing g(s);, the compiler looks for any function taking an argument of type sample (templated or not!). In your case, the best match is void g(T p). At this point, the compiler has not even looked at the body of g(T p) yet!.
Now, the compiler creates a instance of g(T p), specialized for T: sample. So when it sees h(p.member) it knows that p.member is of type int, and will try locate a function h() taking an argument of type int. Your template function h(T p) turns out to be the best match.
Note that if you had written (note the NOT_A_member):
template<typename T>
void g(T p)
{
h(p.NOT_A_member);
return;
}
then the compiler would still consider g() a valid match at stage 1. You then get an error when it turns out that sample does not have a member called NOT_A_member.
There are a couple of things that the compiler cannot possibly do with the code that you provide, the first of which is deduce the second template argument TBody. First, type deduction is only applied to the arguments of the function when the compiler is trying to match the call. At that point the definition of the templated function is not even looked at.
For extra credits, even if the compiler were to look the function definition, the code TBody v = parameter.member is non-deducible in itself, as there are potentially infinite data types that can accept a parameter.member in the constructor.
Now, on the second block of code. To understand it the whole process of template compilation starts when the compiler sees the function call g(x) at that point of call. The compiler sees that the best candidate is the template function template <typename T> void g( T ) and determines what the type T is as part of the overload resolution. Once the compiler determines that it is a call to the template, it performs the first pass of compilation on that function.
During the first pass, syntactic checks are perform without an actual substitution of the type, so the template argument T is still any-type and the argument p is of a yet-unknown type. During the first pass, the code is verified, but dependent names are skipped and their meaning is just assumed. When the compiler sees p.member, and p is of type T that is a template argument it assumes that it will be a member of the yet unknown type (this is the reason why if it is a type you would have to qualify it here with typename). The call h(p.member); is also dependent on the type argument T and is left as it is, assuming that once the type substitution takes place everything will make sense.
Then the compiler does actually substitute the type. At this step T is no longer a generic type, but it represents the concrete type sample. Now the compiler during the second pass tries to fill in the gaps that were left during the first pass. When it sees p.member it looks member inside the type and determines that it is an int and tries to resolve the call h( p.member ); with that knowledge. Because the type T has been resolved before this second stage, this is equivalent to the outside call g(x): all types are known and the compiler only needs to resolve what is the best overload for a function call h that takes an argument of type int&, and the whole process starts again, the template h is found as the best candidate, and ...
It is really important for metaprogramming to understand that type deduction is performed only on the actual signature of the function and not the body, and that is what makes it non-trivial for beginners. Using enable_if (from boost or elsewhere) in the function signature as argument or return type is not a coincidence, but the only way of having the compiler fail to substitute the type before the template is selected as best candidate and the substitution failure is turned into an actual error (and not SFINAE)
No compiler could possibly implement this functionality in a consistent manner. You are simply asking too much.
TBody might be ambiguous, because sample might not be the only type that has a member member. Furthermore, if g calls other template functions, the compiler has no way of knowing what other restrictions might be imposed on TBody.
So in some edge cases, it is theoretically possible to deduce the proper type for TBody, generally it is not.