Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.16.54.63] |
|
Страницы: (11) « Первая ... 4 5 [6] 7 8 ... 10 11 все ( Перейти к последнему сообщению ) |
Сообщ.
#76
,
|
|
|
Цитата D_KEY @ Можно по подробнее? Ну подробнее чем просто смайлик? С чем ты не согласен? Если хочешь - можешь перевести что там написано, а то я в английском вообще не понимаю, полный ноль. Спасибо. Добавлено К слову, не знаю как там D, в C# ровно такая же фиговина, этот D очень сильно на C# похож, там тоже ссылочная семантика, но ЕМНИП - структуры, передаются по значению, и есть даже модификаторы типа out, ref которые явно можно указывать в параметрах методов. Так вот ref - ведет себя как ссылка, а out - как указатель. Вся фишка в том, что об этом все знают, им нет дела до того - как это работает в плюсах, там просто свои правила и все. Они не применимы к С++. Так же как и на оборот. Просто ваш спор напоминает спор слепого с глухим )) Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#77
,
|
|
|
Цитата KILLER @ и есть даже модификаторы типа out, ref которые явно можно указывать в параметрах методов. Так вот ref - ведет себя как ссылка, а out - как указатель. Это не модификатора типа Это специальные ключевые слова для изменения способа передачи аргумента. И мой вопрос относительно C++ как раз о том, нахрена там ссылка является частью типа? Какую пользу это несёт? По-моему это только усложняет систему типов, добавляет кучу правил и исключений из них. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#78
,
|
|
|
Цитата D_KEY @ И мой вопрос относительно C++ как раз о том, нахрена там ссылка является частью типа? Какую пользу это несёт? По-моему это только усложняет систему типов, добавляет кучу правил и исключений из них. Где там? Цитата D_KEY @ Какую пользу это несёт? В основном - быстродействие. Это несет очень большую пользу. В основном ты работаешь просто с другими задачами на этих языках. И там в основном нужен динамический полиморфизм. Смысла в основном нет использовать какие то примитивные типы, ты просто получил коробку с кучей возможностей, не задумываясь о том, как это выглядит на более низком уровне. Добавлено Цитата D_KEY @ По-моему это только усложняет систему типов, добавляет кучу правил и исключений из них. Вот тебе С++ void f (Widget&& param) ; // rvalue - ccылкa Widget&& var1 = Widget () ; // rvalue- ccылкa auto&& var2 = var1 ; // Не rvalue- ccылкa (универсалоьная ссылка) template<typename Т> void f( std::vector<T>&& param) ; // rvalue- ccылкa template<typename T> void f(T&& param); // Не rvalue - ccылкa (универсалоьная ссылка) Усложняет или нет? Ты понял идею того, что описано выше? В C# нет такой проблемы в принципе например. Но там есть ref и out. А еще там ссылочная семантика. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#79
,
|
|
|
KILLER, зачем ты все это написал? Ты понимаешь, что ссылки можно было добавить в язык не добавляя их в систему типов и не делая их частью типов? Мой вопрос об этом.
Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#80
,
|
|
|
Цитата D_KEY @ Ты понимаешь, что ссылки можно было добавить в язык не добавляя их в систему типов и не делая их частью типов? Мой вопрос об этом. Тогда было бы очень громоздко писать программы. Ты рехнулся? Везде писать вместо & - ref? Нет уж, увольте, пусть будет так как есть. Ты видимо не до конца понимаешь концепцию ссылочной семантики и ссылок в С++ или что? Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#81
,
|
|
|
Цитата D_KEY @ И мой вопрос относительно C++ как раз о том, нахрена там ссылка является частью типа? Какую пользу это несёт? Эта "часть типа" показывает компилятору что можно, а что нельзя делать с конкретно этим вариантом типа. Как было продемонстрировано в примерах выше. И это относится не только к передаче аргументов в функцию. Добавлено Цитата D_KEY @ Ты понимаешь, что ссылки можно было добавить в язык не добавляя их в систему типов и не делая их частью типов? Нельзя. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#82
,
|
|
|
Представь есть у тебя тип данных - Любой. Так вот - ты можешь сделать на него указатель, и у тебя получится совершенно другой тип данных, будет Любой*, а ссылка - это просто некий атрибут, с помощью которого, ты говоришь - вот тут я не хочу копировать весь объект, хочу чтоб он вошел внутрь как есть, а вот тут - я буду вообще управлять им с помощью другого идентификатора. Это не тип - это атрибут, или как то так, типа. Это не является типом данных, это всего лишь реально атрибут. Как то так.
Цитата D_KEY @ KILLER, зачем ты все это написал? Это, ты веки подними выше кода )) Там написано зачем я это писал. Я же говорю - вы спорите о двух разных вещах, и так главное все повелись. Вот в С# похоже что ровно тоже самое что и в D, но тем не менее - те недостатки, которые ты описываешь - они там не возникают вообще никак. Я не знаю, может просто я с таким не сталкивался. Возможно, но реально это из области фантастики. Вы спорите о разном просто. Вот и все )) Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#83
,
|
|
|
Цитата Flex Ferrum @ Цитата D_KEY @ Ты понимаешь, что ссылки можно было добавить в язык не добавляя их в систему типов и не делая их частью типов? Нельзя. Почему? Добавлено KILLER, это часть типа в C++. Перечитай свои же цитаты из стандарта и авторитетного для тебя автора. Добавлено Flex Ferrum, в D&E Страуструп пишет, что столкнулся с проблемой добавления перегрузки операторов в язык и для ее устранения ввел ссылки. Если бы вместо добавления ссылок в систему типов он бы добавил ключевые слова(ну или тот же &) для указания способа передачи аргумента в функцию(ну и для возврата), то его проблема была бы решена. Какие негативные последствия такого решения ты видишь? Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#84
,
|
|
|
Цитата D_KEY @ KILLER, это часть типа в C++. Это часть типа в С++? Ок, тогда ты согласен что это не тип данных, о чем тебе Флекс и говорил? Или как? Цитата D_KEY @ Перечитай свои же цитаты из стандарта и авторитетного для тебя автора. Там уже по 5 раз все прочитано, по крайней мере Маерса. Что там написано в стандарте - ты выдрал 5 слов от туда, и поставил смайлик, и чего мне делать на этот весомый аргумент? Я же просил - переведи мне на русский что там написано, я не понимаю же )) Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#85
,
|
|
|
Цитата KILLER @ Это часть типа в С++? Ок, тогда ты согласен что это не тип данных, о чем тебе Флекс и говорил? О чем там говорил Flex я не понял. Он говорил, что ссылка является модификатором типа, но пруфы из стандарта приводить не стал. В стандарте же постоянно ссылки считаются типом во многих местах. Раздел про ссылки ты видел, в разделе о типах так же говорится, что типы описывают и ссылки в том числе. Ссылки в качестве типа встречаются много где... Тип данных? Что ты под этим подразумеваешь? Типы в C++ описывают объекты, функции и ссылки. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#86
,
|
|
|
Сообщ.
#87
,
|
|
|
Цитата Flex Ferrum @ Я скомпилировал в гцц с ключом и запустил. Вывело четыре раза хелловорлд. UB таки есть.В этом коде нет UB. Но есть две ошибки компиляции, вызванные тем, что нельзя брать адрес временного объекта - ни при возврате значения из функции, ни при передаче значения в функцию. Нет. Ссылка будет интерпретироваться как указатель на временный объект в стеке. Добавлено Цитата Qraizer @ Очень аргументированно. Могу привести пример этого самого pointer aliasinga с ссылками, если хочешь. Значит-таки нет. Добавлено Цитата Flex Ferrum @ Так предлагается убрать ссылочный тип. Тогда и компилятору не нужно ничего знать о том, что можно, а чего нельзя делать с несуществующим типом.Эта "часть типа" показывает компилятору что можно, а что нельзя делать с конкретно этим вариантом типа. Как было продемонстрировано в примерах выше. И это относится не только к передаче аргументов в функцию. Цитата Flex Ferrum @ Можно. Что мы потеряем, если внезапно исчезнет ссылочный тип? Нельзя будет создавать переменные-ссылки? Ну и хрен с ними, заменим на указатели. Что еще? Нельзя будет делать странные трюки со ссылками на временные объекты возвращаемые из функции? Ну так это же прекрасно, это только улучшит язык.Нельзя. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#88
,
|
|
|
Цитата applegame @ А ты ещё раз перечитай. Альясинг там приведёт как самый простой и распространённый пример запрета компилятору на агрессивную оптимизацию. Естественно этот пример не единственный, пост начинался-то с общего тезиса. В завершении же поста указано, как ссылки могут помочь восстановить разрешение на агрессивную оптимизацию там, где указатели пасуют. Очень аргументированно. Могу привести пример этого самого pointer aliasinga с ссылками, если хочешь. Добавлено Цитата applegame @ Ухудшит. Указывать на недавние посты в этой теме не буду. Просто возьми и перестань пользоваться ссылками, сам поймёшь, если аргументы не доходят.Что мы потеряем, если внезапно исчезнет ссылочный тип? ... Ну так это же прекрасно, это только улучшит язык. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#89
,
|
|
|
Цитата Qraizer @ Ухудшит. "Улучшит" относилось к исчезновению наличия странной возможности давать ссылки на временные объекты, продлевая их жизнь. Цитата Qraizer @ Просто возьми и перестань пользоваться ссылками, сам поймёшь, если аргументы не доходят. Легко, если появится компилятор С++ с изменениями, которые тут описывались. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |
Сообщ.
#90
,
|
|
|
Цитата Qraizer @ Перечитал еще раз. Я тебя прекрасно понял и у меня создалось впечатление, что ты немного не понимаешь, что такое pointer aliasing.А ты ещё раз перечитай. Ссылки не помогут компилятору избежать косяков с pointer aliasing. Потому что эта проблема вообще ортогональна способу реализации алиасов. И ссылки и указатели - это суть алиасы на некую область памяти. С разной семантикой, но и то и другое - алиасы. Вот ты пишешь: Цитата Qraizer @ С помощью ссылки ты "защищаешь" некое "значение" ссылки (хотя формально "значения" у ссылки нет, но мы сделаем вид, что есть), а проблема-то возникает не со "значением" ссылки, а с объектом на короый она ссылается, а его она защищает не лучше указателя. С тем же успехом ты можешь создать константный указатель, компилятор тоже будет знать, что "единственное место, где т.к. единственное место, где ссылка может поменять своё значение – это точка её инициализации. void foo(int& b) { int* const a = &b; // ничем не лучше чем int& a; } ЕМНИП, стандарт регламентирует поведение компилятора таким образом, что если два алиаса указывают на объекты разных типов, то компилятору разрешается считать, что они не могут ссылаться на одну и ту же область памяти. И совершенно пофиг являются ли эти алиасы ссылками или указателями. Если у тебя есть две ссылки разного типа, но указывающие в одно и тоже место - ничего хорошего не жди: #include <cstdio> int foo(int& x, long& y) { x = 5; y = 10; return x; } int main() { long y = 1; foo(*(int*)y, y); printf("y = %d", y); // ??? } Цитата Qraizer @ Какие посты? То что привел Флекс? В здравом уме и трезвой памяти такой говнокод никто не пустит в серьезный проект.Ухудшит. Указывать на недавние посты в этой теме не буду. Цитата Qraizer @ Я ими уже пару лет как не пользуюсь, с тех пор как перешел на D, потому что там ссылочный тип отсутствует. Просто возьми и перестань пользоваться ссылками, сам поймёшь, если аргументы не доходят. Добавлено Цитата OpenGL @ Как можно жить без таких архиполезных конструкций как:"Улучшит" относилось к исчезновению наличия странной возможности давать ссылки на временные объекты, продлевая их жизнь. const int& a = 10; // WAT??? Добавлено Флексу же предлагаю нашу ветку спора завершить. Думаю мы поняли друг-друга. Во всяком случае я согласен, что программируя на C++ будет правильно считать ссылки некими псевдонимами на объекты, а не особыми разыменованными указателями (даже если для какого-нибудь бэкенда GCC они суть одно и тоже). В таком контексте всякие странности перестают быть странностями. Это сообщение было перенесено сюда или объединено из темы "D vs C++" |