Re: А вы с какой целью интересуетесь?
От: so5team https://stiffstream.com
Дата: 10.07.24 05:36
Оценка: 21 (3) +7
Есть C++ в котором ссылки не могут менять свое значение. Рассуждения о том, что бы было бы если бы относительно C++ осмысленны так же, как рассуждения о том, что было бы если бы Shmj перестал засирать RSDN своей тупизной.

Вы хотите сделать новый язык, в котором это было бы не так?

Или просто не знаете про существование std::reference_wrapper?
Вопрос про ссылки - что бы сломалось, если...
От: Shmj Ниоткуда  
Дата: 10.07.24 05:10
Оценка: -2 :))) :))
Вопрос такой. Ссылки нельзя переназначить на другой адрес, что мешает использовать их в map и пр.

int a = 10;
int b = 20;
int& ref1 = a;
int& ref2 = b;

// как то сделать, чтобы ref1 и ref2 ссылались на одну область памяти

ref1 = ref2 // присваивает значение b в a, а не присваиваем ref1 адрес ref2, как хотелось бы. А что мешает?


А вот гипотетически можно было бы разрешить присваивать ссылкам адреса других ссылок? Что бы при этом принципиально сломалось? Ведь все-равно вторая ссылка обязательно на что-то ссылается то.
Re: Вопрос про ссылки - что бы сломалось, если...
От: Doom100500 Израиль  
Дата: 10.07.24 05:30
Оценка: +4
Здравствуйте, Shmj, Вы писали:

S>Вопрос такой. Ссылки нельзя переназначить на другой адрес, что мешает использовать их в map и пр.


S>
S>int a = 10;
S>int b = 20;
S>int& ref1 = a;
S>int& ref2 = b;

S>// как то сделать, чтобы ref1 и ref2 ссылались на одну область памяти

S>ref1 = ref2 // присваивает значение b в a, а не присваиваем ref1 адрес ref2, как хотелось бы. А что мешает?
S>


S>А вот гипотетически можно было бы разрешить присваивать ссылкам адреса других ссылок? Что бы при этом принципиально сломалось? Ведь все-равно вторая ссылка обязательно на что-то ссылается то.


Мешает то, что если ссылка начнёт менять то, на что она ссылается, то она сможет принимать и неинициализированное значение, что сразы же убирает уверенность в её валидности. А значит с ссылками придётся работаь как с указателями — то есть постоянно проверять на null, плюс всякие бесконтрольные UB. Это сразу убивает весь смысл ссылок в C++
Спасибо за внимание
Re[5]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 10.07.24 16:32
Оценка: +1 :)
Здравствуйте, Евгений Музыченко, Вы писали:

R>>>std::max(42, 43)

BFE>>А где тут ссылка?
ЕМ>Дык, в определении же.
Не, там есть тип возвращаемого значения, а ссылки — нет.
И каждый день — без права на ошибку...
Re[2]: Вопрос про ссылки - что бы сломалось, если...
От: rg45 СССР  
Дата: 10.07.24 12:56
Оценка: +1
Здравствуйте, B0FEE664, Вы писали:

BFE>Ссылка — это второе имя переменной (в отличии от ссылочного типа). В map не кладут имена переменных. В map кладут значения переменных.


Ну вот зачем ты это пишешь? Чтобы еще больше запутать его? А когда ссылка является результатом выражения, например std::max(42, 43) где там какое имя?
--
Re[4]: Вопрос про ссылки - что бы сломалось, если...
От: rg45 СССР  
Дата: 10.07.24 13:29
Оценка: +1
Здравствуйте, andrey.desman, Вы писали:

AD>Здравствуйте, rg45, Вы писали:


BFE>>>Ссылка — это второе имя переменной (в отличии от ссылочного типа). В map не кладут имена переменных. В map кладут значения переменных.

R>>Ну вот зачем ты это пишешь? Чтобы еще больше запутать его? А когда ссылка является результатом выражения, например std::max(42, 43) где там какое имя?

AD>Так это тип, а не ссылка.


Конечно же, у результата есть тип. Но есть же и сам результат — та самая ссылка. Есть временный объект, к которому привязана ссылка. И это можно даже визуализировать:

std::cout << std::max(42, 43) << std::endl;


Можно еще добавить примеров:

auto ptr = std::make_unique<int>(42);
std::cout << *ptr << std::endl;

Выражение *ptr здесь вычисляется в ссылку (и конечно же, у этой ссылки есть тип — int&). А вот никакого имени здесь нет — ни первого, ни второго.

Имя есть у переменной. Но переменная — это не единственная форма существования ссылок.
--
Отредактировано 10.07.2024 14:29 rg45 . Предыдущая версия . Еще …
Отредактировано 10.07.2024 13:42 rg45 . Предыдущая версия .
Отредактировано 10.07.2024 13:35 rg45 . Предыдущая версия .
Отредактировано 10.07.2024 13:32 rg45 . Предыдущая версия .
Re[3]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 10.07.24 15:42
Оценка: +1
Здравствуйте, rg45, Вы писали:

BFE>>Ссылка — это второе имя переменной (в отличии от ссылочного типа). В map не кладут имена переменных. В map кладут значения переменных.

R>Ну вот зачем ты это пишешь? Чтобы еще больше запутать его? А когда ссылка является результатом выражения, например std::max(42, 43) где там какое имя?
А где тут ссылка?
И каждый день — без права на ошибку...
Re[6]: Вопрос про ссылки - что бы сломалось, если...
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.24 16:42
Оценка: +1
Здравствуйте, B0FEE664, Вы писали:

BFE>Не, там есть тип возвращаемого значения, а ссылки — нет.


Э-э-э... Функция определена так:

template < class T > const T& max ( const T& a, const T& b );


Она возвращает константную ссылку. Где именно, по-Вашему, эта ссылка исчезает?
Re[7]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 10.07.24 17:10
Оценка: +1
Здравствуйте, rg45_from_ban, Вы писали:

