смогу ли я быть программистом

← →
vpbar © (2007-10-25 22:27) [80]

Попробую пояснить, что имел ввиду.
Во первых в языке нужно не смешивать ссылки и указатели.
Ссылка - ссылается на объект определенного типа или никуда не ссылается (равна nil). Ссылке можно присвоить nil или ссылку на объект совметимого типа. Проверить на равенство с nil или с другой ссылкой. Ее можно разименовать, т.е. указать что мы хотим работать не ссылкой, а с объектом на который она ссылается. И все. Т.е. ссылка нужно для того чтобы ссылаться на объект из разных мест.
Указатель - это адрес блока в памяти. Это низкоуровневая конструкция. Ее можно складывать сравнивать с другими указателями и приводить к ссылке определенного типа.
Так вот в делфи переменная типа объект (TObject) это по сути ссылка. Переменная типа Pointer of Type - это тоже ссылка. Но работа с ними не логична потому что в одном случае подразумевается объект на который указывает ссылка (a:TObject; a.Field:=10) а в другое сама ссылка (a,b:TObject; a:=b;);
Конечно в случае с оператором "." можно считать что слева должен быть указатель на структуру. И это как бы сокращение от a^.Field
Но в случае с динамическим массивом (arr1,arr2) arr1[1] // arr1- массив
arr1:=arr2 //arr1 - ссылка.
Ссылке можно свободно присвоить указатель, хотя при этом теряется типобезопастность, но этого не видно.
p:pointer; o:Tobject; ... o:=p; // надо помнить что такое p //Логичнее приведение типа o:=TObject(p);
Т.е. нужно постоянно помнить что ссылка это ссылка. Хотя обычно это не важно - а важно то на что она ссылается.
Поэтому я считаю, то обязательное указание на то что мы используем ссылку как ссылку, а не как объект - логично и наглядно.
Например
arr1:=arr2 // присваиваем массивы
arr1@:=arr2@ // присваиваем ссылки.

ЗЫ. В принципе можно запомнить, что в некоторых случаях (например, присваивание) имеется ввиду ссылка, а в других (например, обращение к полям, элементам) объект. Но мне кажется это не логичным.

По-поводу C++
Если объект на стеке то обращается к полям через "." а если на куче то "->". Но обычно где он - это не важно и не зачем это так выделять. Т.е. имхо еще не логичнее.

← →
vpbar © (2007-10-25 22:29) [81]

>>@!!ex © (25.10.07 22:05) [78]
>>в дельфи еще и ^. есть, это полный аналог -> или я чего то не учитываю?
О нет! Совсем не полный. У си тут своя логика. Особенно когда -> перегружен.

← →
@!!ex © (2007-10-25 22:37) [82]

> [81] vpbar © (25.10.07 22:29)

ну так и + в дельфи не равен + в С, особенно если + перегружен. ;)

> [79] Ins © (25.10.07 22:07)

Например, указатель на объект.
Form:^TForm;
при том что Form - это указатель на ссылку, мы все равно можем работать с ним как с непосредственно объектом. Это не логично. ИМХО опять же.

← →
Ins © (2007-10-25 22:42) [83]

> Во первых в языке нужно не смешивать ссылки и указатели.

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

> Ее можно складывать сравнивать с другими указателями

Опять таки, считаю, что арифметика указателей не должна быть в строготипизированном языке. Указатель - это указатель, манипуляции, которые позволяют его изменить, потенциально могут привести к его невалидности. Хотя в Delphi пошли на некоторые уступки, в частности для типизированных указателей можно использовать Inc, Dec, а к PChar-у и вовсе можно целое прибавлять и отнимать без проблем.

← →
vpbar © (2007-10-25 22:54) [84]

>>Ins © (25.10.07 22:42) [83]
А по мне не лишне. Ибо p:Pointer и O:Tobject; (или ppt:PPoint) это разные весчи. И что допуситимо с указателем (p1>p2; inc(p)) не имеет смысла с сылкой. Кроме того ссылка имеет определенный тип а указатель нет.

