Баллада о ссылках в С++

[Qraizer]

Цитата applegame @ 07.07.17, 08:51

Я тебя прекрасно понял и у меня создалось впечатление, что ты немного не понимаешь, что такое pointer aliasing.

Тьфу. Всё, сотри pointer aliasing из своей памяти. Нет примера. Сам придумай.


Это сообщение было перенесено сюда или объединено из темы "D vs C++"

Сообщение отредактировано: JoeUser - 08.07.17, 22:45

[Qraizer]

Цитата applegame @ 07.07.17, 08:51

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

В школу. На урок информатики, 8-го класса. Прости, цензурные эпитеты кончились.

Добавлено 07.07.17, 19:49

Цитата applegame @ 07.07.17, 08:51

С тем же успехом ты можешь создать константный указатель, компилятор тоже будет знать, что "единственное место, где ссылка константный указатель может поменять своё значение – это точка её его инициализации.":

Нет. И это тоже надо объяснять?? Пожалуй, я пойду отсюда. У Flex Ferrum-а нервы крепче.

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

Сообщение отредактировано: Qraizer - 08.07.17, 22:45

[D_KEY]

Qraizer, мда...

Добавлено 07.07.17, 19:52
Qraizer, по типам скажешь что-нибудь или тоже нет?

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

[Qraizer]

Вот это, пожалуй, единственное серьёзное замечание.

Цитата applegame @ 07.07.17, 08:51

В здравом уме и трезвой памяти такой говнокод никто не пустит в серьезный проект.

Видишь ли, библиотекам обычно плевать, что там написано у нас, а нам зачастую плевать, как реализованы библиотеки. И если каждое из обоих написаны безупречно, то это ещё не означает, что собранные в одну кучу они окажутся счастливы.

Добавлено 07.07.17, 20:05

Цитата D_KEY @ 07.07.17, 19:50

Qraizer, мда...

А чего ты ожидал? Просто интересно. Я вот к примеру, не ожидал, что пишу для Исмаила Прокопенко.

Добавлено 07.07.17, 20:06
P.S. По системе типов я сказал. Не тебе, правда, но applegame-у тоже не понравилось.

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

[D_KEY]

Цитата Qraizer @ 07.07.17, 19:55

P.S. По системе типов я сказал. Не тебе, правда, но applegame-у тоже не понравилось.

Если не сложно, тыкни где. Плохо следил за вашим обсуждением. Но если что, сам потом поищу.

Добавлено 07.07.17, 20:16

Цитата Qraizer @ 07.07.17, 19:55

А чего ты ожидал?

Аргументации. И объяснения, если человек не понимает. Ты умеешь, я помню.

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

[OpenGL]

Шо, опять "вы дураки, я умный"? Печально

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

[applegame]

Цитата Qraizer @ 07.07.17, 19:48

В школу. На урок информатики, 8-го класса. Прости, цензурные эпитеты кончились.

Цитата Qraizer @ 07.07.17, 19:48

Нет. И это тоже надо объяснять?? Пожалуй, я пойду отсюда. У Flex Ferrum-а нервы крепче.

Qraizer, такой Qraizer. Иди-иди уже, прими успокоительное и антивысокомерин.

Цитата D_KEY @ 07.07.17, 20:15

Аргументации. И объяснения, если человек не понимает. Ты умеешь, я помню.

Человек все прекрасно понимает. А вот оппоненту нечего возразить и все сводится как обычно к

Цитата OpenGL @ 07.07.17, 20:20

"вы дураки, я умный"

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

Сообщение отредактировано: applegame - 08.07.17, 22:45

[Qraizer]

Цитата D_KEY @ 07.07.17, 20:15

Аргументации.

Четвёртый раз одно и то же? Ещё прошлым летом надоело.

Добавлено 08.07.17, 06:12
А хотя давай.

Добавлено 08.07.17, 06:14