BFE>>Не, там есть тип возвращаемого значения, а ссылки — нет.

__>И где ж ты такое прочитал, интересно
Что прочитал? Как можно прочитать то, чего нет?

__>Зачем вот что-то выдумывать, когда можно просто открыть стандарт и почитать:

__>https://timsong-cpp.github.io/cppwp/n4861/dcl.fct#11

__>

__>Functions shall not have a return type of type array or function, although they may have a return type of type pointer or reference to such things. There shall be no arrays of functions, although there can be arrays of pointers to functions.


Тут речь про возвращаемый тип, а не ссылку.
Сказать, что функция возвращает ссылку, это всё равно, что сказать, что функция возвращает имя.
И каждый день — без права на ошибку...
Re[3]: А вы с какой целью интересуетесь?
От: Carc Россия http://www.amlpages.com/home.php
Дата: 10.07.24 18:07
Оценка: :)
Здравствуйте, Doom100500, Вы писали:

D>...бы было бы если бы относительно C++ осмысленны так же, как рассуждения о том, что было бы если бы Shmj перестал засирать RSDN своей тупизной.


D>А что так можно было что-ли?

Нет, нельзя. Тогда это было бы так называемое (ц) другое (ц)
Aml Pages Home
Отредактировано 10.07.2024 18:09 Carc . Предыдущая версия .
Re[8]: Вопрос про ссылки - что бы сломалось, если...
От: reversecode google
Дата: 11.07.24 13:32
Оценка: -1
есть некоторое общее правило С++
если передается указатель
ему можно сделать delete
можно ли в том find сделать delete тому указателю что вернется?
вряд ли
рискованно
опасно
уб
уц
уд
уе
Re[9]: Вопрос про ссылки - что бы сломалось, если...
От: so5team https://stiffstream.com
Дата: 11.07.24 13:43
Оценка: +1
Здравствуйте, reversecode, Вы писали:

R>есть некоторое общее правило С++

R>если передается указатель
R>ему можно сделать delete
R>можно ли в том find сделать delete тому указателю что вернется?

Есть общее правило: писать с выделением предложений знаками препинания, начиная каждое новое предложение с заглавной буквы. Но некоторым альтернативно одаренным на это пох. А на мнение альтернативно одаренных откровенно начхать.

Особенно если эти альтернативно одаренные ведут себя типа как суперпрофи, но при этом не в курсе про правило "никаких голых владеющих указателей"
Re[3]: Вопрос про ссылки - что бы сломалось, если...
От: graniar  
Дата: 13.07.24 19:27
Оценка: :)
Здравствуйте, Shmj, Вы писали:

S>А как же передача в функцию по ссылке? Это и удобно и память лишний раз не копируется.


Разве что при развертывании инлайн-функции. Но там и указатели прекрасно прооптимизируются. А в нормальном вызове аргумент-ссылка и так передается через стэк как указатель, как же иначе то?
Вобщем не дают ссылки никакого магического преимущества.
Re[2]: Вопрос про ссылки - что бы сломалось, если...
От: Shmj Ниоткуда  
Дата: 10.07.24 05:31
Оценка:
Здравствуйте, Doom100500, Вы писали:

D>Мешает то, что если ссылка начнёт менять то, на что она ссылается, то она сможет принимать и неинициализированное значение, что сразы же убирает уверенность в её валидности. А значит с ссылками придётся работаь как с указателями — то есть постоянно проверять на null, плюс всякие бесконтрольные UB. Это сразу убивает весь смысл ссылок в C++


Но если разрешить только между ссылками. Т.е. просто адрес напрямую установить не можете, а от одной ссылки переназначить на другую — можно. А ведь другая то тоже 100% на что-то ссылается же.
Re[3]: Вопрос про ссылки - что бы сломалось, если...
От: Doom100500 Израиль  
Дата: 10.07.24 05:38
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Doom100500, Вы писали:


D>>Мешает то, что если ссылка начнёт менять то, на что она ссылается, то она сможет принимать и неинициализированное значение, что сразы же убирает уверенность в её валидности. А значит с ссылками придётся работаь как с указателями — то есть постоянно проверять на null, плюс всякие бесконтрольные UB. Это сразу убивает весь смысл ссылок в C++


S>Но если разрешить только между ссылками. Т.е. просто адрес напрямую установить не можете, а от одной ссылки переназначить на другую — можно. А ведь другая то тоже 100% на что-то ссылается же.


Страуструп подразумевал, что ссылка — это псевдоним. Псевдоним принадлежит только кому-то одному. В свази с этим уже написано тонны кода типа ref1 = ref2. Вот он и сломается.
Почему Страуструп так решил — пусть теоретики расскажут.
Спасибо за внимание
Re[4]: Вопрос про ссылки - что бы сломалось, если...
От: vsb Казахстан  
Дата: 10.07.24 05:52
Оценка:
Здравствуйте, Doom100500, Вы писали:

D>>>Мешает то, что если ссылка начнёт менять то, на что она ссылается, то она сможет принимать и неинициализированное значение, что сразы же убирает уверенность в её валидности. А значит с ссылками придётся работаь как с указателями — то есть постоянно проверять на null, плюс всякие бесконтрольные UB. Это сразу убивает весь смысл ссылок в C++


S>>Но если разрешить только между ссылками. Т.е. просто адрес напрямую установить не можете, а от одной ссылки переназначить на другую — можно. А ведь другая то тоже 100% на что-то ссылается же.


D>Страуструп подразумевал, что ссылка — это псевдоним. Псевдоним принадлежит только кому-то одному. В свази с этим уже написано тонны кода типа ref1 = ref2. Вот он и сломается.

D>Почему Страуструп так решил — пусть теоретики расскажут.

Ну очевидно, что для изменения адреса ссылки использовался бы синтаксис вроде &a = &b.
Re[2]: А вы с какой целью интересуетесь?
От: Doom100500 Израиль  
Дата: 10.07.24 06:03
Оценка:
Здравствуйте, so5team, Вы писали:

