Taron
Taron

Reputation: 1235

Why isn't it a compile-time error to return a nullptr as a std::string?

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

Answers (2)

Evg
Evg

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

Hatted Rooster
Hatted Rooster

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, if s is a null pointer).

Upvotes: 24

Related Questions