Цитата applegame @ 06.07.17, 12:12

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

В общем случае не может. Даже больше: может в ограниченном количестве случаев. Всё потому, что указатель доступен программисту как есть, поэтому компилятор не может гарантировать, кто где-то, в невидимом ему контексте, этот указатель программером не поменяется, даже если всё время жизни объекта-указателя у него перед глазами. ... Учёт этой штуки по факту заставляет компилятор запрещать многие оптимизации. Которые доступны при замене указателей на ссылки, т.к. единственное место, где ссылка может поменять своё значение – это точка её инициализации. Конечно, невелика разница, если рассматриваемый объект является параметром функции/метода, но достаточно представить себе поле класса, и тут уже не всё так шоколадно с указателями и всё прекрасно с ссылками.

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

[Flex Ferrum]

Цитата applegame @ 07.07.17, 08:51

Какие посты? То что привел Флекс? В здравом уме и трезвой памяти такой говнокод никто не пустит в серьезный проект.

Да. Вот тут стоит прокомментировать. Это ни разу не говнокод. Ситуаций в реальном коде, когда temporary object биндится к l-value (или r-value) reference - пруд пруди. Собственно, это любой вызов, где происходит неявный каст через инициализирующий конструктор. Или где в одну функцию передаётся результат работы другой. И т. п. Вот когда возвращаемое значение надо биндить к явной ссылке на константу - сходу сказать не могу. Очевидно, что константные указатели в этой ситуации не помогут от слова "совсем". Ибо указатель - это указатель. То, с чем можно работать явно (в отличие от ссылки). И (ещё раз) это отличие - принципиальное.

Добавлено 08.07.17, 06:24

Цитата Qraizer @ 08.07.17, 06:11

Учёт этой штуки по факту заставляет компилятор запрещать многие оптимизации.

Что и было мною продемонстрировано на примерах. Но это, почему-то, не аргумент. Оказывается, я повёл себя нечестно, запретив оптимизировать указатель.

Добавлено 08.07.17, 06:25

Цитата Qraizer @ 08.07.17, 06:11

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

Поясни примером кода, что ты имеешь в виду.

Добавлено 08.07.17, 06:30

Цитата D_KEY @ 07.07.17, 12:50

Flex Ferrum, можешь кодом?

Цитата applegame @ 07.07.17, 13:17

Параметр, который пришел как ref T будет иметь тип T, соответственно и в шаблонный метод он придет как T.

Ну да. Тут applegame правильно сказал. Это я запамятовал.

Цитата D_KEY @ 07.07.17, 12:18

Не будет такого типа как T &. Не будет такой специализации шаблона, например. Не будет странного типа без размера в языке.

BTW, в плюсах от этого всё равно никуда не деться. Вот, скажем, код:

#include <iostream>
#include <string>
 
using namespace std;
 
template<typename Os, typename Cont, typename Delim>
void PrintContainer(Os&& os, Cont&& cont, Delim delim)
{
    bool isFirst = true;
    for (auto& v : cont)
    {
        if (!isFirst)
            os << delim;
        else
            isFirst = false;
            
        os << v;
    }
}
 
int main()
{
    auto& os = std::cout;
    std::string hw = "Hello World!";
    PrintContainer(std::cout, hw, ", ");
    return 0;
}

Он прекрасно работает с любыми комбинациями передаваемых значений. И, опять же, хороший пример того, что ссылочный тип - это больше инструкции компилятору и относится к декларации параметра, а не типа. В зависимости от того, что передаётся в PrintContainer шаблонные типы могут оказаться как правыми сслыками, так и левыми на константы, так и конкретными значениями. Кто-то называет такой приём universal reference, но на самом деле тут работают правила "схлопывания" ссылок.

Добавлено 08.07.17, 06:46

Цитата applegame @ 07.07.17, 08:51

Если у тебя есть две ссылки разного типа, но указывающие в одно и тоже место - ничего хорошего не жди:

Как это. Можно и зайца научить курить. Нет ничего невозможного для человека с интеллектом. Но только вот зачем? Да, действительно, в С++ можно обойти встроенные в компилятор механизмы защиты и контроля корректности. Только вот зачем это делать без крайней на то необходимости? Как раз таки приведённые игрища с ссылками и есть говнокод.

Добавлено 08.07.17, 06:58
Но хотя бы лишь то отличие, что ссылку нельзя оставить неинициализированной - уже огромный плюс. Ибо сейчас (в очередной раз) напоролся на то, что профачил инициализацию указателя, а потом к нему обратился.

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

Сообщение отредактировано: Flex Ferrum - 08.07.17, 22:45

[applegame]

Цитата Qraizer @ 08.07.17, 06:11

А хотя давай.

Лучше не надо. Все равно твоя аргументация сводится к отсылкам к собственным постам (в том числе в весьма отдаленном прошлом), к фейспалмами и советам пойти куда-нибудь далеко учить матчасть. Такую "аргументацию" оставь при себе.

Цитата Flex Ferrum @ 08.07.17, 06:23

Ситуаций в реальном коде, когда temporary object биндится к l-value (или r-value) reference - пруд пруди. Собственно, это любой вызов, где происходит неявный каст через инициализирующий конструктор. Или где в одну функцию передаётся результат работы другой. И т. п.

Да, это встречается очень часто. Но речь-то шла не об этом, а о:

Цитата Flex Ferrum @ 08.07.17, 06:23

Вот когда возвращаемое значение надо биндить к явной ссылке на константу - сходу сказать не могу.

Вот это я назвал говнокодом.

Цитата Flex Ferrum @ 08.07.17, 06:23

Очевидно, что константные указатели в этой ситуации не помогут от слова "совсем". Ибо указатель - это указатель. То, с чем можно работать явно (в отличие от ссылки). И (ещё раз) это отличие - принципиальное.

А причем тут константные указатели? Твой пример обсуждался в контексте ценности подобных "умений" ссылок, а не сравнения с константными указателями. Константные указатели появились в споре с Qraizerом, не с тобой.

Цитата Flex Ferrum @ 08.07.17, 06:23

Цитата Qraizer @ 08.07.17, 06:11

Учёт этой штуки по факту заставляет компилятор запрещать многие оптимизации.

Что и было мною продемонстрировано на примерах. Но это, почему-то, не аргумент.

Забавно, что ты не заметил, что продемонстрировал строго обратное
Qraizer, говорил, о том, что, в отличие от указателей, ссылки помогают избежать опасных агрессивных оптимизаций. А ты привел пример, где, наоборот, ссылка агрессивно соптимизировалась. Кроме того, никакого pointer aliasing в твоей демонстрации нет.
Вы братцы, похоже, совсем запутались в дебрях реализаций. Передозировка абстракциями налицо.

Цитата Flex Ferrum @ 08.07.17, 06:23

Оказывается, я повёл себя нечестно, запретив оптимизировать указатель.

Ну я тоже так умею. Ты мой следующий пример смотрел? Там ссылка тоже перестала оптимизироваться.

Цитата Flex Ferrum @ 08.07.17, 06:23

BTW, в плюсах от этого всё равно никуда не деться. Вот, скажем, код:

#include <iostream>
#include <string>
 
using namespace std;
 
template<typename Os, typename Cont, typename Delim>
void PrintContainer(Os&& os, Cont&& cont, Delim delim)
{
    bool isFirst = true;
    for (auto& v : cont)
    {
        if (!isFirst)
            os << delim;
        else
            isFirst = false;
            
        os << v;
    }
}
 
int main()
{
    auto& os = std::cout;
    std::string hw = "Hello World!";
    PrintContainer(std::cout, hw, ", ");
    return 0;
}