S>Или просто не знаете про существование std::reference_wrapper?


А что так можно было что-ли?
Спасибо за внимание
Re: Вопрос про ссылки - что бы сломалось, если...
От: T4r4sB Россия  
Дата: 10.07.24 06:08
Оценка:
Здравствуйте, Shmj, Вы писали:

S>А вот гипотетически можно было бы разрешить присваивать ссылкам адреса других ссылок? Что бы при этом принципиально сломалось? Ведь все-равно вторая ссылка обязательно на что-то ссылается то.


А синтаксис какой был бы?
Такой же?
Прикинь у тебя два вектора и ты пишешь a[i]=b[i]
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re: Вопрос про ссылки - что бы сломалось, если...
От: rg45 СССР  
Дата: 10.07.24 07:23
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Вопрос такой. Ссылки нельзя переназначить на другой адрес, что мешает использовать их в map и пр.

S>А вот гипотетически можно было бы разрешить присваивать ссылкам адреса других ссылок? Что бы при этом принципиально сломалось? Ведь все-равно вторая ссылка обязательно на что-то ссылается то.

Имхо, ты из раза в раз совершаешь одну и ту же ошибку: вместо того, чтобы прийти, рассказать задачу и попросить помощи в решении, ты пускаешься в глубокие теоретические изыскания и какое-то пустое философствование. В маниловщину, проще говоря. Реакцию участников форума ты видишь сам.
--
Отредактировано 10.07.2024 7:41 rg45 . Предыдущая версия . Еще …
Отредактировано 10.07.2024 7:25 rg45 . Предыдущая версия .
Отредактировано 10.07.2024 7:23 rg45 . Предыдущая версия .
Re: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 10.07.24 12:32
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Вопрос такой. Ссылки нельзя переназначить на другой адрес, что мешает использовать их в map и пр.

Ссылка — это второе имя переменной (в отличии от ссылочного типа). В map не кладут имена переменных. В map кладут значения переменных.

S>
S>int a = 10;
S>int b = 20;
S>int& ref1 = a;
S>int& ref2 = b;

S>// как то сделать, чтобы ref1 и ref2 ссылались на одну область памяти
//Допустим...

S>ref1 = ref2 // присваивает значение b в a, а не присваиваем ref1 адрес ref2, как хотелось бы. А что мешает?
//ref1 и ref2 - это вторые имена переменных a и b соответственно.
//Поэтому вопрос равносилен следующему:
a = b // присваивает значение b в a, а не присваивает a адрес b, как хотелось бы. А что мешает?

S>


S>А вот гипотетически можно было бы разрешить присваивать ссылкам адреса других ссылок? Что бы при этом принципиально сломалось? Ведь все-равно вторая ссылка обязательно на что-то ссылается то.

Да, теоретически можно было бы вместо копирования значений перепривязывать имена переменных к другим объектам. Более того, насколько я знаю, в теоретическую часть всех ВУЗовских курсов программирования входит рассказ такой возможности. Но это не C++.
И каждый день — без права на ошибку...
Re[3]: Вопрос про ссылки - что бы сломалось, если...
От: andrey.desman  
Дата: 10.07.24 13:22
Оценка:
Здравствуйте, rg45, Вы писали:

BFE>>Ссылка — это второе имя переменной (в отличии от ссылочного типа). В map не кладут имена переменных. В map кладут значения переменных.

R>Ну вот зачем ты это пишешь? Чтобы еще больше запутать его? А когда ссылка является результатом выражения, например std::max(42, 43) где там какое имя?

Так это тип, а не ссылка.
Re[5]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 10.07.24 15:40
Оценка:
Здравствуйте, rg45, Вы писали:

BFE>>>>Ссылка — это второе имя переменной (в отличии от ссылочного типа). В map не кладут имена переменных. В map кладут значения переменных.

R>>>Ну вот зачем ты это пишешь? Чтобы еще больше запутать его? А когда ссылка является результатом выражения, например std::max(42, 43) где там какое имя?
AD>>Так это тип, а не ссылка.
R>Конечно же, у результата есть тип. Но есть же и сам результат — та самая ссылка. Есть временный объект, к которому привязана ссылка. И это можно даже визуализировать:
R>
R>std::cout << std::max(42, 43) << std::endl;
R>

Осталось доказать, что где-то здесь есть ссылка.
Ссылка — это даже не объект. Ссылка — это такая абстракция, как имя переменной.

R>Можно еще добавить примеров:

R>
R>auto ptr = std::make_unique<int>(42);
R>std::cout << *ptr << std::endl;
R>

R>Выражение *ptr здесь вычисляется в ссылку (и конечно же, у этой ссылки есть тип — int&). А вот никакого имени здесь нет — ни первого, ни второго.
Совершенно не видно, что здесь где-то есть ссылка.

R>Имя есть у переменной. Но переменная — это не единственная форма существования ссылок.

В каком смысле "ссылки существуют"?
И каждый день — без права на ошибку...
Re[4]: Вопрос про ссылки - что бы сломалось, если...
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.24 16:23
Оценка:
Здравствуйте, B0FEE664, Вы писали:

R>>std::max(42, 43)


BFE>А где тут ссылка?


Дык, в определении же.
Re[6]: Вопрос про ссылки - что бы сломалось, если...
От: rg45_from_ban  
Дата: 10.07.24 16:42
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Не, там есть тип возвращаемого значения, а ссылки — нет.


И где ж ты такое прочитал, интересно

Зачем вот что-то выдумывать, когда можно просто открыть стандарт и почитать:

https://timsong-cpp.github.io/cppwp/dcl.fct#14

The return type shall be a non-array object type, a reference type, or cv void.


Эта достаточно "свежая" формулировка, появилась она, начиная с N4885 — это все ещё С++20.
Отредактировано 10.07.2024 17:37 rg45_from_ban . Предыдущая версия . Еще …
Отредактировано 10.07.2024 16:59 rg45_from_ban . Предыдущая версия .
Re[8]: Вопрос про ссылки - что бы сломалось, если...
От: rg45_from_ban  
Дата: 10.07.24 17:15
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Тут речь про возвращаемый тип, а не ссылку.

