Как вы относитесь к паскалю? , (есть гипотеза)

[Qraizer]

Экстравагантно выглядит. Ссылочная семантика - она такая, да. Для сравнения: в Плюсах нет указателей на ссылки и как следствие массивов ссылок, т.к. семантически это неоднозначная конструкция.

[korvin]

Цитата Qraizer @ 20.03.14, 14:59

Экстравагантно выглядит.

Ничего экстравагантного. И это не массив ссылок, а массив указателей.

[D_KEY]

Цитата korvin @ 20.03.14, 15:03

И это не массив ссылок, а массив указателей.

А мне вот тоже кажется, что к ссылкам ближе. Указатели - полноценный самостоятельный тип, со своими значениями и операциями.

[Barklay]

Цитата Добрый кот @ 20.03.14, 13:35

program Hello;

{$APPTYPE CONSOLE}

uses
SysUtils;
type t = class
s: array of t;
end;
var t1: t;
i,j,k: integer;
begin
{ TODO -oUser -cConsole Main : Insert code here }
t1.Create;
end.

Delphi 7. Компилится

В целом согласен с Вами...

Но всё же, академической строгости ради, должен заметить, что
в тексте этой маленькой программы при компиляции - целых три предупреждения:
о том, что i,j,k - лишние, а также - одна принципиальная ошибка:

t1.Create

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

На самом деле должно было быть:

t1 := t.Create

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

program Hello; {$APPTYPE CONSOLE}
type
  t = class
    s : array of t;
  end;
var
  t1 : t;
begin
  t1 := t.Create;
  t1.Free;
end.

Или, если не использовать t1 вообще, то можно было бы отказаться в данном случае и от var-секции:
То есть использовать анонимный объект!

program Hello; {$APPTYPE CONSOLE}
 
type
  t = class
    s : array of t;
  end;
 
begin
  with t.Create do try
    //...
  finally
    Free
  end
end.

Но в целом, повторю, с учетом исправления приведенных неточностей и ошибок - идеологически правильный пример!

Более того, добавлю от себя, что все объявления передаваемых переменных ссылочных типов в заголовке функции/процедуры, через VAR/CONST/OUT-параметры,
таких, например, как PChar, PInteger и т.д. (или таких, как объекты, которые по факту - также указатели), есть по определению ссылки-на-сылку, например:

procedure TForm1.Button3Click(Sender: TObject);
  procedure Foo(var v : PChar);
  begin // здесь V передается как ссылка на ссылку, к которой прибавляется 3 - великолепный пример адресной арифметики в Паскале!
    if (v+3)^ <> 'D'       // - если 4-ая буква в слове (третья начиная с нуля, на которую указывает p^) не равна 'D'  
      then Caption := v    // - вывести всё слово
      else Caption := v+3  // - вывести остаток строки, начиная с этой буквы
  end;
var
  p : PChar;
begin
  p := 'ABCDEF';
  Foo(p)
end;

Я уж не говорю про классические Паскалевские цепочки неопределённой длины (указатель-на-указатель-...-на указатель):

type
  PMy = ^TMy;
  TMy = record
          Num : integer;
          Next : PMy
        end;
var
  p : PMy;
...

И далее, после соответствующих инициализаций допустимо:

P^.Next^
P^.Next^.Next^
P^.Next^.Next^.Next^ и т.д.

или, опуская символ (^):

P.Next.Next.Next

что допускается современным синтаксисом при соблюдения условия однозначности трактования ситуации компилятором.
И введено это правило для классов (вместо объектов), но распространяется на прочие указатели.

Кстати, именно поэтому в примере выше - там где речь идет о (v+3)/(v+3)^ - опускать этот символ (^) нельзя!

Потому что:

(v+3)^ - это сам 4-ый символ
(v+3)  - это остаток строки, начиная с этого 4-го символа

Так что замечание об экстравагантности ссылок-на-ссылки, по крайней мере для Паскалей - это скорее всего взгляд с "другого берега", приверженцев другого языка...

Сообщение отредактировано: Barklay - 22.03.14, 14:13

[Barklay]

Ну и так, вдогонку, хохмы ради (Холивар у нас, в конце концов, или где!):

