Как вы относитесь к паскалю?
, (есть гипотеза)
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [216.73.216.156] |
|
|
| Страницы: (20) « Первая ... 15 16 [17] 18 19 ... Последняя » все ( Перейти к последнему сообщению ) |
Как вы относитесь к паскалю?
, (есть гипотеза)
|
Сообщ.
#241
,
|
|
|
|
korvin, ты не прав
Указатели отличаются от ссылок не null'ом(ещё раз прошу обратить внимание на scala, где null формально объектом является), а тем, что представляет собой самостоятельный полиморфный тип с определённым набором значений и определённым набором операций. Добавлено И не надо ориентироваться на специфику C++. |
|
Сообщ.
#242
,
|
|
|
|
Цитата D_KEY @ а тем, что представляет собой самостоятельный полиморфный тип с определённым набором значений и определённым набором операций. Да какой полиморфный тип? Простое uint число. =) Цитата D_KEY @ И не надо ориентироваться на специфику C++. Окей, а как насчет var-параметров в Паскале? Или ref-параметров в C#? out-параметров в других языках? Вот это всё ссылки и они не могут быть null. Просто сущности три, а слова всего два. Цитата D_KEY @ ещё раз прошу обратить внимание на scala, где null формально объектом является И что? Что вообще это значит «формально является объектом»? Добавлено Важно то, что объектные типы как и указатели являются типом-суммой с точки зрения типизации. В отличие от «чистых ссылок». Добавлено Одно из исключений, которое я знаю — Ocaml, там нет null-«объекта». Однако и сделать такой «фокус»: ![]() ![]() var x : T; procedure Proc (var x : T); begin x = T.Create('bar'); end; begin x = T.Create('foo'); Proc(x); Println(x); // => bar end. не получится. |
|
Сообщ.
#244
,
|
|
|
|
Цитата D_KEY @ И не надо ориентироваться на специфику C++. Как будто арифметика указателей — меньшая специфика С/С++/Паскаля. =) |
|
Сообщ.
#245
,
|
|
|
|
Нет, неправильно. В Java нет указаталей. В Java есть ссылки. А название исключения говорит о непоследовательности разработчиков. Цитата 1) она не будет отличаться от указателя Будет. Она не будет самостоятельным типом и не будет уметь адресную арифметику. Цитата В плюсах? Никакого. "Вообще" - вполне может быть. "Пустой объект" или что-то в таком духе. С отдельным типом(bottom-тип для ссылочных типов).И какой должен быть логический смысл у NULL-ссылки? Цитата А то, что оператор [] можно перегрузить и таким образом получить обощенный способ доступа по индексу к любому типу коллекций, в т.ч. и связным спискам, которые вообще как попало размещаются в памяти, не считается? Или они взаимозаменяемы? Смогу я по связному списку пройтись с помощью адресной арифметики? Так итераторы же. Цитата Итераторы-то каким образом обобщают указатели? Потому что они и есть обобщенные указатели. У них есть операции для перемещения и операция разыменования. Указатель - частный случай итератора. Добавлено Цитата korvin @ Цитата D_KEY @ а тем, что представляет собой самостоятельный полиморфный тип с определённым набором значений и определённым набором операций. Да какой полиморфный тип? Простое uint число. =) Не обязательно ptr<T> Цитата Окей, а как насчет var-параметров в Паскале? Или ref-параметров в C#? out-параметров в других языках? Вот это всё ссылки и они не могут быть null. Это передача по ссылке. Один из способов передачи. Тип самостоятельный они не образуют, объекты имеют исходный тип. Цитата Что вообще это значит «формально является объектом»? То, что null - это объект класса Null. Обычный объект, а не какое-то специальное значение для обозначения отсутствия объекта. И когда ты пишешь ![]() ![]() var x : SomeType = null; Ты просто ссылаешься на объект null и все. А работает это дело потому, что Null - bottom-тип всех ссылочных типов. Цитата Важно то, что объектные типы как и указатели являются типом-суммой с точки зрения типизации. Совсем не обязательно. null может быть экземпляром bottom-типа. Добавлено Цитата korvin @ Цитата D_KEY @ И не надо ориентироваться на специфику C++. Как будто арифметика указателей — меньшая специфика С/С++/Паскаля. =) Переходим на итераторы и все ок. Хотя категории итераторов фактически прижились только в C++ и D(там правда range'ы), что на мой взгляд странно. |
|
Сообщ.
#246
,
|
|
|
|
Цитата OpenGL @ Тю, та вот:А можно взглянуть на него? ![]() ![]() int *null = 0; int &ref = *null; Так что ссылки на NULL - это безусловно стиль, которого следует избегать всеми силами. Ссылки в целом как раз вводились для того, чтобы избавиться от указателей и связанных с ними неудобствах там, где только это возможно. |
|
Сообщ.
#247
,
|
|
|
|
Цитата Qraizer @ Ссылки в целом как раз вводились для того, чтобы избавиться от указателей и связанных с ними неудобствах там, где только это возможно. Для перегрузки операторов они вводились же вроде. |
|
Сообщ.
#248
,
|
|
|
|
Цитата D_KEY @ Для перегрузки операторов они вводились же вроде. А как связана перегрузка операторов и ссылки? |
|
Сообщ.
#249
,
|
|
|
|
Цитата OpenGL @ Цитата D_KEY @ Для перегрузки операторов они вводились же вроде. А как связана перегрузка операторов и ссылки? Без ссылок нельзя было нормально ввести перегрузку операторов. Указатели не подходят поскольку являются отдельным типом со своими операциями, а писать *a + *b вместо нормального a + b как-то странно. Кстати, жаль, что this ввели раньше ссылок, а то и он был бы ссылкой, а не указателем. |
|
Сообщ.
#250
,
|
|
|
|
Цитата Кстати, жаль, что this ввели раньше ссылок, а то и он был бы ссылкой, а не указателем. Хорошая мысль. Интересно, а чтобы ещё изменилось в С++, если бы его начали писать сейчас с нуля ( без совместимости с С )? |
|
Сообщ.
#251
,
|
|
|
|
Сложно сказать. Возможно, что-то вроде D
|
|
Сообщ.
#252
,
|
|
|
|
Цитата D_KEY @ Это можно было бы обойти и проще. При этом и ссылки не нужны были бы в таком виде. Идея - оттуда, но конечная реализация более богата фичами. Для перегрузки операторов они вводились же вроде. |
|
Сообщ.
#253
,
|
|
|
|
Я говорил о классических Паскалевских цепчках, имея в виду выражения: P^.Next^.Next^.Next^ а вовсе не структуры данных, на примере которых их работа демонстрировались! Классические, потому что современных компиляторах они превращаются в: P.Next.Next.Next И даже объяснил, почему теперь можно опустить знак (^), а также пояснил когда этого делать нельзя. Поэтому меня очень удивил Ваш ответ, цитируемый выше - Похвально, что Вы узнали в приводимом мною примере, на котором я показал применение классических Паскалевских цепочек (для того и привел определение типов, с которыми они в моем примере использовались), чтобы любой с полуслова без лишних объяснений понял, о чем идет речь! А то, что я с их помощью иллюстрировал, судя по Вашей реплике, прошло мимо Вас... На этом примере я показал, что в Паскале многоранговая ссылочность вовсе не экзотика, как утверждал некоторый ваш коллега (подозреваю - Си-шник), и поэтому его "весьма компетентное" мнение о экстравагантности ссылкок-на-ссылки для Паскалей выглядит просто нелепо! Тем более, что постом ранее я поддержал другого нашего коллегу, лишь поправив некоторые досадные неточности в приведенном им примере, а также показал целых три разных класса ситуаций, в которых ссылка на ссылку в Паскале - просто штатная ситуация: это и VAR'ы, и System-ный тип PPChar, свободно наращиваемый по прихоти пользователя, это, наконец, все стандартные Form1.Memo1.Lines..., которыми испещрен простейший текст на Дельфи, (поскольку все объекты есть по сути ссылки) - многоранговые, цепочечные ссылки. Воистину, когда мудрец показывает на звезды, глупец смотрит на палец! (с) И вот в такой ситуации находится эксперт, который положив ногу-на-ногу может сказать ...Ну-уу, для Паскаля это экзотика, а вот в Плюсах... А потом с неподражаемой непосредственностью, хвастается, что вот де, он то знает различие между ссылками и указателями... Не понимая, что необходимости такого знания в их "кривых" языках нужно стыдиться, как рваных носков знаменитого финансиста, ибо в нормальных языках такой необходимости нет! Паскали - они великолепны, не так ли! Как ответил Лапласс Наполеону: — Вы написали такую огромную книгу о системе мира и ни разу не упомянули о его Творце! — Сир, я не нуждался в этой гипотезе. |
|
Сообщ.
#254
,
|
|
|
|
Цитата Qraizer @ Цитата D_KEY @ Это можно было бы обойти и проще. При этом и ссылки не нужны были бы в таком виде.Для перегрузки операторов они вводились же вроде. Ну можно было не делать отдельный тип, если ты об этом, а ограничится способом передачи параметров и возврата значения. Ты об этом? Добавлено Цитата Barklay @ Я говорил о классических Паскалевских цепчках, имея в виду выражения: P^.Next^.Next^.Next^ Но в этом выражении нет указателя на указатель на указатель. Указатель на указатель на указатель это: ![]() ![]() type PPPMyType = ^^^TMyType Не помню, допускается ли такая запись в Pascal'ях. В Си было бы MyType ***. |
|
Сообщ.
#255
,
|
|
|
|
Цитата D_KEY @ Но в этом выражении нет указателя на указатель на указатель. Указатель на указатель на указатель это: type PPPMyType = ^^^TMyType Не помню, допускается ли такая запись в Pascal'ях. В Си было бы MyType ***. Ну во-первых, это: P^.Next^.Next^.Next^, или это: P.Next.Next.Next это именно ссылка-на-ссылку-... Посмотри в дебагере ASM-код ![]() А то - "Но в этом выражении нет указателя на указатель на указатель" - Это может быть в Си - нет, а в Паскале - есть! Самые настоящие! Вот они, ещё раз - "весьма компетентные" суждения сишников о Паскалях! А во-вторых вы "хочете" каких то особых песен, так их уже было для вас у меня, всего пару постов назад: Цитата Barklay @ Особенно доставляет вот эта строчка: Caption := c^^^ - Это я про "экстравагантность ссылок-на-ссылки" и прочие "весьма компетентные" суждения Си-шников о Паскале/Дельфи! ![]() А заглянуть внутрь, в текст программы из этого поста недосуг было? По верхам читаем только?! ![]() Там ведь полный текст программы - но он чуть длинней обреза окна. Зато эти примеры полностью рабочие и потому легко проверяемы. В отличие от теоретических си-шных умствований - как там "В Си было бы бла-бла-бла..." |