Поэтому O:=P - это грубое нарушение. Почему тогда нельзя O:=ppt ?
>>Опять таки, считаю, что арифметика указателей не должна быть в строготипизированном языке
Вот именно указатель это очень низкоуровневая конструкция в отличии от ссылки.

← →
Ins © (2007-10-25 22:56) [85]

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

← →
hirabayashi (2007-10-25 22:58) [86]

Ins © (25.10.07 22:56) [85]

Но это все фигня, после того как ты постиг дзен.

← →
vpbar © (2007-10-25 22:59) [87]

>>hirabayashi (25.10.07 22:58) [86]
Да уж. Ничего нет, кроме последовательности байт. Остальное иллюзия.

← →
Ins © (2007-10-25 23:01) [88]

> Вот именно указатель это очень низкоуровневая конструкция
> в отличии от ссылки.

Вы указатель приравняли к целому, что недопустимо в строготипизированном языке. Точно также, как и приравнивать к целому логический, перечислимый и прочие типы. Приравнивая все это к целому, мы спускаемся с "человеческого" уровня абстракции на "машинный". Да еще и смешиваем их. Вся прелесть теряется. То, о чем я сказал в [85] вам не дано понять, что ж, жаль, Delphi язык не для вас.

← →
@!!ex © (2007-10-25 23:05) [89]

Дельфи - далеко не строго типизированный язык.
написав пару шейдеров на GLSL - начинаешь понимать это.

← →
vpbar © (2007-10-25 23:08) [90]

Ins © (25.10.07 23:01) [88]
Гы. Не судите, да не судимы будите.
Delphi строго типизированный язык?
тогда почему прокатывает это

var p:Pointer; O:TObject; c:Pchar; begin c:="hello"; inc(c); c^:="2"; // Последствия знаете, знаток делфи? p:=0; // указателю и целое (0 - это ведь целочисленный литерал) присвоили O:=p; // и все без явного приведения типа. end;

← →
Ins © (2007-10-25 23:22) [91]

> Последствия знаете, знаток делфи?

Во-первых, воздержись от наездов. Во-вторых, где здесь нарушение строгой типизации? PChar это кроме всего прочего и ^Char, только если хочешь его потом использовать и как указатель на нультерминальную строку, о том самом терминаторе позаботься. Типизация тут нипричем. Вот я реально один косячек Борланда знаю с PChar, если интересно - могу показать.

> p:=0; // указателю и целое (0 - это ведь целочисленный литерал)
> присвоили

Варнинг получите. А вот другое целое, кроме как 0, не присвоишь.

> O:=p;

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

← →
Ins © (2007-10-25 23:28) [92]

> Последствия знаете, знаток делфи?

Или тут имелось в виду AV, которое возникает при выполнении этих трех строк. Если да, опять таки, дело не в типизации. Просто память, на которую ссылается c располагается в защищенном от записи сегменте кода. Где строковой константе и место.

← →
vpbar © (2007-10-25 23:29) [93]

>>Во-первых, воздержись от наездов.
Это вопрос, а не наезд. Ели это наезд, то в таком случае это тем более "То, о чем я сказал в [85] вам не дано понять, что ж, жаль, Delphi язык не для вас."
>>Во-вторых, где здесь нарушение строгой типизации?
Ну хорошо. То что не надо PChar разименовывать, что бы присвоить ему символ Вы не считаете нарушением типизации. Но ошибка там будет из-за другого нарушения типизации. По сути тут "c" - это ссылка на константу и менять ее нельзя.

>>Варнинг получите. А вот другое целое, кроме как 0, не присвоишь.
Слишком много тонкостей чтобы оправдать это.
>>Если честно, я бы тоже запретил подобные присваивания, но Borland так сделали вероятно по известным только им причинам.
Не виду причин. Наверно просто ошибка при построении языка или компилятора.

← →
vpbar © (2007-10-25 23:31) [94]

>>Ins © (25.10.07 23:28) [92]
Эх. Все таки, видимо, у нас разные взгляды на типизацию. Что ж не буду вас переубеждать. Да и сам останусь при своем мнении (оно у меня весьма обосновано), пока не увижу реальных аргуменов не в его пользу.

