¿Cómo proteger mejor del 0 pasado a los parámetros std :: string?

Me acabo de dar cuenta de algo inquietante. Cada vez que escribo un método que acepta std::stringun paramater, me abro a un comportamiento indefinido.

Por ejemplo, esto ...

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

... se puede llamar así ...

char* s = 0;
myMethod(s);

... y no hay nada que pueda hacer para evitarlo (que yo sepa).

Entonces mi pregunta es: ¿cómo se defiende alguien de esto?

El único enfoque que viene a la mente es escribir siempre dos versiones de cualquier método que acepte un std::stringpará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));
    }
}

¿Es esta una solución común y / o aceptable?

EDITAR: Algunos han señalado que debería aceptar en const std::string& slugar de std::string scomo un parámetro. Estoy de acuerdo. Modifiqué la publicación. Sin embargo, no creo que eso cambie la respuesta.

No creo que debas protegerte. Es un comportamiento indefinido del lado de la persona que llama. No eres tú, es la persona que llama std::string::string(nullptr), que es lo que no está permitido. El compilador permite que se compile, pero también permite que se compilen otros comportamientos indefinidos.

La misma forma sería obtener "referencia nula":

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

El que desreferencia el puntero nulo está haciendo UB y es responsable de ello.

Además, no puede protegerse después de que haya ocurrido un comportamiento indefinido, porque el optimizador tiene todo el derecho de asumir que el comportamiento indefinido nunca había sucedido, por lo que las comprobaciones si c_str()son nulas pueden optimizarse.

El siguiente código proporciona un error de compilación para un pase explícito 0y un error en tiempo de ejecución para un char*valor con 0.

Tenga en cuenta que no implica que normalmente deba hacerlo, pero sin duda puede haber casos en los que se justifique la protección contra el error de la persona que llama.

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
}

También me encontré con este problema hace unos años y, de hecho, me pareció muy aterrador. Puede suceder pasando un nullptro pasando accidentalmente un int con valor 0. Es realmente absurdo:

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

Sin embargo, al final esto solo me molestó un par de veces. Y cada vez causó un bloqueo inmediato al probar mi código. Por lo tanto, no se requerirán sesiones nocturnas para solucionarlo.

Creo que sobrecargar la función const char*es una buena idea.

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

Desearía que fuera posible una mejor solución. Sin embargo, no lo hay.

¿Qué tal cambiar la firma de su método a:

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

De esa manera, la persona que llama debe crear una cadena antes de llamarla, y la descuido que le preocupa causará problemas antes de que llegue a su método, lo que hace obvio, lo que otros han señalado, que es el error de la persona que llama, no el suyo.

¿Qué tal si proporciona sobrecarga la toma un intparámetro?

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

private:
    void myMethod(int);

Ni siquiera tiene que definir la sobrecarga. Intentar llamar myMethod(0)provocará un error de enlazador.

Su método en el primer bloque de código nunca se llamará si intenta llamarlo con un (char *)0. C ++ simplemente intentará crear una cadena y arrojará la excepción por usted. ¿Lo intentaste?

#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) 

¿Ver? No tienes nada de qué preocuparte.

Ahora, si desea captar esto con un poco más de gracia, simplemente no debería estar usando char *, entonces el problema no surgirá.

Si le preocupa que char * sea punteros potencialmente nulos (p. Ej., Retornos de API C externas), la respuesta es usar una versión const char * de la función en lugar de std :: string one. es decir

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

Por supuesto, también necesitará la versión std :: string si desea permitir que se usen.

En general, es mejor aislar las llamadas a API externas y argumentos de mariscal en valores válidos.