Он прекрасно работает с любыми комбинациями передаваемых значений. И, опять же, хороший пример того, что ссылочный тип - это больше инструкции компилятору и относится к декларации параметра, а не типа. В зависимости от того, что передаётся в PrintContainer шаблонные типы могут оказаться как правыми сслыками, так и левыми на константы, так и конкретными значениями. Кто-то называет такой приём universal reference, но на самом деле тут работают правила "схлопывания" ссылок.

Ну этот код не противоречит концепции отсутствия ссылочного типа. Представь, что если ты будешь определять тип переменных os и cont в теле функции PrintContainer, то компилятор будет говорить, что их тип std::cout и std::string соответственно, а не std::cout&& и std::string&&. Правда возникает резонный вопрос, а что тогда меняет такое вот упразднение ссылочного типа?

Цитата Flex Ferrum @ 08.07.17, 06:23

Цитата applegame @ 07.07.17, 08:51

Если у тебя есть две ссылки разного типа, но указывающие в одно и тоже место - ничего хорошего не жди:

Как это. Можно и зайца научить курить. Нет ничего невозможного для человека с интеллектом. Но только вот зачем? Да, действительно, в С++ можно обойти встроенные в компилятор механизмы защиты и контроля корректности. Только вот зачем это делать без крайней на то необходимости? Как раз таки приведённые игрища с ссылками и есть говнокод.

Абсолютно согласен. Pointer aliasing из этой самой серии. И это Qraizer завел об этом разговор, не я. Типа ссылки помогут избежать глюков компилятора в таком вот говнокоде. Во-первых, не помогут, во-вторых, как ты справедливо заметил, можно и зайца научить курить.

Цитата Flex Ferrum @ 08.07.17, 06:23

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

Ну это, конечно, плюс, но не перед указателями. Тут бы тебе помог тот самый константый указатель. Тогда компилятор не дал бы тебе профачить его инициализацию.

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

Сообщение отредактировано: applegame - 08.07.17, 22:45

[applegame]

Оппа, вот это поворот!

Похоже на то, что вы, товарищи, включая нашего уважаемого гуру Флекса (и меня конечно, но мне простительно ), сами плохо знаете, что можно биндить, а чего нельзя к константным ссылкам.
Так вот, если из функции возвращается ссылка на временный объект, то его нельзя биндить к константной ссылке. И пофиг был ли этот временный объект создан внутри функции или в выражении вызова функции и передан в качестве параметра:

Цитата cppreference.com - reference initialization

Whenever a reference is bound to a temporary or to a subobject thereof, the lifetime of the temporary is extended to match the lifetime of the reference, with the following exceptions:
- a temporary bound to a return value of a function in a return statement is not extended: it is destroyed immediately at the end of the return expression. Such function always returns a dangling reference.
...
- a temporary bound to a reference parameter in a function call exists until the end of the full expression containing that function call: if the function returns a reference, which outlives the full expression, it becomes a dangling reference.

Вот тут, Флекс смухлевал (полагаю, что не намеренно, а токмо по ошибке):

Цитата Flex Ferrum @ 06.07.17, 16:38

auto TakingRef(const std::string& str)
{
    return str;
}

Данная функция вернет отнюдь не ссылку, а значение - копию параметра - https://ideone.com/CkeMhZ, которое прибиндится к константной ссылке и все будет ок.
А вот если написать:

auto& TakingRef(const std::string& str)
{
    return str;
}

То получится ссылка указывающая на уничтоженный объект - https://ideone.com/23vwbP

Если я неправ - покажите где. Если Флекс ошибся - ждем-с признания ошибки.

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

Сообщение отредактировано: applegame - 08.07.17, 22:45

[Flex Ferrum]

Цитата applegame @ 08.07.17, 08:33

Вот это я назвал говнокодом.

И это не говнокод. Представь, что такой биндинг делается в шаблонном методе, который не знает, что возвращает аргумент-функтор - ссылку или значение.

Цитата applegame @ 08.07.17, 08:33

А причем тут константные указатели? Твой пример обсуждался в контексте ценности подобных "умений" ссылок, а не сравнения с константными указателями. Константные указатели появились в споре с Qraizerом, не с тобой.

Ну а что, я не могу ответить (или использовать) твои аргументы из спора с Крайзером? Указатель (константный или нет) остаётся указателем, самостоятельным объектом, сущностью. В отличие от ссылки.

Цитата applegame @ 08.07.17, 08:33

Забавно, что ты не заметил, что продемонстрировал строго обратное

Я продемонстрировал именно то, что хотел. Компилятор агрессивно оптимизирует ссылки и никто не может ему этого запретить. В отличие от указателей. А там, где разработчик делает компилятору подножки - он сам себе злобный чебуран.

Цитата applegame @ 08.07.17, 08:33

Ты мой следующий пример смотрел? Там ссылка тоже перестала оптимизироваться.

Это который?

Цитата applegame @ 08.07.17, 08:33

Правда возникает резонный вопрос, а что тогда меняет такое вот упразднение ссылочного типа?

А ты возьми и упраздни. Убери && из объявления параметров и посмотри, что получится. Я уже говорил: пример показывает, что ссылка - это не часть типа "вообще", а часть типа конкретного параметра, часть объявления параметра.

Цитата applegame @ 08.07.17, 08:33

Pointer aliasing из этой самой серии

Pointer Aliasing совсем из другой серии. А относительно говнокода - garbage in, garbage out. Чего удивляться тому, что механизм перестаёт работать, если по нему молотком херачат?

Цитата applegame @ 08.07.17, 08:33

Тут бы тебе помог тот самый константый указатель. Тогда компилятор не дал бы тебе профачить его инициализацию.

Не помог бы. У меня этот указатель дальше по коду меняется.

Добавлено 08.07.17, 10:53

Цитата applegame @ 08.07.17, 10:02

Оппа, вот это поворот!

Похоже на то, что вы, товарищи, включая нашего уважаемого гуру Флекса (и меня конечно, но мне простительно ), сами плохо знаете, что можно биндить, а чего нельзя к константным ссылкам.
Так вот, если из функции возвращается ссылка на временный объект, то его нельзя биндить к константной ссылке. И пофиг был ли этот временный объект создан внутри функции или в выражении вызова функции и передан в качестве параметра:

Цитата cppreference.com - reference initialization

Whenever a reference is bound to a temporary or to a subobject thereof, the lifetime of the temporary is extended to match the lifetime of the reference, with the following exceptions:
- a temporary bound to a return value of a function in a return statement is not extended: it is destroyed immediately at the end of the return expression. Such function always returns a dangling reference.
...
- a temporary bound to a reference parameter in a function call exists until the end of the full expression containing that function call: if the function returns a reference, which outlives the full expression, it becomes a dangling reference.

Вот тут, Флекс смухлевал (полагаю, что не намеренно, а токмо по ошибке):

Цитата Flex Ferrum @ 06.07.17, 16:38

auto TakingRef(const std::string& str)
{
    return str;
}

Данная функция вернет отнюдь не ссылку, а значение - копию параметра - https://ideone.com/CkeMhZ, которое прибиндится к константной ссылке и все будет ок.
А вот если написать:

auto& TakingRef(const std::string& str)
{
    return str;
}

То получится ссылка указывающая на уничтоженный объект - https://ideone.com/23vwbP

Если я неправ - покажите где. Если Флекс ошибся - ждем-с признания ошибки.

Не. Я не ошибся. Я знал, что будет возвращено значение (временный объект). А твой пример - компилятор не может запретить тебе так делать (более того, у него есть подобные функции - std::ref, std::move, std::forward), так что ошибка в этом примере - на совести разработчика.