BFE>Сказать, что функция возвращает ссылку, это всё равно, что сказать, что функция возвращает имя.

Перечитай еще раз мое сообщение
Автор: rg45_from_ban
Дата: 10.07 19:42
— я там обновил цитату из более новой версии стандарта. Там русским по белому перечисленно, чем может быть return type и один из вариантов — ссылка.
Отредактировано 10.07.2024 17:30 rg45_from_ban . Предыдущая версия . Еще …
Отредактировано 10.07.2024 17:25 rg45_from_ban . Предыдущая версия .
Re[9]: Вопрос про ссылки - что бы сломалось, если...
От: rg45_from_ban  
Дата: 10.07.24 17:23
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>>Тут речь про возвращаемый тип, а не ссылку.

BFE>>Сказать, что функция возвращает ссылку, это всё равно, что сказать, что функция возвращает имя.

__>Перечитай еще раз мое сообщение
Автор: rg45_from_ban
Дата: 10.07 19:42
— я там обновил цитату из более нового стандарта. Там русским по белом перечисленно, чем может быть return type и один из вариантов — ссылка.


Ну и чтоб два раза не вставать:

https://timsong-cpp.github.io/cppwp/expr.call#4

If the postfix-expression names a destructor or pseudo-destructor, the type of the function call expression is void; otherwise, the type of the function call expression is the return type of the statically chosen function (i.e., ignoring the virtual keyword), even if the type of the function actually called is different...


То есть, типом function call expression является return type функции.
Re[8]: Вопрос про ссылки - что бы сломалось, если...
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.24 17:23
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Сказать, что функция возвращает ссылку, это всё равно, что сказать, что функция возвращает имя.


Э-э-э... А как еще можно более коротко и менее формально сказать "функция возвращает значение ссылочного типа"? В английском термины "reference type" и "reference" в отношении значений тоже эквивалентны.
Re[7]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 10.07.24 17:39
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

BFE>>Не, там есть тип возвращаемого значения, а ссылки — нет.

ЕМ>Э-э-э... Функция определена так:
ЕМ>
ЕМ>template < class T > const T& max ( const T& a, const T& b );
ЕМ>

ЕМ>Она возвращает константную ссылку.
Так говорят, но строго говоря это не про ссылку, а про тип: возвращаемый тип — это константная ссылка.

ЕМ>Где именно, по-Вашему, эта ссылка исчезает?

Вопрос не в том, где она исчезает, а в том, где появляется. Ссылка — это не объект, она даже памяти не занимает, если имплементация позволяет. А уж в вызовах для int'ов вообще все ссылки отбрасываются и работают прямо со значениями, например в выражении: int n = std::max(42, 43); нет разницы ссылки тут или int'ы, так как наблюдаемый результат будет тот же. Если же написать const int& r = std::max(42, 43);, то — да: тут появляется ссылка, так как появилось имя.
И каждый день — без права на ошибку...
Re[8]: Вопрос про ссылки - что бы сломалось, если...
От: rg45_from_ban  
Дата: 10.07.24 17:39
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Сказать, что функция возвращает ссылку, это всё равно, что сказать, что функция возвращает имя.


С хрена ли?
Re[9]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 10.07.24 17:46
Оценка:
Здравствуйте, rg45_from_ban, Вы писали:

BFE>>Тут речь про возвращаемый тип, а не ссылку.

BFE>>Сказать, что функция возвращает ссылку, это всё равно, что сказать, что функция возвращает имя.

__>Перечитай еще раз мое сообщение
Автор: rg45_from_ban
Дата: 10.07 19:42
— я там обновил цитату из более новой версии стандарта. Там русским по белому перечисленно, чем может быть return type и один из вариантов — ссылка.

Русским? Ссылка?
Или, таки, английский и reference type?
И каждый день — без права на ошибку...
Re[10]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 10.07.24 17:48
Оценка:
Здравствуйте, rg45_from_ban, Вы писали:

__>То есть, типом function call expression является return type функции.


Я различаю ссылку и ссылочный тип. Для меня это два разных понятия.
И каждый день — без права на ошибку...
Re[10]: Вопрос про ссылки - что бы сломалось, если...
От: rg45_from_ban  
Дата: 10.07.24 17:51
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Русским? Ссылка?

BFE>Или, таки, английский и reference type?

Ну, reference type, конечно. И? Что это меняет?
Re[8]: Вопрос про ссылки - что бы сломалось, если...
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.24 18:00
Оценка:
Здравствуйте, B0FEE664, Вы писали:

ЕМ>>Она возвращает константную ссылку.


BFE>Так говорят, но строго говоря это не про ссылку, а про тип: возвращаемый тип — это константная ссылка.


Функция не может "возвращать тип". То, что реально (кроме фиктивного void) возвращает любая функция — это всегда значение (число определенной разрядности). В C/C++ этому значению приписывается еще и тип (как характеристика значения, способ его истолкования). То есть, значение первично (без него никак), тип вторичен (в ряде случаев его можно игнорировать).

Правильный перевод английского "return type" — "тип возвращаемого значения". "Возвращаемый тип" — это просторечие, жаргонизм, который допустимо использовать лишь тогда, когда всем участникам понятен точный смысл.

BFE>Ссылка — это не объект, она даже памяти не занимает, если имплементация позволяет.


Если ссылка существует физически (в виде адреса) — она всегда занимает хоть какую-то память (как физическое устройство хранения), в том числе и регистр.

BFE>А уж в вызовах для int'ов вообще все ссылки отбрасываются и работают прямо со значениями, например в выражении: int n = std::max(42, 43); нет разницы ссылки тут или int'ы, так как наблюдаемый результат будет тот же.


