На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Модераторы: ANDLL, ALXR
Страницы: (20) « Первая ... 15 16 [17] 18 19 ... Последняя » все  ( Перейти к последнему сообщению )  
> Как вы относитесь к паскалю? , (есть гипотеза)
   
Как вы относитесь к паскалю?
Гости не могут просматривать результаты голосования.
Гости не могут голосовать 
    korvin, ты не прав :D Указатели отличаются от ссылок не null'ом(ещё раз прошу обратить внимание на scala, где null формально объектом является), а тем, что представляет собой самостоятельный полиморфный тип с определённым набором значений и определённым набором операций.

    Добавлено
    И не надо ориентироваться на специфику C++.
      Цитата D_KEY @
      а тем, что представляет собой самостоятельный полиморфный тип с определённым набором значений и определённым набором операций.

      Да какой полиморфный тип? Простое uint число. =)

      Цитата D_KEY @
      И не надо ориентироваться на специфику C++.

      Окей, а как насчет var-параметров в Паскале? Или ref-параметров в C#? out-параметров в других языках? Вот это всё ссылки и они не могут быть null. Просто сущности три, а слова всего два.

      Цитата D_KEY @
      ещё раз прошу обратить внимание на scala, где null формально объектом является

      И что? Что вообще это значит «формально является объектом»?

      Добавлено
      Важно то, что объектные типы как и указатели являются типом-суммой с точки зрения типизации. В отличие от «чистых ссылок».

      Добавлено
      Одно из исключений, которое я знаю — Ocaml, там нет null-«объекта». Однако и сделать такой «фокус»:
      ExpandedWrap disabled
        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.

      не получится.
      Сообщение отредактировано: korvin -
        Цитата Qraizer @
        Приводил. Но как пример дерьмостайла.

        А можно взглянуть на него? :)
          Цитата D_KEY @
          И не надо ориентироваться на специфику C++.

          Как будто арифметика указателей — меньшая специфика С/С++/Паскаля. =)
          Сообщение отредактировано: korvin -
            Цитата korvin @
            Цитата D_KEY @
            Ты сейчас говоришь, что в той же Java есть указатели? Правильно я тебя понял?

            Угу, правильно. Даже название исключения на это намекает.

            Нет, неправильно. В Java нет указаталей. В Java есть ссылки. А название исключения говорит о непоследовательности разработчиков.

            Цитата
            1) она не будет отличаться от указателя

            Будет. Она не будет самостоятельным типом и не будет уметь адресную арифметику.

            Цитата
            И какой должен быть логический смысл у NULL-ссылки?
            В плюсах? Никакого. "Вообще" - вполне может быть. "Пустой объект" или что-то в таком духе. С отдельным типом(bottom-тип для ссылочных типов).

            Цитата
            А то, что оператор [] можно перегрузить и таким образом получить обощенный способ доступа по индексу к любому типу коллекций, в т.ч. и связным спискам, которые вообще как попало размещаются в памяти, не считается? Или они взаимозаменяемы? Смогу я по связному списку пройтись с помощью адресной арифметики?

            Так итераторы же.

            Цитата
            Цитата D_KEY @
            итареторов, которые, в свою очередь, фактически обобщают понятие указателя.

            Итераторы-то каким образом обобщают указатели?

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

            Добавлено
            Цитата korvin @
            Цитата D_KEY @
            а тем, что представляет собой самостоятельный полиморфный тип с определённым набором значений и определённым набором операций.

            Да какой полиморфный тип? Простое uint число. =)

            Не обязательно ptr<T> :)

            Цитата
            Окей, а как насчет var-параметров в Паскале? Или ref-параметров в C#? out-параметров в других языках? Вот это всё ссылки и они не могут быть null.

            Это передача по ссылке. Один из способов передачи. Тип самостоятельный они не образуют, объекты имеют исходный тип.

            Цитата
            Что вообще это значит «формально является объектом»?

            То, что null - это объект класса Null. Обычный объект, а не какое-то специальное значение для обозначения отсутствия объекта.
            И когда ты пишешь
            ExpandedWrap disabled
              var x : SomeType = null;

            Ты просто ссылаешься на объект null и все. А работает это дело потому, что Null - bottom-тип всех ссылочных типов.

            Цитата
            Важно то, что объектные типы как и указатели являются типом-суммой с точки зрения типизации.

            Совсем не обязательно. null может быть экземпляром bottom-типа.

            Добавлено
            Цитата korvin @
            Цитата D_KEY @
            И не надо ориентироваться на специфику C++.

            Как будто арифметика указателей — меньшая специфика С/С++/Паскаля. =)

            Переходим на итераторы и все ок. Хотя категории итераторов фактически прижились только в C++ и D(там правда range'ы), что на мой взгляд странно.
            Сообщение отредактировано: D_KEY -
              Цитата OpenGL @
              А можно взглянуть на него?
              Тю, та вот:
              ExpandedWrap disabled
                int *null = 0;
                int &ref = *null;
              По Стандарту разыменование NULL-поинтера допустимо, но недопустимо использование результата сего действа, ибо попадает под неопределённое поведение. Тут результат как таковой не используется, т.к. в точке определения ссылки и естественно её инициализации подссыльный объект не требуется. Но он безусловно будет нужен при любом (в отличие от указателя) использовании ссылки, и нет простых способов проверить валидность ссылки, кроме банального и уродливого подобия if (!&ref).
              Так что ссылки на NULL - это безусловно стиль, которого следует избегать всеми силами. Ссылки в целом как раз вводились для того, чтобы избавиться от указателей и связанных с ними неудобствах там, где только это возможно.
                Цитата Qraizer @
                Ссылки в целом как раз вводились для того, чтобы избавиться от указателей и связанных с ними неудобствах там, где только это возможно.

                Для перегрузки операторов они вводились же вроде.
                  Цитата D_KEY @
                  Для перегрузки операторов они вводились же вроде.

                  А как связана перегрузка операторов и ссылки?
                    Цитата OpenGL @
                    Цитата D_KEY @
                    Для перегрузки операторов они вводились же вроде.

                    А как связана перегрузка операторов и ссылки?

                    Без ссылок нельзя было нормально ввести перегрузку операторов. Указатели не подходят поскольку являются отдельным типом со своими операциями, а писать *a + *b вместо нормального a + b как-то странно.
                    Кстати, жаль, что this ввели раньше ссылок, а то и он был бы ссылкой, а не указателем.
                      Цитата
                      Кстати, жаль, что this ввели раньше ссылок, а то и он был бы ссылкой, а не указателем.

                      Хорошая мысль. Интересно, а чтобы ещё изменилось в С++, если бы его начали писать сейчас с нуля ( без совместимости с С )?
                        Сложно сказать. Возможно, что-то вроде D :)
                          Цитата D_KEY @
                          Для перегрузки операторов они вводились же вроде.
                          Это можно было бы обойти и проще. При этом и ссылки не нужны были бы в таком виде. Идея - оттуда, но конечная реализация более богата фичами.
                            Цитата korvin @
                            Они не паскалевские. Это стандартная реализация односвязного списка.

                            Я говорил о классических Паскалевских цепчках, имея в виду выражения:

                            P^.Next^.Next^.Next^

                            а вовсе не структуры данных, на примере которых их работа демонстрировались!
                            Классические, потому что современных компиляторах они превращаются в:

                            P.Next.Next.Next

                            И даже объяснил, почему теперь можно опустить знак (^), а также пояснил когда этого делать нельзя.

                            Поэтому меня очень удивил Ваш ответ, цитируемый выше - Похвально, что Вы узнали в приводимом мною примере,
                            на котором я показал применение классических Паскалевских цепочек (для того и привел определение типов,
                            с которыми они в моем примере использовались), чтобы любой с полуслова без лишних объяснений понял,
                            о чем идет речь!

                            А то, что я с их помощью иллюстрировал, судя по Вашей реплике, прошло мимо Вас...

                            На этом примере я показал, что в Паскале многоранговая ссылочность вовсе не экзотика,
                            как утверждал некоторый ваш коллега (подозреваю - Си-шник), и поэтому его "весьма компетентное"
                            мнение о экстравагантности ссылкок-на-ссылки для Паскалей выглядит просто нелепо!

                            Тем более, что постом ранее я поддержал другого нашего коллегу, лишь поправив некоторые досадные
                            неточности в приведенном им примере, а также показал целых три разных класса ситуаций, в которых
                            ссылка на ссылку в Паскале - просто штатная ситуация: это и VAR'ы, и System-ный тип PPChar, свободно
                            наращиваемый по прихоти пользователя, это, наконец, все стандартные Form1.Memo1.Lines..., которыми
                            испещрен простейший текст на Дельфи, (поскольку все объекты есть по сути ссылки) - многоранговые,
                            цепочечные ссылки.

                            Воистину, когда мудрец показывает на звезды, глупец смотрит на палец! (с)

                            И вот в такой ситуации находится эксперт, который положив ногу-на-ногу может сказать

                            ...Ну-уу, для Паскаля это экзотика, а вот в Плюсах...

                            А потом с неподражаемой непосредственностью, хвастается, что вот де, он то знает различие между ссылками и указателями...
                            Не понимая, что необходимости такого знания в их "кривых" языках нужно стыдиться, как рваных носков знаменитого финансиста,
                            ибо в нормальных языках такой необходимости нет! Паскали - они великолепны, не так ли!

                            Как ответил Лапласс Наполеону:
                            — Вы написали такую огромную книгу о системе мира и ни разу не упомянули о его Творце!
                            — Сир, я не нуждался в этой гипотезе.
                              Цитата Qraizer @
                              Цитата D_KEY @
                              Для перегрузки операторов они вводились же вроде.
                              Это можно было бы обойти и проще. При этом и ссылки не нужны были бы в таком виде.

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

                              Добавлено
                              Цитата Barklay @
                              Цитата korvin @
                              Они не паскалевские. Это стандартная реализация односвязного списка.

                              Я говорил о классических Паскалевских цепчках, имея в виду выражения:

                              P^.Next^.Next^.Next^

                              Но в этом выражении нет указателя на указатель на указатель.
                              Указатель на указатель на указатель это:
                              ExpandedWrap disabled
                                type PPPMyType = ^^^TMyType

                              Не помню, допускается ли такая запись в Pascal'ях.
                              В Си было бы MyType ***.
                                Цитата D_KEY @
                                Но в этом выражении нет указателя на указатель на указатель.
                                Указатель на указатель на указатель это:

                                type PPPMyType = ^^^TMyType

                                Не помню, допускается ли такая запись в Pascal'ях.
                                В Си было бы MyType ***.


                                Ну во-первых, это: P^.Next^.Next^.Next^, или это: P.Next.Next.Next

                                это именно ссылка-на-ссылку-... Посмотри в дебагере ASM-код :lool:

                                А то - "Но в этом выражении нет указателя на указатель на указатель" - Это может быть в Си - нет, а в Паскале - есть! Самые настоящие!
                                Вот они, ещё раз - "весьма компетентные" суждения сишников о Паскалях!

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

                                Цитата Barklay @
                                Особенно доставляет вот эта строчка: :dance:
                                Caption := c^^^
                                - Это я про "экстравагантность ссылок-на-ссылки" и прочие "весьма компетентные" суждения Си-шников о Паскале/Дельфи! :lool:

                                А заглянуть внутрь, в текст программы из этого поста недосуг было? По верхам читаем только?! :D

                                Там ведь полный текст программы - но он чуть длинней обреза окна.
                                Зато эти примеры полностью рабочие и потому легко проверяемы.
                                В отличие от теоретических си-шных умствований - как там "В Си было бы бла-бла-бла..."
                                Сообщение отредактировано: Barklay -
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:


                                Рейтинг@Mail.ru
                                [ Script execution time: 0.1498 ]   [ 19 queries used ]   [ Generated: 27.07.26, 10:05 GMT ]