procedure TForm1.Button1Click(Sender: TObject);
var
  a : PChar;
  b : PPChar; // - стандартный, между прочим, тип, определенный в модуле System
  c :^PPChar;
begin
  a := 'ABCDEF';
  b := @a;
  c := @b;
 
  Caption := b^;
  Caption := b^+2;
  Caption := b^^;
 
  Caption := c^^;
  Caption := c^^+2;
  Caption := c^^^;
end;

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

[korvin]

Цитата D_KEY @ 20.03.14, 15:11

А мне вот тоже кажется, что к ссылкам ближе.

Креститься надо, когда кажется. =)

data Ptr a = Ptr a | Nil
data Ref a = Ref a

var x : TObject;
x := nil;

Ок?

Добавлено 24.03.14, 03:18

Цитата Barklay @ 22.03.14, 00:57

Я уж не говорю про классические Паскалевские цепочки неопределённой длины (указатель-на-указатель-...-на указатель):

Они не паскалевские. Это стандартная реализация односвязного списка.

[D_KEY]

Цитата korvin @ 24.03.14, 03:15

Цитата D_KEY @ 20.03.14, 15:11

А мне вот тоже кажется, что к ссылкам ближе.

Креститься надо, когда кажется. =)

data Ptr a = Ptr a | Nil
data Ref a = Ref a

var x : TObject;
x := nil;

Ок?

Нет, не ок. nil/null не основное отличие ссылок от указателей(хотя в C++ оно существенно). В той же scala, например, null просто является экземпляром bottom-типа ссылочных типов - Null Основная разница между ссылками и указателями заключается в том, что указатели представляют собой самостоятельный полиморфный тип, со своими значениями(адреса) и операциями(адресная арифметика, разыменование).

[Qraizer]

Цитата Barklay @ 24.03.14, 01:05

- Это я про "экстравагантность ссылок-на-ссылки" и прочие "весьма компетентные" суждения Си-шников о Паскале/Дельфи!

А вот не надо путать ссылки и указатели. Компетентные Си-шники в курсе разницы. В отличие от компетентных в Паскале/Дельфи, как они это уже много раз демонстрировали.

[korvin]

Цитата D_KEY @ 24.03.14, 04:35

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

Это языко-специфичное отличие. В "типобезопасных" языках никакой адресной арифметики нет и быть не может, а разыменовывание выполняется автоматически (что может привести к NullPointerException например). Так что, имхо, если имеет смысл различать эти понятия, то только с позиции типизации. Как, например, в C++ и Kotlin.

[D_KEY]

Цитата korvin @ 24.03.14, 05:41

В "типобезопасных" языках никакой адресной арифметики нет и быть не может, а разыменовывание выполняется автоматически

Поэтому там ссылки, а указателей нет.

Добавлено 24.03.14, 05:56

Цитата korvin @ 24.03.14, 05:41

В "типобезопасных" языках никакой адресной арифметики нет и быть не может

Чем принципиально адресная арифметика отличается от индексации? Если нужно проверять валидность индекса, то можно проверять и выход указателя за диапазон выделенного под массив блока.

Добавлено 24.03.14, 06:06

Цитата korvin @ 24.03.14, 05:41

Так что, имхо, если имеет смысл различать эти понятия, то только с позиции типизации.

Ну вот что, например, означает ссылка на ссылку и имеет ли она смысл? Для указателей указатель на указатель на указатель - вполне нормальное дело

[korvin]

Цитата D_KEY @ 24.03.14, 05:51

Поэтому там ссылки, а указателей нет.

Если бы они были non-nullable, были бы ссылками и никаких NullPointerException не возникало бы в принципе.

Цитата D_KEY @ 24.03.14, 05:51

Чем принципиально адресная арифметика отличается от индексации?

Тем что в ряде языков адресами управляет GC, да и без него обращение к произвольнольному адресу что по-твоему должно означать?

Цитата D_KEY @ 24.03.14, 05:51

Чем принципиально адресная арифметика отличается от индексации? Если нужно проверять валидность индекса, то можно проверять и выход указателя за диапазон выделенного под массив блока.

Ну и зачем тогда эта самая адресная арифметика, если уже есть индексация?

Цитата D_KEY @ 24.03.14, 05:51

