Perché ci sono così tante classi di stringhe di fronte a std :: string?

Mi sembra che molte più grandi librerie C ++ finiscano per creare il proprio tipo di stringa. Nel codice cliente si hanno o utilizzare quello dalla libreria ( QString, CString, fbstringecc, sono sicuro che chiunque può citarne alcuni), o mantenere la conversione tra il tipo standard e quello gli usi della biblioteca (che il più delle volte comporta almeno una copia).

Quindi, c'è una particolare disfunzione o qualcosa di sbagliato std::string(proprio come la auto_ptrsemantica era cattiva)? È cambiato in C ++ 11?

La maggior parte di quelle più grandi librerie C ++ sono state avviate prima che std::stringfosse standardizzato. Altri includono funzionalità aggiuntive standardizzate in ritardo o ancora non standardizzate, come il supporto per UTF-8 e la conversione tra codifiche.

Se quelle librerie fossero implementate oggi, probabilmente sceglierebbero di scrivere funzioni e iteratori che operano su std::stringistanze.

String è il grande imbarazzo del C ++.

Per i primi 15 anni non fornisci affatto una classe di stringhe, costringendo ogni compilatore su ogni piattaforma e ogni utente a crearne una propria.

Quindi fai qualcosa di confuso sul fatto che debba essere un'API di manipolazione di stringhe complete o solo un contenitore di caratteri STL, con alcuni algoritmi che duplicano quelli su uno std :: Vector o sono diversi.

Laddove un'operazione stringa ovvia come sostituisca () o mid () comporta un tale disordine di iteratori che è necessario introdurre una nuova parola chiave "auto" per mantenere l'adattamento dell'istruzione su una singola pagina e indurre la maggior parte delle persone a rinunciare all'intera lingua .

E poi hai unicode 'support' e std :: wstring che è solo arghh .....

<rant off> grazie - Adesso mi sento molto meglio.

In realtà ... ci sono diversi problemi con std::string, e sì, in C ++ 11 migliora un po ', ma non anticipiamo noi stessi.

QStringe CStringfanno parte di vecchie librerie, quindi esistevano prima che il C ++ fosse standardizzato (proprio come lo SGI STL). Hanno quindi avuto per creare una classe.

fbstringaffrontare problematiche prestazionali molto specifiche. Lo standard prescrive un'interfaccia e la complessità algoritmica garantisce i minimi, tuttavia è una qualità di dettagli di implementazione se questo finisce per essere veloce o no. fbstringha ottimizzazioni specifiche (relative allo spazio di archiviazione o findad esempio più veloci ).

Altre preoccupazioni che non sono state evocate qui (en vrac):

• in C ++ 03 non è obbligatorio che la memoria sia contigua, rendendo potenzialmente difficile l'interoperabilità con C. C ++ 11 risolve questo problema.
• std::string sta codificando inconsapevolmente e non ha un codice speciale per UTF-8, è facile memorizzare una stringa UTF-8 e danneggiarla involontariamente
• std::stringl'interfaccia è gonfia , molti metodi potrebbero essere stati implementati come funzioni libere e molti sono duplicati per conformarsi sia a un'interfaccia basata su indice sia a un'interfaccia basata su iteratore.

Oltre ai motivi pubblicati qui, ce n'è anche un altro: la compatibilità binaria . Gli autori delle librerie non hanno alcun controllo su quale std::stringimplementazione si sta utilizzando e se ha lo stesso layout di memoria della loro.

std::stringè un modello, quindi la sua implementazione è presa dalle intestazioni STL locali. Ora immagina di utilizzare localmente una versione STL ottimizzata per le prestazioni, pienamente compatibile con lo standard. Ad esempio, è possibile che si sia scelto di inserire un buffer statico in ciascuno std::stringdi essi per ridurre il numero di allocazioni dinamiche e errori nella cache. Di conseguenza, il layout e / o la dimensione della memoria dell'implementazione sono diversi da quelli della libreria.

Se solo il layout è diverso, alcune std::stringfunzioni dei membri richiamano istanze passate dalla libreria al client o viceversa potrebbero non riuscire, a seconda di quali membri sono stati spostati.

Se anche la dimensione è diversa, tutti i tipi di libreria che hanno std::stringmembri appariranno di dimensioni diverse quando vengono controllati nella libreria e nel codice client. Anche i membri di dati che seguono il std::stringmembro avranno gli offset spostati, e qualsiasi accesso diretto / accessorio in linea chiamato dal client restituirà spazzatura, nonostante "sembri OK" durante il debug della libreria stessa.

In conclusione: se la libreria e il codice client vengono compilati di nuovo in std::stringversioni diverse , si collegheranno perfettamente, ma potrebbe risultare in alcuni bug cattivi e difficili da capire. Se si modifica l' std::stringimplementazione, è necessario ricompilare tutte le librerie che espongono i membri da STL in modo che corrispondano al std::stringlayout del client . E poiché i programmatori vogliono che le loro librerie siano robuste, raramente le vedrai std::stringesposte ovunque.

Ad essere onesti, questo vale per tutti i tipi di STL. IIRC non hanno layout di memoria standardizzati.

Ci sono molte risposte alla domanda ma eccone alcune:

1. Legacy. Molte librerie e classi di stringhe sono state scritte PRIMA dell'esistenza di std :: string.

2. Per compatibilità con il codice in C. La libreria std :: string è C ++ dove come ci sono altre librerie di stringhe che funzionano con C e C ++.

3. Per evitare allocazioni dinamiche. La libreria std :: string utilizza l'allocazione dinamica e potrebbe non essere adatta per sistemi integrati, codice di interrupt o in tempo reale o per funzionalità di basso livello.

4. Modelli. La libreria std :: string si basa su modelli. Fino a poco tempo fa un certo numero di compilatori C ++ aveva scarse prestazioni o addirittura un supporto per il modello difettoso. Sfortunatamente, lavoro in un settore che utilizza molti strumenti personalizzati e una delle nostre catene di strumenti di uno dei principali attori del settore non supporta "ufficialmente" il 100% del C ++ (con roba buggy come template et al).

Probabilmente ci sono anche molte altre ragioni valide.

Si tratta principalmente di Unicode. Il supporto standard per Unicode è nella migliore delle ipotesi e ognuno ha le proprie esigenze Unicode. Ad esempio, ICU supporta tutte le funzionalità Unicode che potresti desiderare, dietro l'interfaccia più disgustosa generata automaticamente da Java che potresti immaginare, e se sei su Unix bloccato con UTF-16 potrebbe non essere la tua idea di un buon momento.

Inoltre, molte persone hanno bisogno di livelli diversi di supporto Unicode, non tutti hanno bisogno delle complesse API del layout del testo e cose del genere. Quindi è facile capire perché esistono numerose classi di stringhe: quella standard è piuttosto schifosa e tutti hanno esigenze diverse da quelle nuove, senza che nessuno riesca a creare una singola classe in grado di eseguire un sacco di supporto Unicode multipiattaforma con un'interfaccia piacevole.

Secondo me, questo è principalmente colpa del Comitato C ++ per non aver fornito correttamente supporto per Unicode nel 1998 o 2003, forse era comprensibile, ma non in C ++ 11. Eventualmente in C ++ 17 faranno meglio.

È perché ogni programmatore ha qualcosa da dimostrare e sente il bisogno di creare la propria classe di stringhe fantastica e più veloce per la sua unica, fantastica funzione. Di solito è un po 'superfluo e porta a tutti i tipi di conversioni di stringa extra nella mia esperienza.