Quando dovrei usare string_view in un'interfaccia?

Sto usando una libreria interna progettata per imitare una libreria C ++ proposta e in alcuni anni ho visto la sua interfaccia cambiata dall'uso std::stringa string_view.

Quindi cambio doverosamente il mio codice, per adeguarmi alla nuova interfaccia. Sfortunatamente, ciò che devo passare è un parametro std :: string e qualcosa che è un valore di ritorno std :: string. Quindi il mio codice è cambiato da qualcosa del genere:

void one_time_setup(const std::string & p1, int p2) {
   api_class api;
   api.setup (p1, special_number_to_string(p2));
}

per

void one_time_setup(const std::string & p1, int p2) {
   api_class api;
   const std::string p2_storage(special_number_to_string(p2));
   api.setup (string_view(&p1[0], p1.size()), string_view(&p2_storage[0], p2_storage.size()));
}

Io davvero non capisco che cosa questo cambiamento mi ha comprato come il client API, diverso da quello più codice (possibilmente rovinare). La chiamata API è meno sicura (a causa dell'API che non possiede più l'archiviazione per i suoi parametri), probabilmente ha salvato il mio programma 0 di lavoro (a causa di ottimizzazioni di spostamento che i compilatori possono fare ora), e anche se risparmiasse lavoro, sarebbe solo un paio di allocazioni che non verranno e non verrebbero mai eseguite dopo l'avvio o in un grande ciclo da qualche parte. Non per questa API.

Tuttavia, questo approccio sembra seguire i consigli che vedo altrove, ad esempio questa risposta :

A parte questo, dal C ++ 17 dovresti evitare di passare una const std :: string e in favore di una std :: string_view:

Trovo sorprendente questo consiglio, poiché sembra sostenere la sostituzione universale di un oggetto relativamente sicuro con un oggetto meno sicuro (sostanzialmente un puntatore e una lunghezza glorificati), principalmente a fini di ottimizzazione.

Quindi quando usare string_view e quando no?

1. La funzionalità che assume il valore deve diventare proprietaria della stringa? In tal caso, utilizzare std::string(non const, non ref). Questa opzione ti dà la possibilità di muoverti esplicitamente anche in un valore se sai che non verrà mai più usato nel contesto chiamante.
2. La funzionalità legge solo la stringa? In tal caso utilizzare std::string_view(const, non-ref) questo perché string_viewpuò gestire facilmente std::stringe char*senza problemi e senza fare una copia. Questo dovrebbe sostituire tutti i const std::string&parametri.

Alla fine non dovresti mai aver bisogno di chiamare il std::string_viewcostruttore come sei. std::stringha un operatore di conversione che gestisce automaticamente la conversione.

A std::string_viewporta alcuni dei vantaggi di a const char*in C ++: a differenza di std::stringstring_view

• non possiede la memoria,
• non alloca memoria
• può puntare a una stringa esistente con un certo offset, e
• ha un livello di indiretta del puntatore in meno rispetto a std::string&.

Ciò significa che una stringa_vista può spesso evitare copie, senza dover affrontare i puntatori non elaborati.

Nel codice moderno, std::string_viewdovrebbe sostituire quasi tutti gli usi dei const std::string&parametri di funzione. Questa dovrebbe essere una modifica compatibile con la fonte, poiché std::stringdichiara un operatore di conversione a std::string_view.

Solo perché una vista stringa non aiuta nel tuo caso d'uso specifico in cui è comunque necessario creare una stringa non significa che sia una cattiva idea in generale. La libreria standard C ++ tende ad essere ottimizzata per generalità piuttosto che per comodità. L'argomento "meno sicuro" non regge, in quanto non dovrebbe essere necessario creare la vista stringa da soli.

Trovo sorprendente questo consiglio, poiché sembra sostenere la sostituzione universale di un oggetto relativamente sicuro con un oggetto meno sicuro (sostanzialmente un puntatore e una lunghezza glorificati), principalmente a fini di ottimizzazione.

Penso che questo sia leggermente frainteso lo scopo di questo. Sebbene si tratti di una "ottimizzazione", dovresti davvero pensarlo come sganciato da dover usare a std::string.

Gli utenti di C ++ hanno creato dozzine di diverse classi di stringhe. Classi di stringa a lunghezza fissa, classi ottimizzate SSO con la dimensione del buffer come parametro del modello, classi di stringhe che memorizzano un valore di hash utilizzato per confrontarle, ecc. Alcune persone usano persino stringhe basate su COW. Se c'è una cosa che i programmatori C ++ amano fare, è scrivere classi di stringhe.

E questo ignora le stringhe create e possedute dalle librerie C. Nudo char*, forse con una taglia di qualche tipo.

Quindi, se stai scrivendo una libreria e prendi un const std::string&, ora l'utente deve prendere qualsiasi stringa che stava usando e copiarlo in un std::string. Forse dozzine di volte.

Se si desidera accedere all'interfaccia std::stringspecifica della stringa, perché è necessario copiare la stringa? È un tale spreco.

I motivi principali per non prendere string_viewun parametro come sono:

1. Se il tuo obiettivo finale è passare la stringa a un'interfaccia che accetta una stringa terminata con NUL ( fopen, ecc.). std::stringè garantito per essere NUL terminato; string_viewnon lo è. Ed è molto semplice eseguire il substring di una vista per renderla non NUL terminata; std::stringla stringa secondaria a copierà la sottostringa in un intervallo terminato con NUL.

   Ho scritto uno speciale tipo di stile string_view terminato con NUL proprio per questo scenario. Puoi eseguire la maggior parte delle operazioni, ma non quelle che interrompono il suo stato terminato con NUL (tagliando dalla fine, per esempio).

2. Problemi di vita. Se hai davvero bisogno di copiarlo std::stringo altrimenti la matrice di caratteri sopravvive alla chiamata della funzione, è meglio dichiararlo in anticipo prendendo un const std::string &. O semplicemente un std::stringparametro come valore. In questo modo, se hanno già una tale stringa, puoi rivendicarne immediatamente la proprietà e il chiamante può spostarsi nella stringa se non ha bisogno di conservarne una copia.