Comment mieux protéger de 0 passé aux paramètres std :: string?

Je viens de réaliser quelque chose de dérangeant. Chaque fois que j'ai écrit une méthode qui accepte un std::stringcomme paramètre, je me suis ouvert à un comportement indéfini.

Par exemple, cela ...

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

... peut être appelé comme ça ...

char* s = 0;
myMethod(s);

... et je ne peux rien faire pour l'empêcher (à ma connaissance).

Ma question est donc: comment quelqu'un peut-il se défendre contre cela?

La seule approche qui me vient à l'esprit est de toujours écrire deux versions de toute méthode qui accepte un std::stringcomme paramètre, comme ceci:

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

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

Est-ce une solution courante et / ou acceptable?

EDIT: Certains ont souligné que je devrais accepter const std::string& sau lieu de std::string scomme paramètre. Je suis d'accord. J'ai modifié le post. Je ne pense pas que cela change la réponse.

Je ne pense pas que vous devriez vous protéger. C'est un comportement indéfini du côté de l'appelant. Ce n'est pas vous, c'est l'appelant qui appelle std::string::string(nullptr), ce qui n'est pas autorisé. Le compilateur permet de le compiler, mais il permet également de compiler d'autres comportements non définis.

La même manière serait d'obtenir une "référence nulle":

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

Celui qui déréférence le pointeur nul fait UB et en est responsable.

De plus, vous ne pouvez pas vous protéger après qu'un comportement indéfini s'est produit, car l'optimiseur a tout à fait le droit de supposer que le comportement indéfini ne s'est jamais produit, de sorte que la vérification si c_str()est nul peut être optimisée.

Le code ci-dessous donne un échec de compilation pour un passage explicite de 0, et un échec d'exécution pour un char*avec une valeur 0.

Notez que je n'implique pas que l'on devrait normalement faire cela, mais il ne fait aucun doute qu'il peut y avoir des cas où la protection contre l'erreur de l'appelant est justifiée.

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
}

J'ai également rencontré ce problème il y a quelques années et je l'ai trouvé très effrayant. Cela peut arriver en passant un nullptrou en passant accidentellement un int avec la valeur 0. C'est vraiment absurde:

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

Cependant, à la fin, cela ne m'a dérangé que quelques fois. Et chaque fois, cela provoquait un crash immédiat lors du test de mon code. Aucune session nocturne ne sera donc nécessaire pour le réparer.

Je pense que surcharger la fonction avec const char*est une bonne idée.

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

Je souhaite qu'une meilleure solution soit possible. Mais il n'y en a pas.

Que diriez-vous de changer la signature de votre méthode pour:

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

De cette façon, l'appelant doit créer une chaîne avant de l'appeler, et la négligence qui vous inquiète causera des problèmes avant d'arriver à votre méthode, ce qui rend évident, ce que les autres ont souligné, que c'est l'erreur de l'appelant et non la vôtre.

Que diriez-vous de fournir en surcharge le prend un intparamètre?

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

private:
    void myMethod(int);

Vous n'avez même pas besoin de définir la surcharge. Essayer d'appeler myMethod(0)déclenchera une erreur de l'éditeur de liens.

Votre méthode dans le premier bloc de code ne sera jamais appelée si vous essayez de l'appeler avec un (char *)0. C ++ essaiera simplement de créer une chaîne et lèvera l'exception pour vous. L'avez-vous essayé?

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

Voir? Vous n'avez rien à craindre.

Maintenant, si vous voulez saisir cela un peu plus gracieusement, vous ne devriez tout simplement pas utiliser char *, le problème ne se posera pas.

Si vous craignez que char * soit des pointeurs potentiellement nuls (par exemple, les retours des API C externes), la réponse est d'utiliser une version const char * de la fonction au lieu de la std :: string. c'est à dire

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

Bien sûr, vous aurez également besoin de la version std :: string si vous souhaitez autoriser leur utilisation.

En général, il est préférable d'isoler les appels aux API externes et de rassembler les arguments en valeurs valides.