Их там и нет по сути, leo. Сам посуди, куда их приткнуть-то? Только в интерфейсы с внешним миром. Всё остальное, окромя исходноидейных динамических структур данных, обходится без них

1 Standard conversions are implicit conversions defined for built-in types. Clause 4 enumerates the full set of such conversions. A standard conversion sequence is a sequence of standard conversions in the following order:

• Zero or one conversion from the following set: lvalue-to-rvalue conversion, array-to-pointer conversion, and function-to-pointer conversion.
• Zero or one conversion from the following set: integral promotions, floating point promotion, integral conversions, floating point conversions, floating-integral conversions, pointer conversions, pointer to member conversions, and boolean conversions.
• Zero or one qualification conversion.

[ Note: a standard conversion sequence can be empty, i.e., it can consist of no conversions. —end note ]
A standard conversion sequence will be applied to an expression if necessary to convert it to a required destination type.
2 [ Note: expressions with a given type will be implicitly converted to other types in several contexts:

• When used as operands of operators. The operator’s requirements for its operands dictate the destination type (Clause 5).
• ...

D_KEY, не надо смотреть... там явный коммент есть

и преобразование к указателю здесь ни при чём.

В этой теме Qraizer говорил именно об этом.

А вот второе... как минимум непонятно.

так лучше бы и синтаксиса не было

Ну согласись, пи***ц же:

Ага, нет.

В чем по твоему отличие стат массивов в дельфе от сишных ? Я что то вообще отличий не вижу.

Это с точки зрения типизации сишной. Так с ее точки зрения в Си вообще нет динамических массивов.

Ну, в таком случае не будет, потому что у нас не массив, а указатель.

Массив, размер которого задается/меняется в рантайме?

Смотря какое определение у "динамического массива".

Я знаю. Так припудрен-то чем? new[] и delete[]?

Ну, нет в плюсах такого встроенного типа - динамический массив. Только указатель и дополнительные действия вокруг операторов new[] и delete[].

Чем это он припудрен?

А вот в плюсах дин. массив - это не тип, а хз что. Припудренный указатель, не больше.

Получается, что статические массивы и динамический массивы - в Си/Плюсах это совершенно разные типы данных, и переменные этих типов определяются совершенно разным образом

Если из паскаля убрать указатели и все, что с ними связано,...

Object'а в виртовском паскале не было же.

Поэтому идеологически указатели Паскалю чужды, и Борландцы всеми правдами и неправдами пытались не допускать их широкое пользование, везде, где только можно, предлагая вместо них их заменители

Экстравагантность заключается в неявности того, что массив хранит

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

:D
Barklay, мало того, что ты вообще не осилил исходного поста,

Но в этом выражении нет указателя на указатель на указатель.
Указатель на указатель на указатель это:

type PPPMyType = ^^^TMyType

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

Это можно было бы обойти и проще. При этом и ссылки не нужны были бы в таком виде.

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

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

Кстати, жаль, что this ввели раньше ссылок, а то и он был бы ссылкой, а не указателем.

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

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

Ссылки в целом как раз вводились для того, чтобы избавиться от указателей и связанных с ними неудобствах там, где только это возможно.

А можно взглянуть на него?

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

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

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

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

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

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

не будет.

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

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

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

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

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

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

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



Ок?

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

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. Компилится :lol:

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

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

В СиПлюсах ничего необычного, для Дельфей - экстравагантно, но допустимо.

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

Да, но указатель должен как-то называться, поэтому надо писать C**myC

Если С - какой-то класс, то С** - указатель на указатель на С :)