При чем здесь int? С точки зрения правил языка, так будет для объекта любого типа. И даже в исполняемом коде, если компилятор точно знает, с каким объектом связана ссылка, он может обойтись без косвенной адресации, работая с объектом напрямую (хоть в регистре). А если ссылка входит в константное выражение, вычислимое на этапе компиляции, то она и вовсе не попадет в исполняемый код в виде "указующего объекта". Но при этом в выражении, содержащем ссылку (явно или неявно), она будет вести себя по правилам, установленным языком для ссылок.

BFE>Если же написать const int& r = std::max(42, 43);, то — да: тут появляется ссылка, так как появилось имя.


Тут появляется не ссылка, как таковая, а именованная ссылка.
Re[11]: Вопрос про ссылки - что бы сломалось, если...
От: rg45_from_ban  
Дата: 10.07.24 18:10
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Я различаю ссылку и ссылочный тип. Для меня это два разных понятия.


Да кто ж с этим спорит. Конечно, это два разных понятия — точно так же, как объект и тип объекта. Только что это меняет? Ты хочешь сказать, что вот в таком случае:

auto p = std::unique_ptr<int>(42);
*p = 43;


выражение *p не вычисляется в ссылку?
Отредактировано 10.07.2024 18:11 rg45_from_ban . Предыдущая версия .
Re[9]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 10.07.24 18:26
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>>Она возвращает константную ссылку.

BFE>>Так говорят, но строго говоря это не про ссылку, а про тип: возвращаемый тип — это константная ссылка.
ЕМ>Функция не может "возвращать тип".
Тип возвращать не может, а возвращаемый тип у функции есть.

ЕМ>То, что реально (кроме фиктивного void) возвращает любая функция — это всегда значение (число определенной разрядности).

В том то и дело, что это не так. Нет никаких "реально", так как "реально" не относится к виртуальной машине, которую описывает стандарт. К реальному относятся только побочные эффекты и текст кода, а всё остальное абстрактно. Вызов функции может быть вообще выкинут, если результат не используется. О чём таком реальном вы пишите?

ЕМ>В C/C++ этому значению приписывается еще и тип (как характеристика значения, способ его истолкования). То есть, значение первично (без него никак), тип вторичен (в ряде случаев его можно игнорировать).

Значение тоже вторично, так может быть вычислено использовано и выкинуто ещё на этапе компиляции.

ЕМ>Правильный перевод английского "return type" — "тип возвращаемого значения". "Возвращаемый тип" — это просторечие, жаргонизм, который допустимо использовать лишь тогда, когда всем участникам понятен точный смысл.

Нет способа убедиться, что всем участникам понятен точный смысл. Более того, нет способа убедится, что мне (или вам) понятен точный смысл.

BFE>>Ссылка — это не объект, она даже памяти не занимает, если имплементация позволяет.

ЕМ>Если ссылка существует физически (в виде адреса) — она всегда занимает хоть какую-то память (как физическое устройство хранения), в том числе и регистр.
Или не существует и не занимает.
Сейчас, к сожалению не пишут самоизменяющийся исполняемый код (из-за борьбы с вирусами), но стандарт такого не запрещает.

BFE>>А уж в вызовах для int'ов вообще все ссылки отбрасываются и работают прямо со значениями, например в выражении: int n = std::max(42, 43); нет разницы ссылки тут или int'ы, так как наблюдаемый результат будет тот же.


ЕМ>При чем здесь int? С точки зрения правил языка, так будет для объекта любого типа.

Я тоже так думал, но нет. Для базовых типов в стандарте часто прописывают исключения.

ЕМ> И даже в исполняемом коде, если компилятор точно знает, с каким объектом связана ссылка, он может обойтись без косвенной адресации, работая с объектом напрямую (хоть в регистре). А если ссылка входит в константное выражение, вычислимое на этапе компиляции, то она и вовсе не попадет в исполняемый код в виде "указующего объекта". Но при этом в выражении, содержащем ссылку (явно или неявно), она будет вести себя по правилам, установленным языком для ссылок.

Если всё так, то против чего, вы, собственно, возражаете?

BFE>>Если же написать const int& r = std::max(42, 43);, то — да: тут появляется ссылка, так как появилось имя.

ЕМ>Тут появляется не ссылка, как таковая, а именованная ссылка.
Что такое "не именнованая ссылка"?
И каждый день — без права на ошибку...
Re[12]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 10.07.24 18:40
Оценка:
Здравствуйте, rg45_from_ban, Вы писали:

BFE>>Я различаю ссылку и ссылочный тип. Для меня это два разных понятия.

__>Да кто ж с этим спорит. Конечно, это два разных понятия — точно так же, как объект и тип объекта. Только что это меняет? Ты хочешь сказать, что вот в таком случае:
__>
__>auto p = std::unique_ptr<int>(42);
__>*p = 43;
__>

__>выражение *p не вычисляется в ссылку?
Вы опять про выражения?
А выражение n + 1; вычисляется в ссылку?:
int n = 0;
n + 1;
И каждый день — без права на ошибку...
Re[5]: Вопрос про ссылки - что бы сломалось, если...
От: andrey.desman  
Дата: 10.07.24 19:27
Оценка:
Здравствуйте, rg45, Вы писали:

AD>>Так это тип, а не ссылка.

R>Конечно же, у результата есть тип. Но есть же и сам результат — та самая ссылка. Есть временный объект, к которому привязана ссылка. И это можно даже визуализировать:

Если полезть в стандарт, то концов там не найдешь. Вокруг ссылок и ссылочных типов много разного словоблудия с переподвыподвертом.

У нас все же принято под ссылкой понимать именно имя, а все остальное, оно про тип: передачу по ссылке, возврат по ссылке и т.д.
Re[10]: Вопрос про ссылки - что бы сломалось, если...
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.24 20:49
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Тип возвращать не может, а возвращаемый тип у функции есть.


Это не "возвращаемый тип", а "тип возвращаемого значения" (value type).

BFE>Значение тоже вторично, так может быть вычислено использовано и выкинуто ещё на этапе компиляции.


В контексте результата функции оно первично, ибо существует всегда, если его тип не void, и функция обязана его вернуть.

