-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std::string_ref как обертка над const char* #504
Comments
zstring_view |
В чём предполагаются отличия от |
std::string_view имеет больший размер, так-как он должен содержать либо два указателя, либо указатель и размер. Из-за этого больше накладные расходы при передаче, в аргумента функции и т.п. Указатель/ссылка на "const std::string" выглядят неплохо, но по сути это "указатель на указатель", что требует двойного разыменования. std::string_view не гарантирует, что ссылается на строку, оканчивающуюся нулем. Поэтому, принимая откуда-то std::string_view и если эту строку надо далее передать в качестве const char*, это нельзя сделать без выделения/копирования данных, даже, если в 99% случаев принимаемый std::string_view действительно ссылается строку с нулем. Т.е. полностью перейти на "std::string/std::string_view" и отказаться от "const char*" нельзя. По крайней мере не заплатив за это цену в виде потери производительности. И в коде "const char*" для строк всё равно будет использоваться. Но хочется удобства и единообразия с тем что есть в std. Поэтому хочется иметь обертку над "const char*", класс std::string_view строго такой оберткой не является, у него немного другой смысл. |
Но
Можем ли мы количественно оценить величину этих расходов? |
Невозможно без UB проверить, является ли произвольный |
Может это как-то в стандарт C добавить, хотя бы и не с блестящей производительностью? |
Предлагаю также рассмотреть ситуацию, когда о куче не идёт и речи:
|
Большой разницы не вижу. Если память выделена, куча это или стек, то можно "просто" определить, что |
Тогда несколько конструкторов у std::string_view придется выпилить. Интересно, почему сразу так не сделали? |
Потому что текущий Поэтому давайте вернёмся к обсуждению исходного предложения. |
Я количественно оценить не готов. Но на каждый такой std::string_view нужно два (указателя/целых числа) вместо одного (для string_ref), быстрее закончатся регистры процессора и аргументы функции придется передавать через стек. |
Ну вот пусть оно в 1% случаев копирует с вызывающей стороны, чем копирует в 100% случаев в вызываемом коде. |
Нашёл прошлое предложение: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1402r0.pdf
Обычно как компилятор, так и железо хорошо этот процесс оптимизируют. Поэтому без количественных данных выглядит как premature optimization. |
Хотелось бы иметь обертку над const char* у которой implicit конструктор от const char*, определены операторы сравнения и ряд других полезных функций. Мне кажется странным, но такого нет в библиотеке до сих пор. Может быть есть на то какие-то причины. Хотелось бы обсудить эту тему.
The text was updated successfully, but these errors were encountered: