I think not since neither Comeau nor VC++ 7.1 accept it (results below), but
I must admit I am perplexed as to why. I know that in general a nontype
parameter for a function template can be deduced, but there is clearly
something special about this case. I'll be interested to follow this
thread...

Note that if you change the parameter to bre reference to array, it works...
Maybe this can hint at why the case you presented fails...

One other thought: Both the parameter and the argument should decay to a
pointer. (The argument would not if it were reference, but that's not the
case here...). I wonder if this is somehow interfering with the deduction
process...

....
>>
>>error: no matching function for call to `strn(const char[5])'
...
> One other thought: Both the parameter and the argument should decay to a
> pointer. (The argument would not if it were reference, but that's not the
> case here...). I wonder if this is somehow interfering with the deduction
> process...

Yes, a reference seems to work, but why does the non reference version
fail ?

I think that in the case of the array, the number in the brackets is
never passed to the function at runtime; --i.e.: it is equivalent to
passing a pointer, and the number in the brackets is just candy for
your eyes only; whereas a reference is a unique type.

>
>I think that in the case of the array, the number in the brackets is
>never passed to the function at runtime; --i.e.: it is equivalent to
>passing a pointer, and the number in the brackets is just candy for
>your eyes only; whereas a reference is a unique type.

Of course! int[5] is not a compile-time type, but a reference to
int[5] IS a type.

Has a conclusion been reached on *why* the original code (shown at the top)
fails to compile? Even though we have determined that using a reference
fixes the problem, it is still unclear to me why the original program fails
to compile...

Because array notation is an ugly thing carried on from C just for
backward compatibility. The big problem with C arrays is that they do
not carry size information. At run-time, an array is the same thing as
a pointer. At compile time as well, for that matter. The only point at
which the numbers in the brackets are actually used by the compiler is
when you create the array (allocate space). Thus, you were hoping to
select the appropriate template instance of a function *given* the
size of an array, but that array size is NOT given; --i.e.: it doesn't
get carried along with an array. So scope resolution cannot work.
To the compiler, int[5] and int[9] are the same type: int*.

It's as if you open two car garages and say, "odd licence plates go in
garage A, even license plates in garage B; but the cars coming in
have NO license plates, so they can't decide where to go.

References were introduced with C++ and do carry full info with them
at compile time, thus, scope resolution can work its magic.

I've tried to do somthing similar with the Austria smart pointer
(releasing under GPL soon) library so that iterators can be managed by
smart pointers as well. I probably should have factorized it out into
somthing like this - different problem but same kind of concept.

What intrigues me is that the more you mess with templates, the code
grows in unexpected ways. I'm still getting used to them. There are
significant limitations on templates as defined by the standard, some of
them because the the legacy of C but I can imagine there is far more to
template meta-programming than I can see right now.

The template syntax however is far more obfuscating than I'd like it to
be. It reminds me of some of the visual programming concepts (auto
deduction etc). The thing that worries me is that the body of
programmers that have the fortitude to master templates even at the
minimal levels is far smaller than those than can master C. The success
of a language is directly related to the number of competant
pratitioners and hence my concern. I still run into new compiler
template bugs and that indicates maturity issues.

But, on the other hand, I can write 100% generic code which should work
with far fewer assuptions and hence the satisfaction of creating code
that I theoretically will never need to update as new features are added
to the language. (think upgrades from 16bit to 32bit to 64bit).

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Ask a Question