Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.224.39.74] |
|
Страницы: (11) « Первая ... 6 7 [8] 9 10 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#106
,
|
|
|
Сообщ.
#107
,
|
|
|
Цитата applegame @ В школу. На урок информатики, 8-го класса. Прости, цензурные эпитеты кончились. С помощью ссылки ты "защищаешь" некое "значение" ссылки (хотя формально "значения" у ссылки нет, но мы сделаем вид, что есть), а проблема-то возникает не со "значением" ссылки, а с объектом на короый она ссылается, а его она защищает не лучше указателя. Добавлено Цитата applegame @ Нет. И это тоже надо объяснять?? Пожалуй, я пойду отсюда. У Flex Ferrum-а нервы крепче.С тем же успехом ты можешь создать константный указатель, компилятор тоже будет знать, что "единственное место, где Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#108
,
|
|
|
Qraizer, мда...
Добавлено Qraizer, по типам скажешь что-нибудь или тоже нет? Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#109
,
|
|
|
Вот это, пожалуй, единственное серьёзное замечание.
Цитата applegame @ Видишь ли, библиотекам обычно плевать, что там написано у нас, а нам зачастую плевать, как реализованы библиотеки. И если каждое из обоих написаны безупречно, то это ещё не означает, что собранные в одну кучу они окажутся счастливы. В здравом уме и трезвой памяти такой говнокод никто не пустит в серьезный проект. Добавлено Цитата D_KEY @ А чего ты ожидал? Просто интересно. Я вот к примеру, не ожидал, что пишу для Исмаила Прокопенко. Qraizer, мда... Добавлено P.S. По системе типов я сказал. Не тебе, правда, но applegame-у тоже не понравилось. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#110
,
|
|
|
Цитата Qraizer @ P.S. По системе типов я сказал. Не тебе, правда, но applegame-у тоже не понравилось. Если не сложно, тыкни где. Плохо следил за вашим обсуждением. Но если что, сам потом поищу. Добавлено Цитата Qraizer @ А чего ты ожидал? Аргументации. И объяснения, если человек не понимает. Ты умеешь, я помню. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#111
,
|
|
|
Шо, опять "вы дураки, я умный"? Печально
Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#112
,
|
|
|
Цитата Qraizer @ В школу. На урок информатики, 8-го класса. Прости, цензурные эпитеты кончились. Цитата Qraizer @ Qraizer, такой Qraizer. Иди-иди уже, прими успокоительное и антивысокомерин.Нет. И это тоже надо объяснять?? Пожалуй, я пойду отсюда. У Flex Ferrum-а нервы крепче. Цитата D_KEY @ Человек все прекрасно понимает. А вот оппоненту нечего возразить и все сводится как обычно кАргументации. И объяснения, если человек не понимает. Ты умеешь, я помню. Цитата OpenGL @ "вы дураки, я умный" Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#113
,
|
|
|
Цитата D_KEY @ Четвёртый раз одно и то же? Ещё прошлым летом надоело. Аргументации. Добавлено А хотя давай. Добавлено Цитата applegame @ В общем случае не может. Даже больше: может в ограниченном количестве случаев. Всё потому, что указатель доступен программисту как есть, поэтому компилятор не может гарантировать, кто где-то, в невидимом ему контексте, этот указатель программером не поменяется, даже если всё время жизни объекта-указателя у него перед глазами. ... Учёт этой штуки по факту заставляет компилятор запрещать многие оптимизации. Которые доступны при замене указателей на ссылки, т.к. единственное место, где ссылка может поменять своё значение – это точка её инициализации. Конечно, невелика разница, если рассматриваемый объект является параметром функции/метода, но достаточно представить себе поле класса, и тут уже не всё так шоколадно с указателями и всё прекрасно с ссылками.Компилятор запросто может и разыменованный указатель соптимизировать и не создавать реальной переменной. А может и ссылку создать в виде указателя, если ему приспичит. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#114
,
|
|
|
Цитата applegame @ Какие посты? То что привел Флекс? В здравом уме и трезвой памяти такой говнокод никто не пустит в серьезный проект. Да. Вот тут стоит прокомментировать. Это ни разу не говнокод. Ситуаций в реальном коде, когда temporary object биндится к l-value (или r-value) reference - пруд пруди. Собственно, это любой вызов, где происходит неявный каст через инициализирующий конструктор. Или где в одну функцию передаётся результат работы другой. И т. п. Вот когда возвращаемое значение надо биндить к явной ссылке на константу - сходу сказать не могу. Очевидно, что константные указатели в этой ситуации не помогут от слова "совсем". Ибо указатель - это указатель. То, с чем можно работать явно (в отличие от ссылки). И (ещё раз) это отличие - принципиальное. Добавлено Цитата Qraizer @ Учёт этой штуки по факту заставляет компилятор запрещать многие оптимизации. Что и было мною продемонстрировано на примерах. Но это, почему-то, не аргумент. Оказывается, я повёл себя нечестно, запретив оптимизировать указатель. Добавлено Цитата Qraizer @ но достаточно представить себе поле класса, и тут уже не всё так шоколадно с указателями и всё прекрасно с ссылками. Поясни примером кода, что ты имеешь в виду. Добавлено Цитата applegame @ Параметр, который пришел как ref T будет иметь тип T, соответственно и в шаблонный метод он придет как T. Ну да. Тут applegame правильно сказал. Это я запамятовал. Цитата D_KEY @ Не будет такого типа как 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, но на самом деле тут работают правила "схлопывания" ссылок. Добавлено Цитата applegame @ Если у тебя есть две ссылки разного типа, но указывающие в одно и тоже место - ничего хорошего не жди: Как это. Можно и зайца научить курить. Нет ничего невозможного для человека с интеллектом. Но только вот зачем? Да, действительно, в С++ можно обойти встроенные в компилятор механизмы защиты и контроля корректности. Только вот зачем это делать без крайней на то необходимости? Как раз таки приведённые игрища с ссылками и есть говнокод. Добавлено Но хотя бы лишь то отличие, что ссылку нельзя оставить неинициализированной - уже огромный плюс. Ибо сейчас (в очередной раз) напоролся на то, что профачил инициализацию указателя, а потом к нему обратился. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#115
,
|
|
|
Цитата Qraizer @ Лучше не надо. Все равно твоя аргументация сводится к отсылкам к собственным постам (в том числе в весьма отдаленном прошлом), к фейспалмами и советам пойти куда-нибудь далеко учить матчасть. Такую "аргументацию" оставь при себе.А хотя давай. Цитата Flex Ferrum @ Да, это встречается очень часто. Но речь-то шла не об этом, а о:Ситуаций в реальном коде, когда temporary object биндится к l-value (или r-value) reference - пруд пруди. Собственно, это любой вызов, где происходит неявный каст через инициализирующий конструктор. Или где в одну функцию передаётся результат работы другой. И т. п. Цитата Flex Ferrum @ Вот это я назвал говнокодом.Вот когда возвращаемое значение надо биндить к явной ссылке на константу - сходу сказать не могу. Цитата Flex Ferrum @ А причем тут константные указатели? Твой пример обсуждался в контексте ценности подобных "умений" ссылок, а не сравнения с константными указателями. Константные указатели появились в споре с Qraizerом, не с тобой.Очевидно, что константные указатели в этой ситуации не помогут от слова "совсем". Ибо указатель - это указатель. То, с чем можно работать явно (в отличие от ссылки). И (ещё раз) это отличие - принципиальное. Цитата Flex Ferrum @ Забавно, что ты не заметил, что продемонстрировал строго обратное Цитата Qraizer @ Учёт этой штуки по факту заставляет компилятор запрещать многие оптимизации. Что и было мною продемонстрировано на примерах. Но это, почему-то, не аргумент. Qraizer, говорил, о том, что, в отличие от указателей, ссылки помогают избежать опасных агрессивных оптимизаций. А ты привел пример, где, наоборот, ссылка агрессивно соптимизировалась. Кроме того, никакого pointer aliasing в твоей демонстрации нет. Вы братцы, похоже, совсем запутались в дебрях реализаций. Передозировка абстракциями налицо. Цитата Flex Ferrum @ Ну я тоже так умею. Ты мой следующий пример смотрел? Там ссылка тоже перестала оптимизироваться. Оказывается, я повёл себя нечестно, запретив оптимизировать указатель. Цитата Flex Ferrum @ Ну этот код не противоречит концепции отсутствия ссылочного типа. Представь, что если ты будешь определять тип переменных os и cont в теле функции PrintContainer, то компилятор будет говорить, что их тип std::cout и std::string соответственно, а не std::cout&& и std::string&&. Правда возникает резонный вопрос, а что тогда меняет такое вот упразднение ссылочного типа?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, но на самом деле тут работают правила "схлопывания" ссылок. Цитата Flex Ferrum @ Абсолютно согласен. Pointer aliasing из этой самой серии. И это Qraizer завел об этом разговор, не я. Типа ссылки помогут избежать глюков компилятора в таком вот говнокоде. Во-первых, не помогут, во-вторых, как ты справедливо заметил, можно и зайца научить курить.Цитата applegame @ Если у тебя есть две ссылки разного типа, но указывающие в одно и тоже место - ничего хорошего не жди: Как это. Можно и зайца научить курить. Нет ничего невозможного для человека с интеллектом. Но только вот зачем? Да, действительно, в С++ можно обойти встроенные в компилятор механизмы защиты и контроля корректности. Только вот зачем это делать без крайней на то необходимости? Как раз таки приведённые игрища с ссылками и есть говнокод. Цитата Flex Ferrum @ Ну это, конечно, плюс, но не перед указателями. Тут бы тебе помог тот самый константый указатель. Тогда компилятор не дал бы тебе профачить его инициализацию. Но хотя бы лишь то отличие, что ссылку нельзя оставить неинициализированной - уже огромный плюс. Ибо сейчас (в очередной раз) напоролся на то, что профачил инициализацию указателя, а потом к нему обратился. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#116
,
|
|
|
Оппа, вот это поворот!
Похоже на то, что вы, товарищи, включая нашего уважаемого гуру Флекса (и меня конечно, но мне простительно ), сами плохо знаете, что можно биндить, а чего нельзя к константным ссылкам. Так вот, если из функции возвращается ссылка на временный объект, то его нельзя биндить к константной ссылке. И пофиг был ли этот временный объект создан внутри функции или в выражении вызова функции и передан в качестве параметра: Цитата 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. Вот тут, Флекс смухлевал (полагаю, что не намеренно, а токмо по ошибке): Данная функция вернет отнюдь не ссылку, а значение - копию параметра - https://ideone.com/CkeMhZ, которое прибиндится к константной ссылке и все будет ок. А вот если написать: auto& TakingRef(const std::string& str) { return str; } Если я неправ - покажите где. Если Флекс ошибся - ждем-с признания ошибки. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#117
,
|
|
|
Цитата applegame @ Вот это я назвал говнокодом. И это не говнокод. Представь, что такой биндинг делается в шаблонном методе, который не знает, что возвращает аргумент-функтор - ссылку или значение. Цитата applegame @ А причем тут константные указатели? Твой пример обсуждался в контексте ценности подобных "умений" ссылок, а не сравнения с константными указателями. Константные указатели появились в споре с Qraizerом, не с тобой. Ну а что, я не могу ответить (или использовать) твои аргументы из спора с Крайзером? Указатель (константный или нет) остаётся указателем, самостоятельным объектом, сущностью. В отличие от ссылки. Цитата applegame @ Забавно, что ты не заметил, что продемонстрировал строго обратное Я продемонстрировал именно то, что хотел. Компилятор агрессивно оптимизирует ссылки и никто не может ему этого запретить. В отличие от указателей. А там, где разработчик делает компилятору подножки - он сам себе злобный чебуран. Цитата applegame @ Ты мой следующий пример смотрел? Там ссылка тоже перестала оптимизироваться. Это который? Цитата applegame @ Правда возникает резонный вопрос, а что тогда меняет такое вот упразднение ссылочного типа? А ты возьми и упраздни. Убери && из объявления параметров и посмотри, что получится. Я уже говорил: пример показывает, что ссылка - это не часть типа "вообще", а часть типа конкретного параметра, часть объявления параметра. Цитата applegame @ Pointer aliasing из этой самой серии Pointer Aliasing совсем из другой серии. А относительно говнокода - garbage in, garbage out. Чего удивляться тому, что механизм перестаёт работать, если по нему молотком херачат? Цитата applegame @ Тут бы тебе помог тот самый константый указатель. Тогда компилятор не дал бы тебе профачить его инициализацию. Не помог бы. У меня этот указатель дальше по коду меняется. Добавлено Цитата 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. Вот тут, Флекс смухлевал (полагаю, что не намеренно, а токмо по ошибке): Данная функция вернет отнюдь не ссылку, а значение - копию параметра - https://ideone.com/CkeMhZ, которое прибиндится к константной ссылке и все будет ок. А вот если написать: auto& TakingRef(const std::string& str) { return str; } Если я неправ - покажите где. Если Флекс ошибся - ждем-с признания ошибки. Не. Я не ошибся. Я знал, что будет возвращено значение (временный объект). А твой пример - компилятор не может запретить тебе так делать (более того, у него есть подобные функции - std::ref, std::move, std::forward), так что ошибка в этом примере - на совести разработчика. Добавлено Тут только статический анализатор поможет. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#118
,
|
|
|
Цитата Flex Ferrum @ В данном случае не можешь, потому что контекст разный и споры разные.Ну а что, я не могу ответить (или использовать) твои аргументы из спора с Крайзером? Указатель (константный или нет) остаётся указателем, самостоятельным объектом, сущностью. В отличие от ссылки. Цитата Flex Ferrum @ Не выкручивайся. Ты же сказал, что продемонстрировал то о чем говорит Qraizer, а оказалось наоборот. Я продемонстрировал именно то, что хотел. Цитата Flex Ferrum @ Ага, и ты именно так и сделал. А там, где разработчик делает компилятору подножки - он сам себе злобный чебуран. Цитата Flex Ferrum @ Вот этот - https://godbolt.org/g/sNgSPXЭто который? Цитата Flex Ferrum @ Нет-нет. Дикей не предлагает убрать && из объявлений. Он предлагает чтобы компилятор перестал это считать типом, а считал этот атрибутами параметров функции или возвращаемого значения. Или он и так не считает? если я обявлю две переменные int& и int, будет ли компилятор считать, что их типы разные?А ты возьми и упраздни. Убери && из объявления параметров и посмотри, что получится. Цитата Flex Ferrum @ Что правда? Ну давай расскажи, как можно схлопотать проблемы с pointer aliasing не говнокодя и как ссыоки помогут бороться с этими проблемами. Ну хоть один примерчик-то можете привести или только утверждения делать мастера?Pointer Aliasing совсем из другой серии. Цитата Flex Ferrum @ Ну а зачем ты тогда ссылки-то вспомнил? Тебе тут и ссылка не поможет.Не помог бы. У меня этот указатель дальше по коду меняется. Цитата Flex Ferrum @ То есть ты намеренно смухлевал? Расскажи еще, что ты знал, что ссылки на временные объекты возвращаемые из функций нельзя биндить даже к константным ссылкам. Я тут тебе цитат понакидаю. Никто тебе не поверит. Не. Я не ошибся. Я знал, что будет возвращено значение (временный объект). Однако Флексу, оказывается, не чуждо верчение ужом на сковородке. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#119
,
|
|
|
Цитата Flex Ferrum @ Я уже говорил: пример показывает, что ссылка - это не часть типа "вообще", а часть типа конкретного параметра, часть объявления параметра. Достигается это за счёт кучи правил и исключений из них. T& является типом в C++, но с кучей всяких исключений и дополнительных правил. Что в итоге приводит к тому, что он часто ведёт себя не как тип И непонятно зачем это все сделано. Вот я и думаю, а что бы было, если бы в язык вместо непонятного типа ввели доп. возможность указывать способ передачи/возврата в/из функции(да и фиг с ним, пусть и локальные синонимы разрешили делать), без изменения системы типов. Правила довольно простые. Система типов не "обогащается" такими странными "полутипами". Пользователи языка не мучаются, даже если начинающие. Вопросы о связи указателей и ссылок вряд ли бы возникали так часто, как сейчас. Разработчикам компиляторов так же было бы намного легче. Добавлено Но у меня смутное чувство, что я что-то упускаю. И возможно это не ошибка дизайна языка, а какой-то гениальный ход, который до меня не доходит. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#120
,
|
|
|
Прошу уполномоченных лиц, отделить обсуждение ссылок в плюсах в отдельную тему. Тут уже давно не пахнет "D vs C++".
Это сообщение было перенесено сюда или объединено из темы "D vs C++" |