Несколько дней назад я столкнулся с тонкой ошибкой, где код выглядел примерно так:
ostringstream ss;
int anInt( 7 );
ss << anInt << "HABITS";
ss << ends;
string theWholeLot = ss.str();
Проблема заключалась в том, что ends вставлял '\ 0' в ostringstream, поэтому theWholeLot действительно выглядел как "7HABITS\0" (т.е. нуль в конце)
Теперь это не появилось, потому что theWholeLot использовался для приема части const char * с помощью string::c_str(). Это означало, что нуль был замаскирован, поскольку он стал просто разделителем. Однако, когда это изменилось, чтобы использовать строки повсюду, значение null внезапно означало что-то и сравнения, такие как:
if ( theWholeLot == "7HABITS" )
не удастся. Это заставило меня задуматься: предположительно причина ends - возврат к дням ostrstream, когда поток обычно не заканчивается нулем и должен быть таким, чтобы str() (который затем выдавал не a string, но a char *) будет работать правильно.
Однако теперь, когда невозможно исключить a char * из ostringstream, использование ends не только лишнее, но и потенциально опасно, и я планирую удалить их все из кода моих клиентов.
Может ли кто-нибудь увидеть очевидную причину использования ends в среде std::string?
Вы, по сути, ответили на свой вопрос, так же подробно нужно. Я, конечно, не могу думать о какой-либо причине использовать std::ends, когда std::string и std::stringstream обрабатывают все, что для вас.
Итак, чтобы явно ответить на ваш вопрос, нет, нет смысла использовать std::ends в среде std::string.
Есть несколько API, которые ожидают "строковый массив" с несколькими строками с нулевым завершением, двойной ноль, чтобы отметить конец. Раймонд Чан недавно недавно рассказал об этом, прежде всего, чтобы продемонстрировать, как часто это происходит.