Reputation: 1235
Due to a bug, I just found out that this code compiles fine on with Visual Studio 17 and probably on other compilers as well. Now I'm curious why?
#include <iostream>
#include <string>
std::string foo(){
return nullptr;
}
int main(){
auto s = foo();
std::cout << s << std::endl;
}
I could imagine it is because the std::basic_string
c'tor could be invoked with a char*
and while returning an implicit conversion from ptr to std::string
occurs (with NULL
as argument and then goes poof). Am I on the right way?
Upvotes: 25
Views: 2219
Reputation: 26272
Why shouldn't it compile? std::string
has the following constructor:
string(const CharT* s, const Allocator& alloc = Allocator());
that constructs the string with the contents initialized with a copy of the null-terminated character string pointed to by s
. The constructor is not explicit, so the implicit conversion from nullptr
to std::string
is indeed possible.
Upvotes: 13
Reputation: 36463
Yes, your assumption is right, checking std::basic_string
constructors #5 will be called:
basic_string( const CharT* s,
const Allocator& alloc = Allocator() );
Note that passing nullptr
invokes undefined behavior as stated in the standard and the notes :
The behavior is undefined if
[s, s + Traits::length(s))
is not a valid range (for example, ifs
is a null pointer).
Upvotes: 24