Thread: Passing C-style string to template function as reference

Literal "foo" actually has type "char const [4]". Therefore T1 is the same, and x is of type "char const (&)[4]", though typeid doesn't say this because it can't make the distinction.

With "bar", the type of T2 would be 'char const [4]". However, declaring a function argument like this actually declares it as a char pointer. So the type of T2 and y is "char const *".

It may help to understand if you replace the template parameters with their actual type:

Code:

#include <iostream>
#include <typeinfo>
 
void f(const char (&x)[4], const char y[4])
{
    std::cout << typeid(x).name() << '\n';
    std::cout << typeid(y).name() << '\n';
}
 
int main()
{
    f("foo", "bar");
    return 0;
}

I've managed to figure out what's going on although I'd still appreciate it if someone has anything to add

Code:

void a(const int *test);
void b(const int test[]);
void c(const int test[10]);

Turns out these three function declarations are identical and in each case, passing an array will result in the array decaying into a pointer. The compiler ignores the 10 I've added in declaration of c and this was the source of confusion for me.

The only way to pass an actual array (without decay) is by using reference:

Code:

void d(const int(&test)[10])

The compiler will complain if I don't specify the size in declaration of d, or if I pass an array that has size other than 10.

Alternatively I can pass a pointer to an array:

Code:

void alternative(const int (*test)[10]){
    std::cout << typeid(*test).name() << '\n';
    std::cout << sizeof(*test) << "\n";
}

Here I can only pass an int array of size 10. typeid().name() gives int const [10] and sizeof() gives 40 on my machine.

Also learnt that even though the compiler ignores the specified bound in the case of c, it actually only ignores the first (left-most) bound.

Code:

void e(const int test[32][32][32]){ // identical to void e(const int test[][32][32])
    std::cout << typeid(test).name() << '\n';
    std::cout << sizeof(test) << "\n";
}

int main()
{
    int test[64][32][32]; // 64 can be replaced by any valid value (>0) but the other two sizes must be 32
    e(test);
    return 0;
}

This prints int const (*)[32][32] and 4.

if y also has type char const [4] then why is typeid saying it's char const *

The two statements are semantically identical, so

Code:

void f(int* n);
void f(int n[5]); // results in  int*  like the preceding line, C/C++ is weird like that

Try and compile the above and you should see a function redefinition error.

Passing an array by reference–as you saw–preserves the whole type with its size.

Originally Posted by sythical

I've managed to figure out what's going on although I'd still appreciate it if someone has anything to add

This whole weird and stupid behaviour is due to C++'s C legacy. Basically, the C standard says it shall work as you see it works. C++ fixed the problem with reference types, so passing an array by reference works as expected with no loss of type information.

To be honest with you, this is (one of) the reasons why we shouldn't use C arrays: their semantics are confusing, dumb and stupid. Objects always follow the same rules that applies to every type except for C-style arrays that have exceptions. For strings, use string_view in the functions instead.

True - colleges and some 'older' books do still enforce people learning C++ to learn C style arrays before Vectors. However vectors are part of the STL and perhaps authors of those books or lecturers would rather teach vectors as part of the whole "STL package". Still, C arrays do have their place in C++ even if it's just a simple learning tool into how simple data structures work.

I've read a few lecture notes from as recently as 2016 and most still explain C arrays before vectors are introduced. However, Java has the same problem in this regard - most texts show arrays as objects (as they do in Java) before moving onto Array Lists - which is just a container array type in Java. C# has lists. It's probably all connected to the "learn A before B" theory.

Saying you should use std::array is well and good, but doesn't help the problem here, because we're dealing with string literals. So understanding the intricacies here can be necessary. Often though, you can just provide an overload or template specialization specifically for strings, and avoid the gotcha that way. A non-template overload will always be preferred to a template function, so that can be a way to make sure all strings are treated the same.

Originally Posted by sythical

I've managed to figure out what's going on although I'd still appreciate it if someone has anything to add

Bonus question: What if you do this?

Code:

#include <iostream>
#include <typeinfo>
 
template <class T1, class T2>
void f(T1 &x, T2 y)
{
    T2 z = "baz";
    std::cout << typeid(x).name() << '\n';
    std::cout << typeid(y).name() << '\n';
    std::cout << typeid(z).name() << '\n';
}
 
int main()
{
    f("foo", "bar");
    return 0;
}

Do you think the type of z should be "char const *" or "char const[4]"? Try it and see.

Why it it that way? Because the writers of the standard though this would be most intuitive and useful. As all this demonstrates, array types are treated specially by template type deduction.

Unfortunately, unlike with std::array, you can't just replace all uses of "char *" with std::string, as the OP example demonstrates.

Also, because string is a dynamically sized, it has costs that std::array doesn't. Elysia mentioned C++17's std::string_view, which is cheaper, but still not as cheep as an array reference. And a const char * may be relatively simple and cheep like array references when you don't need to know the size. So there are choices and trade offs.