@ProCxx - страница 1697 - Telegram web archive

Constantine

О! Антон. Вам наверняка будет интересно. Нашел очень странный фич оптимизатора вижака

Constantine

https://godbolt.org/g/HUqhpq

🐙 Antony

а почему просто не написать: operator string_view() const noexcept & ;

тогда сломается void foo(string_view sw); foo(string{"Hello word!"}); // OK, right now

Constantine

https://godbolt.org/g/HUqhpq

В этом примере можно заметить, что функция f1 будет сгенерирована безумно плохо при компиляции с /EHsc

Aidar

ох не нравятся мне костыли в языке

Constantine

В этом примере можно заметить, что функция f1 будет сгенерирована безумно плохо при компиляции с /EHsc

Все это исправляется явным указанием конструктора const_iterator https://godbolt.org/g/UAxF1B

Constantine

Мораль: чтобы вижак нормально работал, нужно, видимо, не использовать struct-init

🐙 Antony

Если у вас есть учётка, попробуйте отправить им багу.

Aidar

Так вот, по поводу идеи: можно уменьшить количество отстреленных пальцев, если запретить хотя бы присовение временных строк в string_view struct string; struct string_view { using charT = char; string_view() noexcept; string_view(const string_view&) noexcept = default; string_view& operator=(const string_view&) noexcept = default; string_view(const charT* str); string_view(const charT* str, unsigned len); //string_view& operator=(string const&); string_view& operator=(string&&) = delete; }; struct string { operator string_view() const noexcept; }; int main () { string_view sw = "Hello"; sw = "world"; //sw = string{}; // fails to cimpile. Hurray! string_view sw2{string{}}; string_view sw3 = string{}; sw = "qwe qwe"; sw = sw3; }

а это выглядит как костыль

Constantine

Я им отправлю, только проблемы с оптимизацией под /EHsc судя по всему очень давние и какие-то by design

Constantine

при этом /EHsc является основной практической настройкой

Constantine

в данном примере такое ощущение, будто компилятор опасается выброшенного исключения при {} - инициализации структуры с size_t

Aidar

а математически можно заставить компиль распозновать удлинение времени жизни в сложных случаях?

🐙 Antony

а математически можно заставить компиль распозновать удлинение времени жизни в сложных случаях?

Да, там Саттер прорабатывает более общее решение, но оно весьма противоречивое

Aidar

на объекты бы повесить те же штуки что и на функции

Constantine

в общем, категорически рекомендую добавлять /EHsc при проверке тех или иных решений для msvc

Constantine

потому что может приводить к полному сбою всей оптимизации

Aidar

на объекты бы повесить те же штуки что и на функции

хотяб для инициализации

Aidar

хотяб для инициализации

а хотя не уг какоето

Aidar

слишком жирно

🐙 Antony

на объекты бы повесить те же штуки что и на функции

Тогда можно получить javascript с вечной проблемой утекающей в непонятном месте памяти

Anatoly

тогда сломается void foo(string_view sw); foo(string{"Hello word!"}); // OK, right now

а почему надо держаться за этот кейс?

Berkus

да ну его

го писать на го - тупо же звучит, поэтому и не пишет :D

🦥Alex Fails

ага, да и к тому же я ж уже так шутил)

🐙 Antony

а почему надо держаться за этот кейс?

это популярный и нормальный кейс В Boost его попробовали убрать, и поломался весь пользовательский код

Anatoly

интересно, какой смысл вкладывался. даже если предположить, что сигнатура была до появления std::string_view просто std::string.

🐙 Antony

а почему надо держаться за этот кейс?

В более вменяемом виде он выглядит как void foo(string_view sw); string bar(); foo(bar()); // OK, right now

Anatoly

ok

Constantine

а математически можно заставить компиль распозновать удлинение времени жизни в сложных случаях?

я плохо понимаю, зачем

Constantine

нужно просто нормально написать для всяких std::vector::operator [] ref-quailifier

Aidar

ну вон там стрингвью

Anatoly

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

Constantine

в string_view нужно запретить вообще временные объекты передавать)

Aidar

просто какбы у stringview семантика ссылки неявная

Aidar

и вроде хранить можно изза этого

Constantine

я бы сказал, что в C++ есть чудесная проблема преобразования && в const&

Aidar

в string_view нужно запретить вообще временные объекты передавать)

выше пример

Aidar

даже 2 или 3

Constantine

а почему просто не написать: operator string_view() const noexcept & ;

потому что && можно в const& преобразовать

Constantine

const& сигнатура аналогична const

Constantine

operator string_view() noexcept & должно быть

Constantine

string_view это принципиально & тип, насколько я понимаю, он не может захватить владение

🐙 Antony

operator string_view() noexcept & должно быть

Это всё равно не 100% гарантия string_view sw; { string s{"hello word. hello word. hello word. hello word. hello word. "}; sw = s; } std::cout << sw; // Oops!

Constantine

Это всё равно не 100% гарантия string_view sw; { string s{"hello word. hello word. hello word. hello word. hello word. "}; sw = s; } std::cout << sw; // Oops!

По моему текущего мнению все хорошо, если считать 1. Объект & живет минимум scope выше чем оператор, и только с него можно снимать view 2. Объект && живет оператор

Constantine

Т.е. если я создаю или присваиваю view-объект с нарушением правил жизни, я сам буратино

Constantine

Хотя я предпочел бы иметь view-объекты немутабельными

Constantine

Как &

Berkus

Enter Rust

Constantine

По моему текущего мнению все хорошо, если считать 1. Объект & живет минимум scope выше чем оператор, и только с него можно снимать view 2. Объект && живет оператор

Вроде как в этих правилах все хорошо, если view объект создается из объекта &, потому что переданный объект гарантированно живет в scope, в котором объявлен view-объект

Aidar

Это всё равно не 100% гарантия string_view sw; { string s{"hello word. hello word. hello word. hello word. hello word. "}; sw = s; } std::cout << sw; // Oops!

я поэтому и сказал что это костыль

Aidar

ну там не нужна гарантия

Aidar

давайте оставим как есть

Constantine

По моему текущего мнению все хорошо, если считать 1. Объект & живет минимум scope выше чем оператор, и только с него можно снимать view 2. Объект && живет оператор

Из этого вытекает правило при возврате & использовать & как ref qualifier и все еще все хорошо

Constantine

Ну кроме того, что && конвертируемо языком в const& и это все ломает