By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,513 Members | 1,604 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,513 IT Pros & Developers. It's quick & easy.

Template parameter Deduction

P: n/a
Hi all,
I had some confusion about deduction of non-type template parameters
for function templates :

template <class T, int i> void foo (T, int p = i) ;

void bar()
{
foo<int, 10>(40,40); // OK, T = int, i = 10
foo(40,40); // ERROR, T = int but i cannot be deduced.
}

However here I have another example :

template <class T, int i> void lookup ( Buffer<T,i> b);

void bar(Buffer<int, 128> b)
{
lookup(b,100); // No error, can infer T = int, i = 128
}

So it seems that when 'i' gets inferred as a "side effect" of type
matching, the compiler accepts that. However, it doesnot try to infer
it explicitly if required.

What does the standard say about this?

Nov 10 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Neelesh wrote:
Hi all,
I had some confusion about deduction of non-type template parameters
for function templates :

template <class T, int i> void foo (T, int p = i) ;

void bar()
{
foo<int, 10>(40,40); // OK, T = int, i = 10
foo(40,40); // ERROR, T = int but i cannot be deduced.
}
The compiler cannot deduce non-type parameters for function templates
since there is no requirement that the parameters be compile-time
constants. Moreover, non-type template parameters are not all that
useful. Why call one routine when the parameter is 40 and a different
routine when it is 20? Aren't parameters supposed to be variables?
Can't one routine accept both a 20 or a 40 as a parameter?

Even if the routines should be distinct, they need not be function
templates. One function could be named Function20 and the other
Function40. Non-type function templates provide no more abstraction
than parameter-accepting functions, but can easily add significantly
more bloat to an application.
However here I have another example :

template <class T, int i> void lookup ( Buffer<T,i> b);

void bar(Buffer<int, 128> b)
{
lookup(b,100); // No error, can infer T = int, i = 128
}

So it seems that when 'i' gets inferred as a "side effect" of type
matching, the compiler accepts that. However, it doesnot try to infer
it explicitly if required.


The compiler deduces that the type Buffer<int, 128> - so the 128 is
deduced from the type of the parameter. You want the compiler to deduce
40 from the value of the parameter - a completely different
proposition.

Greg

Nov 10 '05 #2

P: n/a

Greg wrote:
The compiler deduces that the type Buffer<int, 128> - so the 128 is
deduced from the type of the parameter. You want the compiler to deduce
40 from the value of the parameter - a completely different
proposition.


Great. That last sentence just clears my confusion. Thanks a lot.

Nov 10 '05 #3

P: n/a
"Greg" <gr****@pacbell.net> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com

The compiler cannot deduce non-type parameters for function templates
since there is no requirement that the parameters be compile-time
constants.


That is news to me. See if you can get this to compile

template<int i>
void foo()
{
int x=i;
}
int a = 5;

int main()
{
foo<a>();
}

--
John Carson
Nov 10 '05 #4

P: n/a
"John Carson" <jc****************@netspace.net.au> wrote in message
news:dk**********@otis.netspace.net.au
"Greg" <gr****@pacbell.net> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com

The compiler cannot deduce non-type parameters for function templates
since there is no requirement that the parameters be compile-time
constants.


That is news to me. See if you can get this to compile

template<int i>
void foo()
{
int x=i;
}
int a = 5;

int main()
{
foo<a>();
}


Or perhaps I misunderstood you and you meant that in

template <class T, int i> void foo (T, int p = i) ;

the ordinary (not template) p parameter of foo doesn't have to be a compile
time constant.
--
John Carson

Nov 10 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.