← →
Ins © (2007-10-25 23:34) [95]

> То что не надо PChar разименовывать, что бы присвоить ему
> символ Вы не считаете нарушением типизации.

Хе-хе. Вы и правда думаете, что
var
c: PChar;
begin
c:="2"; /*
c^:="2"; /**
end;
* и ** - это одно и то же? :)

> Слишком много тонкостей чтобы оправдать это.

Нет никаких тонкостей, это скорее уступка, намекающая, что 0 то я тебе позволю присвоить указателю, но только его и не забывай, что Pointer и Integer - это не одно и то же.

← →
vpbar © (2007-10-25 23:37) [96]

Ins © (25.10.07 23:34) [95]
Не одно конечно. В первом случае "2" -это строка а во втором "2" -это символ.
Еще одна ненужная тонкость.

← →
vpbar © (2007-10-25 23:38) [97]

>>Ins © (25.10.07 23:34) [95]
>>не забывай, что Pointer и Integer - это не одно и то же.
Я нигде не говорил этого. Наоборот, всячески разграничивал указатели от других типов.

← →
Ins © (2007-10-25 23:42) [98]

> Еще одна ненужная тонкость.

Просто не нужно думать, что PChar - это ^Char. Это не так. PChar - это особый встроенный в компилятор тип. Цель этих особенностей - облегчить работу со строками. А насчет строгой типизации, просто не нужно забывать, что есть как совместимые типы, так и несовместимые. Паскаль допускает совместимость типов, но только тех, которые должны быть совместимы, а не так как в C++, целое оно же логическое оно же указатель.

← →
Ins © (2007-10-25 23:47) [99]

> Наоборот, всячески разграничивал указатели от других типов.

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

← →
vpbar © (2007-10-25 23:48) [100]

>>Ins © (25.10.07 23:42) [98]
> Еще одна ненужная тонкость.
В [96] я о том что "Х" - это и строка и символ.
Хотя можно считать ее всегда символом - логичнее будет.

По-поводу совместимости типов в Делфи спроить не буду с этим получше чем в Си, но тоже не идеал.

← →
vpbar © (2007-10-25 23:52) [101]

>>Ins © (25.10.07 23:47) [99]
>>Правильно, только понятие указателя несколько расширить нужно
Нафик. Лучше я буду разделять указатели и ссылки.

ЗЫ У меня такое ощущение, что вы пытаетесь меня учить, при том что знаете не больше меня. Не стоит. Если я забуду какуюто Делфийскую тонкость всегда могу нажать Ctrl+Shift+C
А в области теорий ваши учения мне не импонируют.

← →
Ins © (2007-10-25 23:53) [102]

> Хотя можно считать ее всегда символом - логичнее будет.

А как тогда присвоить PChar-у указатель на строковый литерал из одного символа?

> По-поводу совместимости типов в Делфи спроить не буду с
> этим получше чем в Си, но тоже не идеал.

Не идеал. Я с совместимостью Pointer-TObject тоже не согласен. Опять таки потому, что приходиться спускаться на более низкий уровень абстракции.

← →
Ins © (2007-10-25 23:55) [103]

> У меня такое ощущение, что вы пытаетесь меня учить, при
> том что знаете не больше меня.

Давайте не будем меряться ничем. Никто вас не учит, я лишь высказываю свое отношение к теме дискуссии.

← →
Ins © (2007-10-25 23:59) [104]

Проблема в том, что я мыслю в категориях Паскаля, а вы - скорее C++, так как нету в Паскале ссылок. Не-ту. Не вводил Вирт такого понятия.

← →
vpbar © (2007-10-26 00:03) [105]

>>Ins © (25.10.07 23:53) [102]
Так же как и строке. Разрешить присваивать символ.
Возможно же присвоение типа String:=Char . Хотя с PChar тут опять несуразность PChar:=Char - нельзя, но PChar:=String тоже нельзя. Хотя PChar:="строка" можно. Так почему же не считать что PChar:="с"
(где "с" - символ) тоже можно.

Ins © (25.10.07 23:55) [103]
Давайте. Просто у меня возникло такое ощущение после [95] и гдето еще.

ЗЫ. Вообщем все. Я спать. А то запутано что то объясняю такие простые весчи.

← →
vpbar © (2007-10-26 00:05) [106]

>>Ins © (25.10.07 23:59) [104]
Неее я мыслю в категориях абстрактных понятий, а вы как и сказали "в категориях Паскаля". Просто я считаю что Макконел прав. "Программировать нужно не на языке, а с использованием языка"

← →
vpbar © (2007-10-26 00:07) [107]

Точно спать пора.
Макконнелл - кажется точнее будет :)

← →
oxffff © (2007-10-26 00:09) [108]

Парни открывайте устройство управляемого кода, особенно почитайте про Machine State.

> [108] oxffff © (26.10.07 00:09)

Да вообще лучше забить на императивные языки и изучать функциональные. :) Там таких проблем нет.

> Просто я считаю что Макконел прав.

Вирт наверное не читал Макконелла, но мне импонирует та идеология, которую он вложил в Паскаль. :) И я ее придерживаюсь.

> Ins © (26.10.07 00:10) [109]
>
> > [108] oxffff © (26.10.07 00:09)
>
> Да вообще лучше забить на императивные языки и изучать функциональные.
> :) Там таких проблем нет.

Это были просто мои мысли в слух.
Ни кому и не о чем.
:)

P.S. Мне спать пора уже.
И сняться мне цистерны и вагоны.
Привет Mettler Toledo.

Читал-читал про типизацию, но так и не понял - сможет Валентин быть программистом, или нет?

Отвечаю - Валентин, если последние штук 40 постов тебе интересны, то сможешь.

> Это были просто мои мысли в слух.
> Ни кому и не о чем.
> :)

Дык у меня тоже :) Все фигня.

> Скажите, это обязательно знать, смогу ли я быть, скажем
> так, хорошим программистом, не вдаваясь глубоко внутрь?

Чего?

> Чего?

Не, мне точно пора спать. LOL сам с себя.

> @!!ex © (26.10.07 00:32) [116]
> > [112] Юрий Зотов © (26.10.07 00:23)
>
> Мне интересны... Значит я смогу?

Если прочитаешь про Assignment compatibility

The formal description of assignment compatibility

verification type compatibility.
In essence, a value V is assignment compatible with a location L if it meets one
of the following conditions:
• The exact static type referred to by the type signature of V matches the exact type of the location.
• V, described by the generic type signature G<U1,...,Un>, is assignment compatible with L,
described by the generic type signature H<T1,…,Tn>, if and only if G=H, and for each generic
parameter of G with a variance annotation of var_i we have:
o var_i = none or Ti is a value type or Ti is a generic parameter: Ui is the same exact
type as Ti
o var_i = +: Ti := Ui (covariant: an instance of Ui can be stored in a location of type Ti)
o var_i = -: Ui := Ti (contravariant: an instance of Ti can be stored in a location of
type Ui).
One of the types supported by the exact type of V is assignment compatible to the type of L.
This allows, for example, an instance of a class that inherits from a base class (hence supports
Partition I 33
the base class’s type contract) to be stored into a location whose type is that of the base class.
[Note: Recall that a location constraint is just a type constraint plus two additional possible
constraints (literal and constant), and thus a location constraint can be converted into a type
constraint in a natural way. end note] Under this set of rules, transitivity of assignment
compatibility holds: if L := V and M := L, then M := V.

И т.д. и т.п.

Интересно?

> @!!ex © (26.10.07 00:37) [118]

Да ты крут как я погляжу. :)

Тогда поясни почему при передачи var параметра его тип должен точно соответствовать типу параметру метода.

> [119] oxffff © (26.10.07 00:40)
> Тогда поясни почему при передачи var параметра его тип должен
> точно соответствовать типу параметру метода.

Не должен. Вы это откуда взяли?

смогу ли я быть программистом Найти похожие ветки