АК
ну с точки зрения здравого смысла substr от неизменяемой строки как раз должен быть вьюхой.
это очень субъективно
Size: a a a
2020 August 05
ГH
Так это проблема string, а не view.
Ну вот я например, когда этот код увидел как пример UB, я хз где там UB.
ГH
Пришлось комментарии читать.
ПК
{ std::string_view ret = str.substr(1); return ret; } // здесь же будет висячая ссылка?
Если заменить
string_view на const std::string&, то то же самое UB будет. То есть это никак не относится к string_view, оно тут ничего не ухудшилоПК
ты вернул ссылку на локальную переменную считай
ПК
Это всегда уб было
🎄T
Если заменить
string_view на const std::string&, то то же самое UB будет. То есть это никак не относится к string_view, оно тут ничего не ухудшилоПочему с const std::string& уб?
ПК
Почему с const std::string& уб?
Потому же почему со string_view уб
🎄T
Потому же почему со string_view уб
const std::string&продлевает время жизни. Если возвращаемое значение это ссылка/вью, то уб
AK
Потому же почему со string_view уб
Не, тут же другая история
const std::string& реально продлит время жизни объекта
const std::string& реально продлит время жизни объекта
AK
А c string_view оно умрёт в конструкторе
ПК
Ссылка для экспериментов: https://godbolt.org/z/z8fMxq
Ну теперь замени
string_view на const std::string&ГH
clang ругается.
D
Ссылка для экспериментов: https://godbolt.org/z/z8fMxq
Так substr в любом случае возвращает временный объект
ПК
clang ругается.
Ну т.е. уб неоткуда не появилось новое
ГH
а вот так нет:
std::string_view ret = std::string_view(str).substr(1);ПК
А c string_view оно умрёт в конструкторе
Из функции всё равно ссылка выходит, так что это неважно
m
А c string_view оно умрёт в конструкторе
Это не совсем точная формулировка. Временный объект строки будет жить до конца выражения. То есть конструтор string_view отработает корректно. Но после
; временный объект будет разрушен и view будет указывать на освобожденную память.