Ну вот что, например, означает ссылка на ссылку

Она означает ссылку. Как сумма нулей, как произведение единиц.

Цитата D_KEY @ 24.03.14, 05:51

и имеет ли она смысл?

Практический — нет. И в приведенном делфийском коде нет ссылок.

Сообщение отредактировано: korvin - 24.03.14, 14:42

[D_KEY]

Цитата korvin @ 24.03.14, 14:41

Цитата D_KEY @ 24.03.14, 05:51

Поэтому там ссылки, а указателей нет.

Если бы они были non-nullable, были бы ссылками

Ты сейчас говоришь, что в той же Java есть указатели? Правильно я тебя понял?

И ты так и не ответил на аргументы мои относительно null. С чего ты взял, что ссылка не может быть null'ом?

Добавлено 24.03.14, 15:25

Цитата korvin @ 24.03.14, 14:41

Ну и зачем тогда эта самая адресная арифметика, если уже есть индексация?

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

Сообщение отредактировано: D_KEY - 24.03.14, 15:27

[korvin]

Цитата D_KEY @ 24.03.14, 15:21

Ты сейчас говоришь, что в той же Java есть указатели? Правильно я тебя понял?

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

Цитата D_KEY @ 24.03.14, 15:21

И ты так и не ответил на аргументы мои относительно null. С чего ты взял, что ссылка не может быть null'ом?

Ты не задавал этого вопроса. Потому что тогда: 1) она не будет отличаться от указателя, 2) ее придется правильно разыменовывать (ну или точнее проверять адрес), и 3) никакой неоднозначности:

Цитата Qraizer @ 20.03.14, 14:59

в Плюсах нет указателей на ссылки и как следствие массивов ссылок, т.к. семантически это неоднозначная конструкция.

не будет.

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

Цитата D_KEY @ 24.03.14, 15:21

Потому, что она является более общей концепцией

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

Добавлено 24.03.14, 15:46

Цитата D_KEY @ 24.03.14, 15:21

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

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

Добавлено 24.03.14, 15:53

Цитата korvin @ 24.03.14, 15:44

Цитата D_KEY @ 24.03.14, 15:21

Ты сейчас говоришь, что в той же Java есть указатели? Правильно я тебя понял?

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

Единственное, на что я могу согласиться (в качестве компромиса =)), так это, что 1) указатели в C, 2) ссылки в C++ и Паскале (которые var, const) и 3) объекты в Java, Delphi, etc — это три разных механизма. 3–й занимает промежуточное место между 1–м и 2–м.

Добавлено 24.03.14, 15:54
http://programmers.stackexchange.com/quest...rom-a-c-pointer

Сообщение отредактировано: korvin - 24.03.14, 15:54

[Qraizer]

Цитата korvin @ 24.03.14, 15:44

...Потому что тогда: 1) она не будет отличаться от указателя, 2) ее придется правильно разыменовывать (ну или точнее проверять адрес), и 3) никакой неоднозначности:

Цитата Qraizer @ 20.03.14, 14:59

в Плюсах нет указателей на ссылки и как следствие массивов ссылок, т.к. семантически это неоднозначная конструкция.

не будет.

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

int  x;
 
int& y1 = x;
int&&y2 = y1; // предположим; на самом деле такого синтаксиса в языке нет.

На что ссылается y2? На y1 или x? Если первое, то y2, являясь псевдонимом y1, даёт доступ к значению y1, что противоречит основополагающему свойству ссылок. Если второе, то зачем сия конструкция, если она полностью аналогична обычной ссылке?

Цитата korvin @ 24.03.14, 15:44

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

Приводил. Но как пример дерьмостайла.

[korvin]

Цитата Qraizer @ 24.03.14, 16:27

На что ссылается y2? На y1 или x? Если первое, то y2, являясь псевдонимом y1, даёт доступ к значению y1, что противоречит основополагающему свойству ссылок. Если второе, то зачем сия конструкция, если она полностью аналогична обычной ссылке?

Второе, я ж написал.

Цитата Qraizer @ 24.03.14, 16:27

Но как пример дерьмостайла.

Это да, просто вдруг D_KEY будет настаивать именно на технической, принципиальной возможности. =)