Passing C-style string to template function as reference

I was reading about std::decay on Stack Overflow (c++ - What is std::decay and when it should be used? - Stack Overflow) and in the accepted answer it is stated that:

Quote:

---

If it accepted its parameters by reference, then T1 will be deduced as an array type, and then constructing a pair<T1, T2> will be ill-formed.

---

The following code demonstrates the issue I have:

Code:

---

#include <iostream>
#include <typeinfo>

template <class T1, class T2>
void f(T1 &x, T2 y)
{
    std::cout << typeid(x).name() << '\n';
    std::cout << typeid(y).name() << '\n';
}

int main()
{
    f("foo", "bar");
    return 0;
}

---

Running this with VS 2015 gives me the following:

Code:

---

char const [4]
char const *

---

I don't really understand why T1 is being deduced as an array type. "foo" has type const char* so does this mean x has type const char*& which evaluates to const char array? I can see that the type T1 contains size information so it's definitely an array type and no array decay happened but what I'm having trouble with is the syntax and how adding the reference operator results in an array and removes the implicit cast.

Cheers!

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;
}

---

That helped me but also confused me. In your example if "bar" has type char const [4] and I'm passing it by value to f, and if y also has type char const [4] then why is typeid saying it's char const *? sizeof(y) is 4 (size of pointer, not 4 x 1 byte chars) so we're losing size information. I thought this only happens when an array is implicitly casted to a pointer which happens when trying and use an array in a pointer context (which isn't the case here). I hope I've been able to communicate why I'm confused... Basically I'm expecting both x and y to have type const char [4], both with size 4 (4 x 1 byte chars) and the only difference being one is passed by reference and the other is copied.

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.

Quote:

---

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.

Quote:

---

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.

What's even more silly is that we're still using raw arrays when we should be using std::array. It's a very thin layer of abstraction of the native array that makes it useful and also ensures your code will still work even when ranges become a more popularized and dominate abstraction.

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.

Quote:

---

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.

Ah, that's right. We're passing raw strings around. So yes, std::array isn't exactly applicable here, my apologies.

But, imo, raw arrays are problematic exactly for the reason why this thread was created. It's because it's difficult to reason about the behavior of the type as it's converted or referenced. Using something like std::string is significantly more reliable in this instance and supports short string optimization which will favor the stack when it's convenient so you don't lose much (if anything) with regards to performance and gain a significantly more clear view of what's happening.

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.