ЕМ>>При чем здесь int? С точки зрения правил языка, так будет для объекта любого типа.


BFE>Я тоже так думал, но нет. Для базовых типов в стандарте часто прописывают исключения.


Что именно в стандарте прописано для фундаментальных типов? Если Вы про интерпретацию типа значения выражения, то в этом контексте ссылка на любой тип сводится к самому типу, чисто для упрощения анализа. Но формально-то T f () и T const & f () — разные функции. Тип результата вызова первой — T, второй — T const &. А уже при оптимизации выражения, в которое входит вызов (именно самого выражения, а не порождаемого им кода), компилятор имеет право забыть, что во втором случае возвращена именно ссылка, а не само значение, если они их фактический смысл одинаков.

BFE>Если всё так, то против чего, вы, собственно, возражаете?


Против выражения "возвращаемый тип".

А ссылка в обсуждаемом выражении таки есть — ее возвращает std::max в операторе return. Возвращаемое ею значение имеет ссылочный тип.

BFE>Что такое "не именнованая ссылка"?


Значение ссылочного типа (T &), существующее отдельно от именованного объекта.
Re[13]: Вопрос про ссылки - что бы сломалось, если...
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.24 20:52
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>А выражение n + 1; вычисляется в ссылку?:

BFE>
BFE>int n = 0;
BFE>n + 1;
BFE>


Нет — здесь нигде не возникает значений ссылочного типа (int &) — хоть в явном виде, хоть в результате преобразования.
Re[6]: Вопрос про ссылки - что бы сломалось, если...
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.24 20:57
Оценка:
Здравствуйте, andrey.desman, Вы писали:

AD>У нас все же принято под ссылкой понимать именно имя, а все остальное, оно про тип: передачу по ссылке, возврат по ссылке и т.д.


Это неправильно, так как путаются понятия ссылочного типа и ссылки, как "указующего", "косвенного" объекта. В передаче и возврате по ссылке участвует именно ссылка-объект, а не просто ссылочный тип или "синоним".
Re[14]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 11.07.24 09:52
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

BFE>>А выражение n + 1; вычисляется в ссылку?:

BFE>>
BFE>>int n = 0;
BFE>>n + 1;
BFE>>


ЕМ>Нет — здесь нигде не возникает значений ссылочного типа (int &) — хоть в явном виде, хоть в результате преобразования.

Что насчёт 'int&&'?
И каждый день — без права на ошибку...
Re[2]: Вопрос про ссылки - что бы сломалось, если...
От: sergii.p  
Дата: 11.07.24 09:58
Оценка:
Здравствуйте, Doom100500, Вы писали:

D>Мешает то, что если ссылка начнёт менять то, на что она ссылается, то она сможет принимать и неинициализированное значение, что сразы же убирает уверенность в её валидности.


первое из второго вроде как не следует. Ну закройте "конструктор по умолчанию" для ссылок вот и пропадут неинициализированные значения. Тот же reference_wrapper гарантирует, что выдаст ненулевой адрес.
Тот же код на Rust гарантирует валидность и компилируется

let i = 0;
let k = 1;
let mut ref_i = &i;
ref_i = &k;


Получается, проблема таки в синтаксисе — нет механизма переприсвоить ссылку. И это таки баг языка (имхо конечно).

p.s. Кстати, заметьте, насколько в Rust тривиальное определение ссылки. Это просто адрес. А в С++ уже на 10 страниц развели спор об определении.
Re[11]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 11.07.24 10:00
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

BFE>>Тип возвращать не может, а возвращаемый тип у функции есть.

ЕМ>Это не "возвращаемый тип", а "тип возвращаемого значения" (value type).
Хорошо, пусть будет тип возвращаемого значения.

BFE>>Значение тоже вторично, так может быть вычислено использовано и выкинуто ещё на этапе компиляции.

ЕМ>В контексте результата функции оно первично, ибо существует всегда, если его тип не void, и функция обязана его вернуть.
В каком смысле "существует"?

ЕМ>>>При чем здесь int? С точки зрения правил языка, так будет для объекта любого типа.

BFE>>Я тоже так думал, но нет. Для базовых типов в стандарте часто прописывают исключения.
ЕМ>Что именно в стандарте прописано для фундаментальных типов? Если Вы про интерпретацию типа значения выражения, то в этом контексте ссылка на любой тип сводится к самому типу, чисто для упрощения анализа.
Да, я именно про это. ссылка не на любой тип сводится к самому типу, так как для объектов могут быть написаны перегрузки функций и операций для ссылок.

ЕМ> Но формально-то T f () и T const & f () — разные функции. Тип результата вызова первой — T, второй — T const &. А уже при оптимизации выражения, в которое входит вызов (именно самого выражения, а не порождаемого им кода), компилятор имеет право забыть, что во втором случае возвращена именно ссылка, а не само значение, если они их фактический смысл одинаков.

Согласен.

BFE>>Если всё так, то против чего, вы, собственно, возражаете?

ЕМ>Против выражения "возвращаемый тип".
Хорошо, пусть будет тип возвращаемого значения.

ЕМ>А ссылка в обсуждаемом выражении таки есть — ее возвращает std::max в операторе return. Возвращаемое ею значение имеет ссылочный тип.

BFE>>Что такое "не именнованая ссылка"?
ЕМ>Значение ссылочного типа (T &), существующее отдельно от именованного объекта.
Вот вы пишите про "выражение". Какой смысл вы вкладываете с слово "существует" в таком контексте?
И каждый день — без права на ошибку...
Re[9]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 11.07.24 10:07
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

BFE>>Сказать, что функция возвращает ссылку, это всё равно, что сказать, что функция возвращает имя.

ЕМ>Э-э-э... А как еще можно более коротко и менее формально сказать "функция возвращает значение ссылочного типа"? В английском термины "reference type" и "reference" в отношении значений тоже эквивалентны.

