Коли я повинен використовувати string_view в інтерфейсі?

Я використовую внутрішню бібліотеку, яка була створена для імітації запропонованої бібліотеки C ++ , і десь за останні кілька років я бачу, що її інтерфейс змінився від використання std::stringна string_view.

Тож я достойно змінюю свій код, щоб відповідати новому інтерфейсу. На жаль, те, що мені потрібно передати, - це параметр std :: string, а також те, що є поверненим значенням std :: string. Тому мій код змінився з чогось такого:

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

до

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

Я дійсно не бачу, що ця зміна придбала мене як клієнта API, окрім більшого коду (можливо, накручується). Виклик API менш безпечний (через те, що API більше не володіє сховищем для його параметрів), ймовірно, врятував мою програму 0 роботи (завдяки компіляторам оптимізацій переміщення зараз можна зробити), і навіть якщо це збереже роботу, це було б лише пара виділень, які не будуть і ніколи не будуть зроблені після запуску або десь у великому циклі. Не для цього API.

Однак, схоже, цей підхід дотримується порад, які я бачу в інших місцях, наприклад, у цій відповіді :

На відміну від C ++ 17 вам слід уникати передачі const std :: string & на користь std :: string_view:

Я вважаю цю пораду дивовижною, оскільки, здається, пропонується повсюдна заміна відносно безпечного об'єкта на менш безпечний (в основному прославлений покажчик і довжина), насамперед для оптимізації.

Отже, коли слід використовувати string_view, а коли не слід?

1. Чи потрібно функціоналу, що приймає значення, взяти право власності на рядок? Якщо так, використовуйте std::string(non-const, non-ref). Цей параметр дає вам можливість явно переміщати значення, а також якщо ви знаєте, що він ніколи не буде використаний знову в контексті виклику.
2. Чи функціонал просто читає рядок? Якщо так, використовуйте std::string_view(const, non-ref), це тому, що string_viewможна легко std::stringі char*без проблем видавати копію. Це повинно замінити всі const std::string&параметри.

Зрештою, вам ніколи не потрібно дзвонити std::string_viewконструктору таким, яким ви є. std::stringмає оператор перетворення, який обробляє перетворення автоматично.

A std::string_viewприносить деякі переваги від a const char*до C ++: на відміну від std::stringstring_view

• не володіє пам'яттю,
• не виділяє пам'ять,
• може вказувати на існуючий рядок при деякому зміщенні, і
• має один менший рівень непрямості вказівника, ніж a std::string&.

Це означає, що string_view часто може уникати копій, не маючи справи з необробленими покажчиками.

У сучасному коді std::string_viewслід замінити майже всі const std::string&параметри використання функцій. Це має бути зміна, сумісна з джерелами, оскільки std::stringоголошує оператора перетворення в std::string_view.

Тільки тому, що подання рядка не допомагає у вашому конкретному випадку використання, де вам все одно потрібно створити рядок, ще не означає, що це взагалі погана ідея. Стандартна бібліотека C ++, як правило, оптимізується для загальності, а не для зручності. Аргумент "менш безпечний" не відповідає, оскільки не слід створювати перегляд рядків самостійно.

Я вважаю цю пораду дивовижною, оскільки, здається, пропонується повсюдна заміна відносно безпечного об'єкта на менш безпечний (в основному прославлений покажчик і довжина), насамперед для оптимізації.

Я думаю, це трохи нерозуміє мету цього. Незважаючи на те, що це "оптимізація", ви дійсно повинні вважати це тим, що відмовляєте себе від необхідності використання std::string.

Користувачі C ++ створили десятки різних класів струн. Класи рядків з фіксованою довжиною, оптимізовані для SSO класи, розмір буфера - параметр шаблону, рядкові класи, які зберігають хеш-значення, яке використовується для їх порівняння тощо. Деякі люди навіть використовують рядки на основі COW. Якщо є одна річ, яку люблять робити програмісти на C ++, це писати строкові класи.

І це ігнорує рядки, які створені та належать бібліотекам C. Голі char*s, можливо, з розміром якогось.

Отже, якщо ви пишете якусь бібліотеку, а ви берете файл const std::string&, користувач тепер повинен взяти будь-який рядок, який він використовував, і скопіювати його в std::string. Може, десятки разів.

Якщо ви хочете отримати доступ до std::stringінтерфейсу, орієнтованого на рядок, навіщо вам копіювати рядок? Ось така трата.

Принципові причини не приймати а string_view за параметр такі:

1. Якщо ваша кінцева мета - передати рядок до інтерфейсу, який приймає рядок, що закінчується NUL ( fopenтощо).std::stringгарантовано припинено NUL; string_viewні. І дуже легко підкреслити подання, щоб зробити його не закінченим NUL; підрядка a std::stringскопіює підрядку в діапазон, що закінчується NUL.

   Я написав спеціальний тип стилю string_view, що закінчується NUL, саме для цього сценарію. Ви можете робити більшість операцій, але не ті, що порушують його статус, що припиняється NUL (наприклад, обрізка з кінця).

2. Життєві питання. Якщо вам дійсно потрібно скопіювати те std::stringабо інше, щоб масив символів пережив виклик функції, найкраще вказати це наперед, взявши a const std::string &. Або просто std::stringяк параметр значення. Таким чином, якщо вони вже мають такий рядок, ви можете негайно заявити право власності на нього, і абонент може перейти до рядка, якщо їм не потрібно зберігати його копію.