"& s [0]" punta a caratteri contigui in una stringa: std ::?

Question

sto facendo alcuni lavori di manutenzione e sono imbattuto in qualcosa di simile al seguente:

std::string s; 
s.resize(strLength); 
// strLength is a size_t with the length of a C string in it. 

memcpy(&s[0], str, strLength); 

So utilizzando & s [0] sarebbe stato sicuro se fosse uno std :: vector, ma questo è un uso sicuro di std :: string?

Answer 1

Un'assegnazione di std :: string non è garantita per essere contigui secondo lo standard C++ 98/03, ma C++ 11 lo impone. In pratica, né I né Herb Sutter sono a conoscenza di un'implementazione che non utilizza archiviazione contigua.

Si noti che la funzione &s[0] è sempre garantita dallo standard C++ 11, anche nel caso di stringa di lunghezza 0. Non sarebbe garantito se avete fatto str.begin() o &*str.begin(), ma per &s[0] lo standard definisce operator[] come:

Returns: *(begin() + pos) se pos < size(), altrimenti un riferimento a un oggetto di tipo T con valore charT(); il valore di riferimento non deve essere modificata

Proseguendo, data() è definito come:

Restituisce: Un puntatore p tale che per ogni p + i == &operator[](i)i in [0,size()].

(notare le parentesi quadre ad entrambe le estremità della gamma)

---

Avviso: pre-standardizzazione C++ 0x non garantiva &s[0] a lavorare con le stringhe di lunghezza zero (in realtà, era un comportamento esplicitamente indefinito) e una revisione più vecchia di questa risposta spiegava questo; questo è stato corretto in bozze standard successive, quindi la risposta è stata aggiornata di conseguenza.

Answer 2

Tecnicamente, no, dal std::string non è necessario per archiviarne il contenuto in modo contiguo nella memoria.

Tuttavia, in quasi tutte le implementazioni (tutte le implementazioni di cui sono a conoscenza), i contenuti vengono archiviati in modo contiguo e questo "funzionerebbe".

Answer 3

I lettori devono notare che questa domanda è stata posta nel 2009, quando lo standard C++ 03 era la pubblicazione corrente. Questa risposta è basata su quella versione dello standard, in cui std::string s è non garantito per l'utilizzo di archiviazione contigua. Dato che questa domanda non è stata posta nel contesto di una piattaforma particolare (come gcc), non faccio ipotesi sulla piattaforma di OP - in particolare, tempo o non ha utilizzato memorizzazione contagiosa per lo string.

Note legali? Forse sì forse no. Sicuro? Probabilmente, ma forse no. Buon codice? Bene, non andiamo là ...

Perché non basta fare:

std::string s = str; 

... o:

std::string s(str); 

... o:

std::string s; 
std::copy(&str[0], &str[strLen], std::back_inserter(s)); 

... o:

std::string s; 
s.assign(str, strLen); 

?

Answer 4

Questo è generalmente non sicuro, indipendentemente dal fatto che la sequenza di stringhe interna sia archiviata in memoria in modo continuo o meno. Potrebbero esserci molti altri dettagli di implementazione relativi al modo in cui la sequenza controllata viene archiviata dall'oggetto std::string, oltre alla continuità.

Un vero problema pratico potrebbe essere il seguente. La sequenza controllata di std::string non deve essere memorizzata come stringa a terminazione zero. Tuttavia, in pratica, molte (la maggior parte?) Implementazioni scelgono di sovradimensionare il buffer interno di 1 e memorizzano comunque la sequenza come una stringa a terminazione zero perché semplifica l'implementazione del metodo c_str(): basta restituire un puntatore al buffer interno e si fatto.

Il codice indicato nella domanda non fa alcuno sforzo per terminare a zero i dati copiati nel buffer interno. Molto probabilmente semplicemente non sa se è necessaria la terminazione zero in questa implementazione di std::string. Molto probabilmente si basa sul buffer interno riempito di zeri dopo la chiamata a resize, quindi il carattere extra assegnato per lo zero-terminator dall'implementazione è convenientemente preimpostato su zero. Tutto questo è dettaglio di implementazione, il che significa che questa tecnica dipende da alcune ipotesi piuttosto fragili.

In altre parole, in alcune implementazioni probabilmente dovresti usare strcpy, non memcpy per forzare i dati nella sequenza controllata del genere. Mentre in alcune altre implementazioni dovresti usare memcpy e non strcpy.

Answer 5

Il codice potrebbe funzionare, ma più per fortuna che per giudizio, fa supposizioni sull'implementazione che non sono garantite. Suggerisco di determinare la validità del codice è irrilevante, mentre si tratta di una inutile complicazione sopra che può essere facilmente ridotta a poco:

std::string s(str) ; 

o se assegnare a un oggetto std :: stringa esistente, basta:

s = str ; 

e quindi lasciare che std :: string stesso determini come ottenere il risultato. Se hai intenzione di ricorrere a questo genere di assurdità, allora potresti anche non usare std :: string e stick in quanto stai reintroducendo tutti i pericoli associati alle stringhe C.

Answer 6

È sicuro da usare. Penso che la maggior parte delle risposte siano corrette una volta, ma lo standard è cambiato. Citando dal C++ 11 di serie, basic_string requisiti generali [string.require], 21.4.1.5, dice:

Gli oggetti char-come in un oggetto basic_string devono essere conservati in modo contiguo.Cioè, per qualsiasi basic_string oggetto s, l'identità & * (s.begin() + n) == & * s.begin() + n deve valere per tutti i valori di n tale che 0 < = n < s .dimensione().

Un po 'prima, dice che tutti gli iteratori sono iteratori ad accesso casuale. Entrambi i bit supportano l'uso della tua domanda. (Inoltre, Stroustrup lo usa apparentemente nel suo ultimo libro;))

Non è improbabile che questo cambiamento sia stato fatto in C++ 11. Mi sembra di ricordare che la stessa garanzia è stata aggiunta per il vettore, che ha anche ottenuto l'utilissimo puntatore data() con quella versione.

Spero che questo aiuti.