Initialise std :: string à partir d'un pointeur de caractère éventuellement NULL

Le dernier est idiot parce qu'il n'utilise pas l'initialisation quand il le pouvait.

Les deux premiers sont complètement identiques du point de vue sémantique (pensez à la c_str() fonction membre), c'est plutôt la première version car elle est la plus directe et idiomatiques, et facile à lire.

(Il y serait être une différence sémantique si std::string avait un constexpr constructeur par défaut, mais il ne le fait pas. Pourtant, c'est possible que std::string() est différente de std::string("")mais je ne sais pas toutes les implémentations qui font cela, car il ne semble pas faire beaucoup de sens. D'autre part, populaire petite chaîne optimisations de nos jours signifie que les deux versions seront probablement pas effectuer toute allocation dynamique.)

---

Mise à jour: @Jonathan, la chaîne de deux constructeurs ne sera probablement exécuter un code différent, et si ce qui compte pour vous (même si elle ne devrait pas), vous pourriez envisager une quatrième version:

: cstr ? cstr : std::string()

À la fois lisible et de défaut de construction.

---

Deuxième mise à jour: Mais préfèrent cstr ? cstr : "". Comme vous pouvez le voir ci-dessous, lorsque les deux branches d'appeler la même constructeur, ce qui peut être mis en œuvre de manière très efficace à l'aide conditionnelle se déplace et pas de branches. (De sorte que les deux versions ne sont en effet de générer un code différent, mais le premier est mieux).

---

Pour le fou rire, j'ai couru les deux versions à travers Clang 3.3, avec -O3sur x86_64, pour un struct foo; comme la vôtre et une fonction foo bar(char const * p) { return p; }:

Constructeur par défaut (std::string()):

    .cfi_offset r14, -16
    mov     R14, RSI
    mov     RBX, RDI
    test    R14, R14
    je      .LBB0_2
    mov     RDI, R14
    call    strlen
    mov     RDI, RBX
    mov     RSI, R14
    mov     RDX, RAX
    call    _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcm
    jmp     .LBB0_3
.LBB0_2:
    xorps   XMM0, XMM0
    movups  XMMWORD PTR [RBX], XMM0
    mov     QWORD PTR [RBX + 16], 0
.LBB0_3:
    mov     RAX, RBX
    add     RSP, 8
    pop     RBX
    pop     R14
    ret

Vide-chaîne constructeur (""):

    .cfi_offset r14, -16
    mov     R14, RDI
    mov     EBX, .L.str
    test    RSI, RSI
    cmovne  RBX, RSI
    mov     RDI, RBX
    call    strlen
    mov     RDI, R14
    mov     RSI, RBX
    mov     RDX, RAX
    call    _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcm
    mov     RAX, R14
    add     RSP, 8
    pop     RBX
    pop     R14
    ret

.L.str:
    .zero    1
    .size    .L.str, 1

Dans mon cas, il semblerait même que "" génère mieux code: les Deux versions appel strlenmais le vide-chaîne de version n'utilise pas de sauts, uniquement sous réserve se déplace (depuis le même constructeur est appelé avec deux arguments différents). Bien sûr, c'est complètement dénuée de sens, non transférables et non transférables d'observation, mais il va juste pour montrer que le compilateur n'a pas toujours besoin d'autant d'aide que vous pourriez le penser. Il suffit d'écrire le code qui semble la meilleure.

Première chose d'abord, vous avez raison, à partir de http://www.cplusplus.com/reference/string/string/string/:

Si s est un pointeur null, si n == osbl, ou si la plage spécifiée par [first,last) n'est pas valide, il provoque un comportement indéfini.

Aussi, ça dépend de ce qu'est un pointeur NULL signifie pour vous. Je suppose que c'est la même chose qu'une chaîne vide pour vous.

Je voudrais aller avec le premier, car c'est la seule j'ai lu meilleur. Première solution et la seconde sont les mêmes. Troisième de ne pas fonctionner si votre chaîne est const.