Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>Сказать, что функция возвращает ссылку, это всё равно, что сказать, что функция возвращает имя. ЕМ>Э-э-э... А как еще можно более коротко и менее формально сказать "функция возвращает значение ссылочного типа"? В английском термины "reference type" и "reference" в отношении значений тоже эквивалентны.
Неформально можно сказать многое, в том числе, что функция возвращает ссылку, но считать, что при этом на самом деле возвращается некий объект-ссылка — ошибка.
И каждый день — без права на ошибку...
Re[3]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, sergii.p, Вы писали:
SP>Получается, проблема таки в синтаксисе — нет механизма переприсвоить ссылку. И это таки баг языка (имхо конечно).
Это не ошибка языка, а так и задумано.
SP>p.s. Кстати, заметьте, насколько в Rust тривиальное определение ссылки. Это просто адрес. А в С++ уже на 10 страниц развели спор об определении.
Вот в Json тоже писали краткие определения, а на практике оказалось, что в результате очень много ошибок о которых авторы не подумали.
let a = "объект с данными в куче".to_string();
// объект передан переменной b
// переменная a становится неинициализированной
let b = a;
// ошибка!
let c = a;
В чём смысл такого? Или все такие ошибки отлавливаются на этапе компиляции?
И каждый день — без права на ошибку...
Re[4]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, sergii.p, Вы писали:
SP>>Получается, проблема таки в синтаксисе — нет механизма переприсвоить ссылку. И это таки баг языка (имхо конечно). BFE>Это не ошибка языка, а так и задумано.
понятно, что так и задумано, но мне кажется в долгосрочной перспективе ошиблись.
Сейчас ведь даже нельзя написать что-то типа такого:
хотя optional для этого по сути и задумывался.
BFE>Вот в Json тоже писали краткие определения, а на практике оказалось, что в результате очень много ошибок о которых авторы не подумали.
ну а в С++ пример обратный. Перемудрили.
BFE>
BFE>let a = "объект с данными в куче".to_string();
BFE>// объект передан переменной b
BFE>// переменная a становится неинициализированной
BFE>let b = a;
BFE>// ошибка!
BFE>let c = a;
BFE>
BFE>В чём смысл такого? Или все такие ошибки отлавливаются на этапе компиляции?
немного не понял вопроса. Тут же не ссылки. Тут что-то типа такого в переводе на C++
auto a = std::string {"abc"};
auto b = std::move(a);
auto c = std::move(a);
всякие cpp check это тоже отлавливают.
Re[5]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, sergii.p, Вы писали:
SP>>>Получается, проблема таки в синтаксисе — нет механизма переприсвоить ссылку. И это таки баг языка (имхо конечно). BFE>>Это не ошибка языка, а так и задумано. SP>понятно, что так и задумано, но мне кажется в долгосрочной перспективе ошиблись.
Не, то, чего хочет Shmj не согласуется с принципом бедняка: "Не платить за то, что не используется". Если попробовать полностью описать как должно работать переназначение ссылок, то первым делом сама ссылка станет объектом и будет занимать какую-то память, потом появится подсчёт ссылок и в конечном итоге получится конструкция функционально неотличимая от std::shared_ptr<NotNullPtr<T>>
SP>Сейчас ведь даже нельзя написать что-то типа такого: SP>
Не подойдёт?
SP>ну а в С++ пример обратный. Перемудрили.
С++ был придумал, развивался и развивается по эволюционной модели развития проекта, что, конечно, несёт с собой отрицательные аспекты.
И каждый день — без права на ошибку...
Re[5]: Вопрос про ссылки - что бы сломалось, если...
SP>>>Получается, проблема таки в синтаксисе — нет механизма переприсвоить ссылку. И это таки баг языка (имхо конечно). BFE>>Это не ошибка языка, а так и задумано.
SP>понятно, что так и задумано, но мне кажется в долгосрочной перспективе ошиблись. SP>Сейчас ведь даже нельзя написать что-то типа такого:
SP>
да, приходится так писать. Но это же "теоретически" неверно. Никто выходящий указатель на nullptr проверять не будет, компилятор за этим не проследит. Короче нафига тогда std::optional?
Re[7]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, sergii.p, Вы писали:
SP>Но это же "теоретически" неверно.
Это смотря с какой теории смотреть.
SP>Никто выходящий указатель на nullptr проверять не будет, компилятор за этим не проследит.
Но ведь так же можно сказать, что и optional на пустоту проверять никто не будет.
Тем не менее код вида:
std::optional<T> r = try_get_object();
if(r) r->do_something();
пишут.
И в этом плане optional по интерфейсу очень похож на указатель.
SP>Короче нафига тогда std::optional?
Если смотреть на std::optional как на объект, который предоставляет место для хранения T, при этом еще и следит за временем жизни T, то получается очень удобная штука.
Не нужно писать самому что-то вроде:
И если смотреть на std::optional так, то становится понятно, почему нет смысла в optional помещать ссылку. По крайней мере с моей колокольни удобно смотреть так.
Re[8]: Вопрос про ссылки - что бы сломалось, если...
есть некоторое общее правило С++
если передается указатель
ему можно сделать delete
можно ли в том find сделать delete тому указателю что вернется?
вряд ли
рискованно
опасно
уб
уц
уд
уе
Re[9]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, reversecode, Вы писали:
R>есть некоторое общее правило С++ R>если передается указатель R>ему можно сделать delete R>можно ли в том find сделать delete тому указателю что вернется?
Есть общее правило: писать с выделением предложений знаками препинания, начиная каждое новое предложение с заглавной буквы. Но некоторым альтернативно одаренным на это пох. А на мнение альтернативно одаренных откровенно начхать.
Особенно если эти альтернативно одаренные ведут себя типа как суперпрофи, но при этом не в курсе про правило "никаких голых владеющих указателей"
Re[8]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, so5team, Вы писали:
S>Но ведь так же можно сказать, что и optional на пустоту проверять никто не будет.
ага. И эти вопросы я бы хотел задать тем, кто принимал optional в таком виде в стандарт
S>Если смотреть на std::optional как на объект, который предоставляет место для хранения T, при этом еще и следит за временем жизни T, то получается очень удобная штука.
это как бы побочный эффект optional. Не думаю, что создавался для этого. Для меня классическое применение в методах типа find. Во многих языках (Haskell, Rust, Zig) так, но почему-то не в С++.
Re[9]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, sergii.p, Вы писали:
S>>Но ведь так же можно сказать, что и optional на пустоту проверять никто не будет.
SP>ага. И эти вопросы я бы хотел задать тем, кто принимал optional в таком виде в стандарт
Для другого вида в стандарт сначала следовало бы принять полноценные алгебраические типы и паттерн-матчинг. Но этого и в C++26, вероятно, не будет. Что уж про C++17 говорить.
S>>Если смотреть на std::optional как на объект, который предоставляет место для хранения T, при этом еще и следит за временем жизни T, то получается очень удобная штука.
SP>это как бы побочный эффект optional.
Ну как бы не совсем, т.к. мы же в рамках C++, в котором доминирует value-семантика. А раз у нас value, значит optional играет роль хранилища для этого value + булевый признак актуальности значения в хранилище.
SP>Для меня классическое применение в методах типа find.
Ну вот в том же Rust есть find для str. Он же не optional с ссылкой внутри возвращает.
Сделайте свою функцию как:
и будете иметь тоже, что и в Rust-е.
SP>Во многих языках (Haskell, Rust, Zig) так, но почему-то не в С++.
Опять же, если сравнивать C++ с другими языками, в которых, во-первых, есть reference-типы и GC, и, во-вторых, есть алгебраические типы и паттерн-матчинг, то там можно делать совсем не так, как в C++ (я про Haskell и Scala). Но в C++ нет ни того, ни другого, приходится выкручиваться.
Re[7]: Вопрос про ссылки - что бы сломалось, если...
SP>Оно как бы компилируется, но такое количество костылей на единицу строчки неприемлемо.
Честно говоря я не понял, что вам не нравится и чего хочется.
Я не знаю, для чего задумывался std::optional, но в качестве результата я его ни разу не использовал. Использовал для указания отсутствия данного.
И вообще, если у вас в качестве параметра функтор, то зачем вообще что-то возвращать?
const std::vector<std::string_view> vec = {"123", "234", "4", "567", "321"};
unsigned int nCount = 0; // счётчик найденныхauto fnOut = [&nCount](const auto& x){ std::cout << '\n' << x; ++nCount;}; // вывод и подсчёт
std::ranges::find_if(
vec, // никаких begin/end
[
n = 2, // искать не больше двух
&fn = fnOut // операция над найденным
]
(const auto& x) mutable
{
if (x.contains('3')) // только элементы содержащие '3'
{
--n; // изменили счётчик
fn(x);// применили операцию
}
return 0 == n; // условие останова
}
);
std::cout << '\n' << "Total: " << nCount << " element(s)";
И каждый день — без права на ошибку...
Re[8]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, B0FEE664, Вы писали:
BFE>Честно говоря я не понял, что вам не нравится и чего хочется.
auto tmp = std::string_view{"123"};
std::cout << find(vec, tmp).value_or(std::ref(tmp)).get();
нельзя использовать временный объект. std::ref не конструируется от временного
приходится заводить бессмысленную переменную tmp
нужно дополнительно вызывать get()
хочется такого
Здравствуйте, graniar, Вы писали:
G>Используй указатели и не ломай мозг надуманными проблемами. G>Ссылки нужны только для локального удобства, например
А как же передача в функцию по ссылке? Это и удобно и память лишний раз не копируется.
Re[3]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, Shmj, Вы писали:
S>А как же передача в функцию по ссылке? Это и удобно и память лишний раз не копируется.
Разве что при развертывании инлайн-функции. Но там и указатели прекрасно прооптимизируются. А в нормальном вызове аргумент-ссылка и так передается через стэк как указатель, как же иначе то?
Вобщем не дают ссылки никакого магического преимущества.