baibaichen said:
Yes, you are right, As we know,
void foo(const std::string&);
void foo(const std::string);
are not permitted in C++,
Why shouldn't it be permitted? It's only not easy to use because you
can't call the functions directly because the call would be
ambigous. If the parameters were not const, you could call the
second one directly by providing an const parameter, because then
(and only then) the compiler could figure out that the first
function was not applicable because a const object cannot be bound
to a const reference. However, you _can_ call both functions through
function pointers, because the functions' types are different and
therefore you can assign the function's adresses to appropiate fptrs:
void foo(const std::string&) {cout << "ref version!" << endl; }
void foo(const std::string) { cout << "str version!" << endl ;}
int main()
{
void (*pfr)(std::string const&) = &foo;
void (*pfs)(std::string const) = &foo;
pfr(""); //ref version!
pfs(""); //str version!
}
void foo(const std::string&);
...
std::cout<< typeid(foo).name << std:endl;
In this case, VC would clearly tell us that the parameter is a
*reference type*(Gcc also report the same result with unfriendly
words).
Yes it does, because a function taking a reference has another type
than an function taking an object.
In the C++ standard, a reference to T indeed is another type than T
itself.
BUT the standard explicitly states (5.2.8) that typeid() yields an
type_info representing the referenced type if passed a type-id that
is a reference type. Equally, toplevel cv-qualifiers are ignored, so
typeid(T) == typeid(T const) == typeid(T&) == typeid(T const&).
Summary: T& and T are different types, but typeid yields the same
type_info object.
