Вопрос такой. Ссылки нельзя переназначить на другой адрес, что мешает использовать их в map и пр.
int a = 10;
int b = 20;
int& ref1 = a;
int& ref2 = b;
// как то сделать, чтобы ref1 и ref2 ссылались на одну область памяти
ref1 = ref2 // присваивает значение b в a, а не присваиваем ref1 адрес ref2, как хотелось бы. А что мешает?
А вот гипотетически можно было бы разрешить присваивать ссылкам адреса других ссылок? Что бы при этом принципиально сломалось? Ведь все-равно вторая ссылка обязательно на что-то ссылается то.
Здравствуйте, 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[2]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, Doom100500, Вы писали:
D>Мешает то, что если ссылка начнёт менять то, на что она ссылается, то она сможет принимать и неинициализированное значение, что сразы же убирает уверенность в её валидности. А значит с ссылками придётся работаь как с указателями — то есть постоянно проверять на null, плюс всякие бесконтрольные UB. Это сразу убивает весь смысл ссылок в C++
Но если разрешить только между ссылками. Т.е. просто адрес напрямую установить не можете, а от одной ссылки переназначить на другую — можно. А ведь другая то тоже 100% на что-то ссылается же.
Есть C++ в котором ссылки не могут менять свое значение. Рассуждения о том, что бы было бы если бы относительно C++ осмысленны так же, как рассуждения о том, что было бы если бы Shmj перестал засирать RSDN своей тупизной.
Вы хотите сделать новый язык, в котором это было бы не так?
Или просто не знаете про существование std::reference_wrapper?
Re[3]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Doom100500, Вы писали:
D>>Мешает то, что если ссылка начнёт менять то, на что она ссылается, то она сможет принимать и неинициализированное значение, что сразы же убирает уверенность в её валидности. А значит с ссылками придётся работаь как с указателями — то есть постоянно проверять на null, плюс всякие бесконтрольные UB. Это сразу убивает весь смысл ссылок в C++
S>Но если разрешить только между ссылками. Т.е. просто адрес напрямую установить не можете, а от одной ссылки переназначить на другую — можно. А ведь другая то тоже 100% на что-то ссылается же.
Страуструп подразумевал, что ссылка — это псевдоним. Псевдоним принадлежит только кому-то одному. В свази с этим уже написано тонны кода типа ref1 = ref2. Вот он и сломается.
Почему Страуструп так решил — пусть теоретики расскажут.
Спасибо за внимание
Re[4]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, Doom100500, Вы писали:
D>>>Мешает то, что если ссылка начнёт менять то, на что она ссылается, то она сможет принимать и неинициализированное значение, что сразы же убирает уверенность в её валидности. А значит с ссылками придётся работаь как с указателями — то есть постоянно проверять на null, плюс всякие бесконтрольные UB. Это сразу убивает весь смысл ссылок в C++
S>>Но если разрешить только между ссылками. Т.е. просто адрес напрямую установить не можете, а от одной ссылки переназначить на другую — можно. А ведь другая то тоже 100% на что-то ссылается же.
D>Страуструп подразумевал, что ссылка — это псевдоним. Псевдоним принадлежит только кому-то одному. В свази с этим уже написано тонны кода типа ref1 = ref2. Вот он и сломается. D>Почему Страуструп так решил — пусть теоретики расскажут.
Ну очевидно, что для изменения адреса ссылки использовался бы синтаксис вроде &a = &b.
Здравствуйте, Shmj, Вы писали:
S>А вот гипотетически можно было бы разрешить присваивать ссылкам адреса других ссылок? Что бы при этом принципиально сломалось? Ведь все-равно вторая ссылка обязательно на что-то ссылается то.
А синтаксис какой был бы?
Такой же?
Прикинь у тебя два вектора и ты пишешь a[i]=b[i]
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой. Ссылки нельзя переназначить на другой адрес, что мешает использовать их в map и пр. S>А вот гипотетически можно было бы разрешить присваивать ссылкам адреса других ссылок? Что бы при этом принципиально сломалось? Ведь все-равно вторая ссылка обязательно на что-то ссылается то.
Имхо, ты из раза в раз совершаешь одну и ту же ошибку: вместо того, чтобы прийти, рассказать задачу и попросить помощи в решении, ты пускаешься в глубокие теоретические изыскания и какое-то пустое философствование. В маниловщину, проще говоря. Реакцию участников форума ты видишь сам.
Здравствуйте, 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[2]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, B0FEE664, Вы писали:
BFE>Ссылка — это второе имя переменной (в отличии от ссылочного типа). В map не кладут имена переменных. В map кладут значения переменных.
Ну вот зачем ты это пишешь? Чтобы еще больше запутать его? А когда ссылка является результатом выражения, например std::max(42, 43) где там какое имя?
--
Re[3]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, rg45, Вы писали:
BFE>>Ссылка — это второе имя переменной (в отличии от ссылочного типа). В map не кладут имена переменных. В map кладут значения переменных. R>Ну вот зачем ты это пишешь? Чтобы еще больше запутать его? А когда ссылка является результатом выражения, например std::max(42, 43) где там какое имя?
Так это тип, а не ссылка.
Re[4]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, 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&). А вот никакого имени здесь нет — ни первого, ни второго.
Имя есть у переменной. Но переменная — это не единственная форма существования ссылок.
Здравствуйте, 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>Выражение *ptr здесь вычисляется в ссылку (и конечно же, у этой ссылки есть тип — int&). А вот никакого имени здесь нет — ни первого, ни второго.
Совершенно не видно, что здесь где-то есть ссылка.
R>Имя есть у переменной. Но переменная — это не единственная форма существования ссылок.
В каком смысле "ссылки существуют"?
И каждый день — без права на ошибку...
Re[3]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, rg45, Вы писали:
BFE>>Ссылка — это второе имя переменной (в отличии от ссылочного типа). В map не кладут имена переменных. В map кладут значения переменных. R>Ну вот зачем ты это пишешь? Чтобы еще больше запутать его? А когда ссылка является результатом выражения, например std::max(42, 43) где там какое имя?
А где тут ссылка?
И каждый день — без права на ошибку...
Re[4]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, Евгений Музыченко, Вы писали:
R>>>std::max(42, 43) BFE>>А где тут ссылка? ЕМ>Дык, в определении же.
Не, там есть тип возвращаемого значения, а ссылки — нет.
И каждый день — без права на ошибку...
Re[6]: Вопрос про ссылки - что бы сломалось, если...
Здравствуйте, 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.
Тут речь про возвращаемый тип, а не ссылку.
Сказать, что функция возвращает ссылку, это всё равно, что сказать, что функция возвращает имя.
