Почему в std :: string_view нет методов assign () и clear ()?

Question

Мне кажется, что реализация этих методов проста, и они сделают использование std::string и std::string_view более взаимозаменяемыми. В конце концов, std::string_view имеет конструкторы, которые оставляют объект в том же состоянии, что и эти методы. Можно обойти отсутствующие методы, как это:

std::string s {"abcd"};
std::string_view v {s.c_str()};
std::cout << "ctor:   " << v << std::endl; // "abcd"
v = {s.c_str() + 1, 2};
std::cout << "assign: " << v << std::endl; // "bc"
v = {nullptr}; // or even v = {};
std::cout << "clear:  " << v << std::endl; // ""

Итак, каковы причины не включения этих двух очевидных методов в стандарт?

UPDATE: Один общий вопрос в ваших комментариях, кажется, «Какой смысл?», Поэтому я дам вам некоторый контекст. Я анализирую большую строку, в результате чего получается структура подстрок. Эта результирующая структура является естественным кандидатом на просмотр строк, поэтому мне не нужно копировать все эти строки, которые даже перекрываются. Частично результатом являются сопоставления со строковыми представлениями, поэтому мне может потребоваться создать их пустыми, когда я получу ключ, и заполнить их позже, когда я получу значение. При разборе мне нужно отслеживать промежуточные строки, что включает в себя обновление и сброс их. Теперь их можно заменить и строковыми представлениями, и так я поступил с этими недостающими функциями. Конечно, я мог бы продолжать использовать строки или заменить их простыми старыми парами ptr-ptr или ptr-size, но это именно то, для чего std::string_view, верно?

Answer 1

Мне кажется, что реализация этих методов проста, и они сделают использование std::string и std::string_view более взаимозаменяемыми.

std::string_view не предназначен для замены std::string. Он предназначен для замены const std::string&. assign и clear не являются функциями-членами const std::string&, которые вы можете вызвать.

Answer 2

Это только когда-то будет спекуляцией, но общее мнение, как представляется, заключается в том, что эти операции будут неясными.

Лично я думаю, что "очистка представления" имеет смысл (и давайте также не будем забывать)что remove_prefix и remove_suffix существуют! Хотя см. ниже ...), но я также согласен с тем, что существуют и другие распространенные толкования, которые имеют меньший смысл.Напомним, что string_view предназначен для дополнения const std::string&, а не std::string, и ни одна из названных вами функций не является частью постоянного интерфейса std::string.

Если честно, тот факт, чтонам этот разговор вообще нужен, сам по себе, вероятно, является хорошей причиной, чтобы вообще не иметь этой функции.

С окончательное предложение по string_view, следующий отрывокне о assign или clear конкретно, но действует как уместное представление [смеется] в умах комитета по этому вопросу:

s/remove_prefix/pop_front/, etc.

В Kona 2012 я предложил класс range<> с элементами pop_front и т. Д., Которые скорректировали границы диапазона.Дискуссия там показала, что членам комитета было неудобно использовать те же имена для операций с малой дальностью, что и для контейнерных операций .Существующая практика не согласовывает название для этой операции, поэтому я сохранил имя, используемое Google StringPiece.

Это предложение действительно включало clear(), что было бесцеремонновычеркнул из реестра в более позднем, изолированном, обоснованном голодном предложении .

Теперь можно утверждать, что поэтому функции могли быть предоставлены под разными именами, но это никогда не предлагалось,и трудно представить, какие альтернативные имена решат эту проблему, не будучи просто плохими именами для операций.

Поскольку мы можем достаточно легко назначить новый string_view, включая пустой, вся проблема решаетсяпросто не удосужившись заняться этим.

Answer 3

Интерфейс std::string имеет плохую репутацию из-за его взорванного API , поэтому очень маловероятно, что std::string_view получит столько же методов, сколько std::string только потому, что он удобен или делает два типа более взаимозаменяемы.

Но что более важно, эти типы не должны быть взаимозаменяемыми. Что означает «очистить» представление о контейнере символов? Поскольку clear() присутствует во всех контейнерах STL и делает что-то значимое, наличие std::string_view::clear() было бы весьма запутанным.

Кроме того, просмотр некоторых данных предназначен для временного потребления, например, параметр функции только для чтения. Почему вы хотите назначить его в любом случае? Вот пример подписи функции, которая использует std::string_view:

// Called e.g. with "x86_64-Darwin-16.7.0"
std::string_view extractOSName(std::string_view configStr)
{
    // Parse input, return a new view. Lifetime/ownership managed by caller.
    // No need to re-assign anything, let alone "clearing" them.
}