Добавлено 08.07.17, 10:54
Тут только статический анализатор поможет.

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

[applegame]

Цитата Flex Ferrum @ 08.07.17, 10:45

Ну а что, я не могу ответить (или использовать) твои аргументы из спора с Крайзером? Указатель (константный или нет) остаётся указателем, самостоятельным объектом, сущностью. В отличие от ссылки.

В данном случае не можешь, потому что контекст разный и споры разные.

Цитата Flex Ferrum @ 08.07.17, 10:45

Я продемонстрировал именно то, что хотел.

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

Цитата Flex Ferrum @ 08.07.17, 10:45

А там, где разработчик делает компилятору подножки - он сам себе злобный чебуран.

Ага, и ты именно так и сделал.

Цитата Flex Ferrum @ 08.07.17, 10:45

Это который?

Вот этот - https://godbolt.org/g/sNgSPX

Цитата Flex Ferrum @ 08.07.17, 10:45

А ты возьми и упраздни. Убери && из объявления параметров и посмотри, что получится.

Нет-нет. Дикей не предлагает убрать && из объявлений. Он предлагает чтобы компилятор перестал это считать типом, а считал этот атрибутами параметров функции или возвращаемого значения. Или он и так не считает? если я обявлю две переменные int& и int, будет ли компилятор считать, что их типы разные?

Цитата Flex Ferrum @ 08.07.17, 10:45

Pointer Aliasing совсем из другой серии.

Что правда? Ну давай расскажи, как можно схлопотать проблемы с pointer aliasing не говнокодя и как ссыоки помогут бороться с этими проблемами. Ну хоть один примерчик-то можете привести или только утверждения делать мастера?

Цитата Flex Ferrum @ 08.07.17, 10:45

Не помог бы. У меня этот указатель дальше по коду меняется.

Ну а зачем ты тогда ссылки-то вспомнил? Тебе тут и ссылка не поможет.

Цитата Flex Ferrum @ 08.07.17, 10:45

Не. Я не ошибся. Я знал, что будет возвращено значение (временный объект).

То есть ты намеренно смухлевал? Расскажи еще, что ты знал, что ссылки на временные объекты возвращаемые из функций нельзя биндить даже к константным ссылкам. Я тут тебе цитат понакидаю. Никто тебе не поверит.

Однако Флексу, оказывается, не чуждо верчение ужом на сковородке.

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

Сообщение отредактировано: applegame - 08.07.17, 22:45

[D_KEY]

Цитата Flex Ferrum @ 08.07.17, 10:45

Я уже говорил: пример показывает, что ссылка - это не часть типа "вообще", а часть типа конкретного параметра, часть объявления параметра.

Достигается это за счёт кучи правил и исключений из них. T& является типом в C++, но с кучей всяких исключений и дополнительных правил. Что в итоге приводит к тому, что он часто ведёт себя не как тип И непонятно зачем это все сделано.
Вот я и думаю, а что бы было, если бы в язык вместо непонятного типа ввели доп. возможность указывать способ передачи/возврата в/из функции(да и фиг с ним, пусть и локальные синонимы разрешили делать), без изменения системы типов. Правила довольно простые. Система типов не "обогащается" такими странными "полутипами". Пользователи языка не мучаются, даже если начинающие. Вопросы о связи указателей и ссылок вряд ли бы возникали так часто, как сейчас. Разработчикам компиляторов так же было бы намного легче.

Добавлено 08.07.17, 11:34
Но у меня смутное чувство, что я что-то упускаю. И возможно это не ошибка дизайна языка, а какой-то гениальный ход, который до меня не доходит.

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

[applegame]

Прошу уполномоченных лиц, отделить обсуждение ссылок в плюсах в отдельную тему. Тут уже давно не пахнет "D vs C++".

Это сообщение было перенесено сюда или объединено из темы "D vs C++"

Сообщение отредактировано: applegame - 08.07.17, 22:45