Como proteger melhor de 0 passado aos parâmetros std :: string?

Acabei de perceber algo perturbador. Toda vez que escrevo um método que aceita a std::stringcomo parâmetro, eu me abro a um comportamento indefinido.

Por exemplo, isso ...

void myMethod(const std::string& s) { 
    /* Do something with s. */
}

... pode ser chamado assim ...

char* s = 0;
myMethod(s);

... e não há nada que eu possa fazer para evitá-lo (que eu saiba).

Então, minha pergunta é: como alguém se defende disso?

A única abordagem que vem à mente é sempre escrever duas versões de qualquer método que aceite a std::stringcomo parâmetro, como este:

void myMethod(const std::string& s) {
    /* Do something. */
}

void myMethod(char* s) {
    if (s == 0) {
        throw std::exception("Null passed.");
    } else {
        myMethod(string(s));
    }
}

Esta é uma solução comum e / ou aceitável?

Edição: Alguns salientaram que eu deveria aceitar em const std::string& svez de std::string scomo um parâmetro. Concordo. Eu modifiquei a postagem. Acho que isso não muda a resposta.

Eu não acho que você deveria se proteger. É um comportamento indefinido do lado do chamador. Não é você, é quem chama std::string::string(nullptr), o que não é permitido. O compilador permite que ele seja compilado, mas também permite que outros comportamentos indefinidos sejam compilados.

Da mesma maneira seria obter "referência nula":

int* p = nullptr;
f(*p);
void f(int& x) { x = 0; /* bang! */ }

Quem desreferencia o ponteiro nulo está criando UB e é responsável por ele.

Além disso, você não pode se proteger após o comportamento indefinido, porque o otimizador tem todo o direito de assumir que o comportamento indefinido nunca aconteceu, portanto, a verificação de c_str()nulo pode ser otimizada.

O código abaixo fornece uma falha de compilação para uma passagem explícita de 0e uma falha em tempo de execução para a char*with value 0.

Observe que eu não implica que alguém deva fazer isso normalmente, mas sem dúvida pode haver casos em que a proteção contra o erro de chamada é justificada.

struct Test
{
    template<class T> void myMethod(T s);
};

template<> inline void Test::myMethod(const std::string& s)
{
    std::cout << "Cool " << std::endl;
}

template<> inline void Test::myMethod(const char* s)
{
    if (s != 0)
        myMethod(std::string(s));
    else
    {
        throw "Bad bad bad";
    }
}

template<class T> inline void Test::myMethod(T  s)
{
    myMethod(std::string(s));
    const bool ok = !std::is_same<T,int>::value;
    static_assert(ok, "oops");
}

int main()
{
    Test t;
    std::string s ("a");
    t.myMethod("b");
    const char* c = "c";
    t.myMethod(c);
    const char* d = 0;
    t.myMethod(d); // run time exception
    t.myMethod(0); // Compile failure
}

Eu também encontrei esse problema há alguns anos e achei realmente muito assustador. Isso pode acontecer nullptrpassando um int ou acidentalmente passando um int com valor 0. É realmente um absurdo:

std::string s(1); // compile error
std::string s(0); // runtime error

No entanto, no final, isso só me incomodou algumas vezes. E cada vez que causava uma falha imediata ao testar meu código. Portanto, não serão necessárias sessões noturnas para corrigi-lo.

Eu acho que sobrecarregar a função const char*é uma boa ideia.

void foo(std::string s)
{
    // work
}

void foo(const char* s) // use const char* rather than char* (binds to string literals)
{
    assert(s); // I would use assert or std::abort in case of nullptr . 
    foo(std::string(s));
}

Eu gostaria que uma solução melhor fosse possível. No entanto, não há.

Que tal alterar a assinatura do seu método para:

void myMethod(std::string& s) // maybe throw const in there too.

Dessa forma, o chamador precisa criar uma sequência antes de chamá-la, e a negligência com a qual você está preocupado causará problemas antes que ele atinja o seu método, tornando óbvio o que os outros apontaram, que é o erro do chamador e não o seu.

Que tal você fornecer sobre sobrecarga o leva um intparâmetro?

public:
    void myMethod(const std::string& s)
    { 
        /* Do something with s. */
    }    

private:
    void myMethod(int);

Você nem precisa definir a sobrecarga. Tentar ligar myMethod(0)acionará um erro do vinculador.

Seu método no primeiro bloco de código nunca será chamado se você tentar chamá-lo com a (char *)0. O C ++ simplesmente tentará criar uma string e lançará a exceção para você. Você tentou?

#include <cstdlib>
#include <iostream>

void myMethod(std::string s) {
    std::cout << "s=" << s << "\n";
}

int main(int argc,char **argv) {
    char *s = 0;
    myMethod(s);
    return(0);
}


$ g++ -g -o x x.cpp 
$ lldb x 
(lldb) run
Process 2137 launched: '/Users/simsong/x' (x86_64)
Process 2137 stopped
* thread #1: tid = 0x49b8, 0x00007fff99bf9812 libsystem_c.dylib`strlen + 18, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007fff99bf9812 libsystem_c.dylib`strlen + 18
libsystem_c.dylib`strlen + 18:
-> 0x7fff99bf9812:  pcmpeqb (%rdi), %xmm0
   0x7fff99bf9816:  pmovmskb %xmm0, %esi
   0x7fff99bf981a:  andq   $15, %rcx
   0x7fff99bf981e:  orq    $-1, %rax
(lldb) bt
* thread #1: tid = 0x49b8, 0x00007fff99bf9812 libsystem_c.dylib`strlen + 18, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007fff99bf9812 libsystem_c.dylib`strlen + 18
    frame #1: 0x000000010000077a x`main [inlined] std::__1::char_traits<char>::length(__s=0x0000000000000000) + 122 at string:644
    frame #2: 0x000000010000075d x`main [inlined] std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(this=0x00007fff5fbff548, __s=0x0000000000000000) + 8 at string:1856
    frame #3: 0x0000000100000755 x`main [inlined] std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(this=0x00007fff5fbff548, __s=0x0000000000000000) at string:1857
    frame #4: 0x0000000100000755 x`main(argc=1, argv=0x00007fff5fbff5e0) + 85 at x.cpp:10
    frame #5: 0x00007fff92ea25fd libdyld.dylib`start + 1
(lldb) 

Vejo? Você não tem nada com o que se preocupar.

Agora, se você quiser entender isso um pouco mais graciosamente, simplesmente não deve usá-lo char *, o problema não surgirá.

Se você está preocupado com char * sendo ponteiros potencialmente nulos (por exemplo, retornos de APIs externas C), a resposta é usar uma versão const char * da função em vez da std :: string one. ie

void myMethod(const char* c) { 
    std::string s(c ? c : "");
    /* Do something with s. */
}

Claro que você também precisará da versão std :: string se quiser permitir que elas sejam usadas.

Em geral, é melhor isolar chamadas para APIs externas e argumentos de empacotamento em valores válidos.