Quale è meglio per stringhe letterali, stringa standard o array di caratteri?Quale usare const char [] o const std :: string?
voglio dire per le stringhe costanti, dicono
const char name[] = "so"; //or to use
const string name = "so";
Per i valori letterali stringa e solo per le costanti stringa che provengono da valori letterali, vorrei utilizzare const char[]. Il vantaggio principale di std::string è che ha la gestione della memoria gratuitamente, ma non è un problema con i letterali stringa.
È il tipo effettivo del letterale in ogni caso e può essere utilizzato direttamente in qualsiasi API che richiede il vecchio stile C stringhe con terminazione nulla o le stringhe C++ (la conversione implicita si attiva). Si ottiene anche un'implementazione in termini di tempo di compilazione utilizzando la matrice anziché il puntatore.
Ora, al momento di definire le interfacce di funzione, e anche se le costanti sono intented essere passati in, preferirei std::string piuttosto che const char*, come nel caso quest'ultimo formato è perso, e sarà eventualmente necessario essere ricalcolati.
Fuori dalla mia esperienza. Sono diventato vecchio di scrivere .c_str() su ogni chiamata alla libreria di registrazione (che utilizzava argomenti variabili) per stringhe letterali con messaggi di informazione/errore.
Si dovrebbe usare ciò che è più appropriato per voi. Se non ci sono requisiti particolari, utilizzerei lo std::string perché fa funzionare tutta la memoria.
Per valori letterali stringa, utilizzare const char*. Il motivo contro const char[] è che è possibile utilizzare const char* per inizializzare un'altra costante. Controllare il seguente codice:
const char str1[] = "str1";
const char* str11 = "str11";
const char str2[] = str1; // <<< compile error
const char* str22 = str11; // <<< OK
stringhe letterali ha una durata statica di stoccaggio (secondo 2.13.4/2) in modo puntatore const char* sarà valido fino al completamento del programma.
Cosa ci fai? Cosa si aspettano i tuoi metodi?
const char è più leggero nella memoria, ma non ha la potenza di std :: string, o la sicurezza quando lo si utilizza. Tuttavia, se disponi di molte API C, potrebbe essere la scelta più giudiziosa.
std :: string sarebbe l'opzione preferita.
.c_str() è tuo amico :) – JPvdMerwe
@JPvdMerwe: theatrus è corretto. Se tutto quello che stai facendo è passare una stringa costante a funzioni che richiedono un 'const char *' non ha senso usare 'std :: string' /' .c_str() '. Una 'const' array di' char' non ha costi di call del costruttore e può essere passata direttamente alle funzioni che lo rende più economico da costruire e meno costoso da passare alle funzioni rispetto a 'std :: string'. –
Sì per stringhe letterali, sono completamente d'accordo, inutile sprecare tempo processore. – JPvdMerwe
Io tendo a preferire const std::string su const char * per valori letterali stringa. Poiché il passaggio di stringhe letterali in funzioni che richiedono const std::string & creerà automaticamente una stringa ogni volta che vengono chiamate anziché una sola. Tuttavia, se utilizzo principalmente il letterale con funzioni che prevedono un const char *, lo userò.
Io tendo a favorire std::string per l'apis.
Ovviamente se utilizzo unicode, utilizzo std::wstring e wchar_t.
Ho fatto la stessa ipotesi sull'unicode, ma questo è interessante: http://utf8everywhere.org/. Si scopre che wchar_t è qualcosa di una reliquia di un tempo più semplice nella cronologia unicode, così come l'API Win32 è nativa WCHAR. La vita potrebbe essere migliore se ti limiti semplicemente a UTF-8 e std :: string. – terriblememory
Ed è più veloce in molte implementazioni STL grazie a una copia sul meccanismo di scrittura se si utilizzano le stesse stringhe in molte posizioni diverse, cosa che rende anche più semplice da utilizzare rispetto alle stringhe in C semplici. Oltre a questo, se hai bisogno di supportare molte lingue, preferirei usare std :: wstring. – jdehaan
@jdehaan: Sarei sorpreso se ci sono (m) eventuali implementazioni di librerie std (non implementazioni STL, dato che 'std :: string' non faceva parte di STL) là fuori che ancora fanno COW. Negli ambienti MT questo di solito si trasforma in una pessimizzazione. Penso che l'ottimizzazione delle stringhe di piccole dimensioni (le stringhe piccole non siano allocate nell'heap, ma nello stack) è ciò che è comunemente favorito ora. – sbi
La copia su scrittura viene rimossa (se ancora presente) nella maggior parte delle implementazioni. Ha problemi in ambienti con multithreading, poiché alcune operazioni che sembrano thread-safe dal punto di vista dell'utente (si riferiscono a differenti std :: string's) potrebbero non essere thread-safe. Considera una stringa copiata con ogni copia passata su diversi thread per la modifica. Ogni thread ha una propria stringa, nessun oggetto condiviso, ma in effetti può esserci una condizione di competizione nell'implementazione interna 'copia su scrittura'. L'aggiunta di un meccanismo di blocco nella libreria la rende più lenta di un'implementazione semplice in molti casi. –