Неформально можно сказать многое, в том числе, что функция возвращает ссылку, но считать, что при этом на самом деле возвращается некий объект-ссылка — ошибка.
И каждый день — без права на ошибку...
Re[3]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 11.07.24 10:24
Оценка:
Здравствуйте, sergii.p, Вы писали:

SP>Получается, проблема таки в синтаксисе — нет механизма переприсвоить ссылку. И это таки баг языка (имхо конечно).

Это не ошибка языка, а так и задумано.

SP>p.s. Кстати, заметьте, насколько в Rust тривиальное определение ссылки. Это просто адрес. А в С++ уже на 10 страниц развели спор об определении.

Вот в Json тоже писали краткие определения, а на практике оказалось, что в результате очень много ошибок о которых авторы не подумали.

отсюда
let a = "объект с данными в куче".to_string();
// объект передан переменной b
// переменная a становится неинициализированной
let b = a;
// ошибка!
let c = a;

В чём смысл такого? Или все такие ошибки отлавливаются на этапе компиляции?
И каждый день — без права на ошибку...
Re[4]: Вопрос про ссылки - что бы сломалось, если...
От: sergii.p  
Дата: 11.07.24 11:12
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, sergii.p, Вы писали:


SP>>Получается, проблема таки в синтаксисе — нет механизма переприсвоить ссылку. И это таки баг языка (имхо конечно).

BFE>Это не ошибка языка, а так и задумано.

понятно, что так и задумано, но мне кажется в долгосрочной перспективе ошиблись.
Сейчас ведь даже нельзя написать что-то типа такого:

template<typename T, typename Pred>
std::optional<T&> find(std::vector<T> const& vec, Pred&& pred);


хотя 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]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 11.07.24 12:12
Оценка:
Здравствуйте, sergii.p, Вы писали:

SP>>>Получается, проблема таки в синтаксисе — нет механизма переприсвоить ссылку. И это таки баг языка (имхо конечно).

BFE>>Это не ошибка языка, а так и задумано.
SP>понятно, что так и задумано, но мне кажется в долгосрочной перспективе ошиблись.
Не, то, чего хочет Shmj не согласуется с принципом бедняка: "Не платить за то, что не используется". Если попробовать полностью описать как должно работать переназначение ссылок, то первым делом сама ссылка станет объектом и будет занимать какую-то память, потом появится подсчёт ссылок и в конечном итоге получится конструкция функционально неотличимая от std::shared_ptr<NotNullPtr<T>>

SP>Сейчас ведь даже нельзя написать что-то типа такого:

SP>
SP>template<typename T, typename Pred>
SP>std::optional<T&> find(std::vector<T> const& vec, Pred&& pred);
SP>

SP>хотя optional для этого по сути и задумывался.
template<typename T, typename Pred>
std::optional<std::reference_wrapper<T>> find(std::vector<T> const& vec, Pred&& pred);

Не подойдёт?

SP>ну а в С++ пример обратный. Перемудрили.

С++ был придумал, развивался и развивается по эволюционной модели развития проекта, что, конечно, несёт с собой отрицательные аспекты.
И каждый день — без права на ошибку...
Re[5]: Вопрос про ссылки - что бы сломалось, если...
От: so5team https://stiffstream.com
Дата: 11.07.24 12:16
Оценка:
Здравствуйте, sergii.p, Вы писали:

SP>Сейчас ведь даже нельзя написать что-то типа такого:


SP>
SP>template<typename T, typename Pred>
SP>std::optional<T&> find(std::vector<T> const& vec, Pred&& pred);
SP>


SP>хотя optional для этого по сути и задумывался.


Так ведь здесь вот просто напрашивается:
template<typename T, typename Pred>
T* find(std::vector<T> const & vec, Pred&& pred);


Не зря же optional мимикрирует под указатель.
Re[5]: Вопрос про ссылки - что бы сломалось, если...
От: σ  
Дата: 11.07.24 12:39
Оценка:
SP>>>Получается, проблема таки в синтаксисе — нет механизма переприсвоить ссылку. И это таки баг языка (имхо конечно).
BFE>>Это не ошибка языка, а так и задумано.

SP>понятно, что так и задумано, но мне кажется в долгосрочной перспективе ошиблись.

SP>Сейчас ведь даже нельзя написать что-то типа такого:

SP>
template<typename T, typename Pred>
std::optional<T&> find(std::vector<T> const& vec, Pred&& pred);


Если ты капитально задумаешься о том (и осознаешь) что есть ссылка, то станет понятно, что запись std::optional<T&> не имеет смысла
Re[6]: Вопрос про ссылки - что бы сломалось, если...
От: sergii.p  
Дата: 11.07.24 13:04
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>
BFE>template<typename T, typename Pred>
BFE>std::optional<std::reference_wrapper<T>> find(std::vector<T> const& vec, Pred&& pred);
BFE>

BFE>Не подойдёт?

я уже ел этот кактус, повторно не предлагать

using Map = std::vector<std::string_view>;
using Opt = std::optional<std::reference_wrapper<Map::value_type>>;
 
Opt find(Map& m, std::string_view s)
{
    auto it = std::find(m.begin(), m.end(), s);
    return it == m.end() ? Opt{} : Opt{*it};
}

int main(int argc, char* argv[]) {
    Map vec = {"123", "234"};

    auto tmp = std::string_view{"123"};
    std::cout << find(vec, tmp).value_or(std::ref(tmp)).get();
}


Оно как бы компилируется, но такое количество костылей на единицу строчки неприемлемо.
Re[6]: Вопрос про ссылки - что бы сломалось, если...
От: sergii.p  
Дата: 11.07.24 13:07
Оценка:
Здравствуйте, so5team, Вы писали:

S>Так ведь здесь вот просто напрашивается:

S>
S>template<typename T, typename Pred>
S>T* find(std::vector<T> const & vec, Pred&& pred);
S>


