Kiedy powinienem używać string_view w interfejsie?

Korzystam z biblioteki wewnętrznej, która została zaprojektowana tak, aby naśladować proponowaną bibliotekę C ++ , a czasami w ciągu ostatnich kilku lat widzę, że jej interfejs zmienił się z używania std::stringna string_view.

Dlatego sumiennie zmieniam kod, aby dostosować się do nowego interfejsu. Niestety, muszę przekazać parametr std :: string i coś, co jest wartością zwracaną std :: string. Więc mój kod zmienił się z czegoś takiego:

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

do

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()));
}

I naprawdę nie wiem, co ta zmiana kupił mnie jako klienta API, inne niż więcej kodu (aby ewentualnie zepsuć). Wywołanie API jest mniej bezpieczne (ponieważ API nie jest już właścicielem pamięci dla swoich parametrów), prawdopodobnie zapisał moją pracę programu 0 (ze względu na optymalizacje przenoszenia kompilatory mogą teraz zrobić), a nawet gdyby zaoszczędził pracę, byłoby to tylko kilka przydziałów, które nie zostaną i nigdy nie zostaną wykonane po starcie lub gdzieś w dużej pętli. Nie dla tego API.

Podejście to wydaje się jednak zgodne z radą, którą widzę gdzie indziej, na przykład z odpowiedzią :

Na marginesie, od C ++ 17 powinieneś unikać przekazywania const std :: string & na rzecz std :: string_view:

Uważam tę radę za zaskakującą, ponieważ wydaje się, że opowiada się ona za uniwersalnym zastąpieniem stosunkowo bezpiecznego obiektu mniej bezpiecznym (w zasadzie uwielbionym wskaźnikiem i długością), przede wszystkim w celach optymalizacji.

Kiedy więc należy użyć string_view, a kiedy nie?

1. Czy funkcjonalność przyjmująca wartość musi przejąć na własność ciąg? Jeśli tak, użyj std::string(non-const, non-ref). Ta opcja daje również możliwość jawnego przejścia do wartości, jeśli wiesz, że nie będzie ona nigdy więcej używana w kontekście wywoływania.
2. Czy funkcjonalność po prostu odczytuje ciąg? Jeśli tak, użyj std::string_view(const, non-ref), ponieważ string_viewmoże to obsługiwać std::stringi char*łatwo bez problemu i bez robienia kopii. To powinno zastąpić wszystkie const std::string&parametry.

Ostatecznie nigdy nie powinieneś dzwonić do std::string_viewkonstruktora takim, jakim jesteś. std::stringma operator konwersji, który automatycznie obsługuje konwersję.

A std::string_viewprzynosi niektóre zalety A const char*do C ++: w przeciwieństwie std::stringdo string_view

• nie ma pamięci,
• nie przydziela pamięci,
• może wskazywać na istniejący ciąg z pewnym przesunięciem, oraz
• ma jeden poziom wskaźnika pośredniego niższy niż std::string&.

Oznacza to, że string_view może często unikać kopiowania, bez konieczności radzenia sobie z surowymi wskaźnikami.

W nowoczesnym kodzie std::string_viewpowinien zastąpić prawie wszystkie zastosowania const std::string&parametrów funkcji. Powinna to być zmiana zgodna ze źródłem, ponieważ std::stringdeklaruje operator konwersji na std::string_view.

To, że widok ciągu nie pomaga w konkretnym przypadku użycia, w którym musisz utworzyć ciąg, nie oznacza, że ​​jest to ogólnie zły pomysł. Standardowa biblioteka C ++ jest zazwyczaj zoptymalizowana pod kątem ogólności, a nie wygody. Argument „mniej bezpieczny” nie ma zastosowania, ponieważ samodzielne tworzenie widoku łańcucha nie powinno być konieczne.

Uważam tę radę za zaskakującą, ponieważ wydaje się, że opowiada się ona za uniwersalnym zastąpieniem stosunkowo bezpiecznego obiektu mniej bezpiecznym (w zasadzie uwielbionym wskaźnikiem i długością), przede wszystkim w celach optymalizacji.

Myślę, że jest to nieco nieporozumienie w tym celu. Chociaż jest to „optymalizacja”, naprawdę powinieneś myśleć o tym jako o odrywaniu się od konieczności używania std::string.

Użytkownicy C ++ stworzyli dziesiątki różnych klas ciągów. Klasy ciągów o stałej długości, klasy zoptymalizowane pod kątem SSO z parametrem szablonu bufora, klasy ciągów przechowujące wartość skrótu używaną do ich porównywania itp. Niektóre osoby używają nawet ciągów opartych na COW. Jeśli jest coś, co programiści C ++ lubią robić, to pisz klasy ciągów.

I to ignoruje ciągi, które są tworzone i będące własnością bibliotek C. Nadzy char*, może o jakimś rozmiarze.

Więc jeśli piszesz jakąś bibliotekę, a bierzesz const std::string&, użytkownik musi teraz pobrać dowolny ciąg, którego używał i skopiować go do std::string. Może dziesiątki razy.

Jeśli chcesz uzyskać dostęp do std::stringinterfejsu specyficznego dla łańcucha, dlaczego musisz go skopiować ? To takie marnotrawstwo.

Główne powody, dla których nie należy przyjmować string_viewparametru jako:

1. Jeśli Twoim ostatecznym celem jest przekazanie łańcucha do interfejsu, który pobiera łańcuch zakończony znakiem NUL ( fopenitp.). std::stringgwarantowane jest zakończenie NUL; string_viewnie jest. I bardzo łatwo jest podciąć widok, aby nie był zakończony NUL; std::stringpodciągi a skopiują podciąg do zakresu zakończonego NUL.

   Napisałem specjalny typ stylu string_view zakończony NUL dla dokładnie tego scenariusza. Możesz wykonywać większość operacji, ale nie takich, które niszczą status zakończony przez NUL (na przykład przycinanie od końca).

2. Problemy z życiem. Jeśli naprawdę potrzebujesz skopiować tę std::stringtablicę lub w inny sposób mieć tablicę znaków, która przeżyje wywołanie funkcji, najlepiej jest to stwierdzić z góry, wykonując znak const std::string &. Lub po prostu std::stringjako parametr wartości. W ten sposób, jeśli mają już taki ciąg, możesz natychmiast przejąć jego własność, a osoba dzwoniąca może przenieść się do ciągu, jeśli nie musi przechowywać jego kopii.