да, приходится так писать. Но это же "теоретически" неверно. Никто выходящий указатель на nullptr проверять не будет, компилятор за этим не проследит. Короче нафига тогда std::optional?
Re[7]: Вопрос про ссылки - что бы сломалось, если...
От: so5team https://stiffstream.com
Дата: 11.07.24 13:29
Оценка:
Здравствуйте, 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, то получается очень удобная штука.
Не нужно писать самому что-то вроде:
alignas(T) std::byte storage[sizeof(T)];
T * obj = new(storage) T{...};
...
obj->~T();


И если смотреть на std::optional так, то становится понятно, почему нет смысла в optional помещать ссылку. По крайней мере с моей колокольни удобно смотреть так.
Re[8]: Вопрос про ссылки - что бы сломалось, если...
От: sergii.p  
Дата: 11.07.24 14:03
Оценка:
Здравствуйте, so5team, Вы писали:

S>Но ведь так же можно сказать, что и optional на пустоту проверять никто не будет.


ага. И эти вопросы я бы хотел задать тем, кто принимал optional в таком виде в стандарт

S>Если смотреть на std::optional как на объект, который предоставляет место для хранения T, при этом еще и следит за временем жизни T, то получается очень удобная штука.


это как бы побочный эффект optional. Не думаю, что создавался для этого. Для меня классическое применение в методах типа find. Во многих языках (Haskell, Rust, Zig) так, но почему-то не в С++.
Re[9]: Вопрос про ссылки - что бы сломалось, если...
От: so5team https://stiffstream.com
Дата: 11.07.24 15:30
Оценка:
Здравствуйте, 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 с ссылкой внутри возвращает.
Сделайте свою функцию как:

template<typename T, typename Pred>
optional<std::vector<T>::size_type> find(std::vector<T> const & vec, Pred&& pred);


и будете иметь тоже, что и в Rust-е.

SP>Во многих языках (Haskell, Rust, Zig) так, но почему-то не в С++.


Опять же, если сравнивать C++ с другими языками, в которых, во-первых, есть reference-типы и GC, и, во-вторых, есть алгебраические типы и паттерн-матчинг, то там можно делать совсем не так, как в C++ (я про Haskell и Scala). Но в C++ нет ни того, ни другого, приходится выкручиваться.
Re[7]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 11.07.24 18:16
Оценка:
Здравствуйте, sergii.p, Вы писали:

BFE>>
BFE>>template<typename T, typename Pred>
BFE>>std::optional<std::reference_wrapper<T>> find(std::vector<T> const& vec, Pred&& pred);
BFE>>

BFE>>Не подойдёт?

SP>я уже ел этот кактус, повторно не предлагать


  Скрытый текст
SP>
SP>using Map = std::vector<std::string_view>;
SP>using Opt = std::optional<std::reference_wrapper<Map::value_type>>;
 
SP>Opt find(Map& m, std::string_view s)
SP>{
SP>    auto it = std::find(m.begin(), m.end(), s);
SP>    return it == m.end() ? Opt{} : Opt{*it};
SP>}

SP>int main(int argc, char* argv[]) {
SP>    Map vec = {"123", "234"};

SP>    auto tmp = std::string_view{"123"};
SP>    std::cout << find(vec, tmp).value_or(std::ref(tmp)).get();
SP>}
SP>


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]: Вопрос про ссылки - что бы сломалось, если...
От: sergii.p  
Дата: 12.07.24 09:45
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Честно говоря я не понял, что вам не нравится и чего хочется.


auto tmp = std::string_view{"123"};
std::cout << find(vec, tmp).value_or(std::ref(tmp)).get();


    нельзя использовать временный объект. std::ref не конструируется от временного
    приходится заводить бессмысленную переменную tmp
    нужно дополнительно вызывать get()

хочется такого

find(vec, "123").transform(handle).value_or(def_val);


может это и мелочи, но учитывая, что в коде без исключений value_or используется очень часто, то становится блокером
Re[9]: Вопрос про ссылки - что бы сломалось, если...
От: B0FEE664  
Дата: 12.07.24 10:25
Оценка:
Здравствуйте, sergii.p, Вы писали:

SP>хочется такого

SP>
SP>find(vec, "123").transform(handle).value_or(def_val);
SP>


SP>может это и мелочи, но учитывая, что в коде без исключений value_or используется очень часто, то становится блокером

#include <utility>
#include <iostream>
#include <string>
#include <optional>
#include <vector>
#include <algorithm>

using Map = std::vector<std::string_view>;
using Opt = std::optional<std::reference_wrapper<Map::value_type>>;
 
const std::string_view& find(Map& m, std::string_view s, const std::string_view& sDefault)
{
    auto it = std::find(m.begin(), m.end(), s);
    return it == m.end() ? sDefault : *it;
}

int main(int argc, char* argv[]) {
    Map vec = {"123", "234"};

    auto tmp = std::string_view{"123"};
    std::cout << find(vec, tmp, "not found");

    return 0;
}


std::optional здесь не нужен.
И каждый день — без права на ошибку...
Re: Вопрос про ссылки - что бы сломалось, если...
От: graniar  
Дата: 13.07.24 19:04
Оценка:
Здравствуйте, Shmj, Вы писали:

S>// как то сделать, чтобы ref1 и ref2 ссылались на одну область памяти


Используй указатели и не ломай мозг надуманными проблемами.
Ссылки нужны только для локального удобства, например


int& ref = some.complicated[lvalue->expression];

if(ref==-1) ref = current_iteration;


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

int a = 10;
int b = 20;
int* ref1 = a;
int* ref2 = b;

// как то сделать, чтобы ref1 и ref2 ссылались на одну область памяти

ref1 = ref2;


Сорри, если уже ответили, лень было всю ветку читать.
Re[2]: Вопрос про ссылки - что бы сломалось, если...
От: Shmj Ниоткуда  
Дата: 13.07.24 19:05
Оценка:
Здравствуйте, graniar, Вы писали:

G>Используй указатели и не ломай мозг надуманными проблемами.

G>Ссылки нужны только для локального удобства, например

А как же передача в функцию по ссылке? Это и удобно и память лишний раз не копируется.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.