generics в 2010. Есть баги

← →
oxffff © (2009-10-22 09:44) [0]

Я .... .... ненавижу этих ..... которые выпускают сырые версии Delphi.
И этих .... тестров. Вообщем везде .........

Накипело.
P.S.

Internal error urw1111 достал.
А мне не хочется делать везде приведение типов. А придется. :(

← →
DrPass © (2009-10-22 09:52) [1]

Лентяй :)

← →
oxffff © (2009-10-22 09:56) [2]

> DrPass © (22.10.09 09:52) [1]

Это прошлый век заниматься приведением типов.

← →
DrPass © (2009-10-22 09:58) [3]

> oxffff © (22.10.09 09:56) [2]
>
> Это прошлый век заниматься приведением типов.

Ага, и вообще код писать - прошлый век.
Всем бы твои проблемы...

← →
oxffff © (2009-10-22 10:04) [4]

> DrPass © (22.10.09 09:58) [3]

Как такие выводы делаешь?

Заниматься приведением типов там где это не нужно - это прошлый век.
Код должен быть безопасным насколько это возможно с точки зрения типов.
Явное приведение - это потенциальные грабли которые не под силу static typed компилятору.

← →
DrPass © (2009-10-22 10:42) [5]

> oxffff © (22.10.09 10:04) [4]

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

← →
oxffff © (2009-10-22 10:59) [6]

> DrPass © (22.10.09 10:42) [5]
>
> > oxffff © (22.10.09 10:04) [4]
>
> Явное приведение типов - это не грабли, а контроль программиста
> над кодом. Потенциальные грабли - это нетипизированные языки,
> языки с отсутствием строгого контроля за типами и т.д.
>

Явное приведение типов - это указание программисту что он будет трактовать один тип как другой. Есть компиляторы которые вставляют динамическую проверку такого решения, а есть такие которые это не делают. В общем случае эта проверка должна гарантировать корректность кода с точки зрения типов. Она необходима. ее остсутствие создает трудновылавливаемые ошибки. Ты не допускаешь ошибки?

← →
DrPass © (2009-10-22 11:23) [7]

> oxffff © (22.10.09 10:59) [6]
> Явное приведение типов - это указание программисту что он
> будет трактовать один тип как другой
...
> Ты не допускаешь ошибки?

При явном приведении типов, признаюсь, за 14 лет стажа работы программистом, не было ни разу. Мне вообще непонятно, как тут можно ошибиться, если ты сам сознательно написал, что и к чему приводить. Разве что писать в укуренном состоянии... Но, думаю, тут дженериками не обойдешься :)
При использовании компиляторов, которые типы слабо контролируют (читай - С, С++), ошибок, конечно, хватало.

← →
oxffff © (2009-10-22 11:27) [8]

> DrPass © (22.10.09 11:23) [7]

Лукавишь.

C, C++ от Pascal не отличается.

Читай

http://en.wikipedia.org/wiki/Type_system

Static typing
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. In static typing, types are associated with variables not values. Statically typed languages include Ada, AS3, C, C++, C#, JADE, Java, Fortran, Haskell, ML, Pascal, Perl (with respect to distinguishing scalars, arrays, hashes and subroutines) and Scala. Static typing is a limited form of program verification (see type safety): accordingly, it allows many type errors to be caught early in the development cycle. Static type checkers evaluate only the type information that can be determined at compile time, but are able to verify that the checked conditions hold for all possible executions of the program, which eliminates the need to repeat type checks every time the program is executed. Program execution may also be made more efficient (i.e. faster or taking reduced memory) by omitting runtime type checks and enabling other optimizations.

← →
RWolf © (2009-10-22 11:34) [9]

ну, положим, Си ещё как отличается; в худшую сторону.
C++ в плане типов построже, да.

← →
oxffff © (2009-10-22 11:36) [10]

> oxffff © (22.10.09 11:27) [8]

Поэтому ошибки вида

var BaseclassVar:Tbaseclass;

BaseclassVar:=TdescendantClass2.create;

TdescendantClass3(BaseclassVar)

допустимы и в том и другом.

← →
DrPass © (2009-10-22 11:39) [11]

> oxffff © (22.10.09 11:27) [8]
>
> Лукавишь.
>
> C, C++ от Pascal не отличается.

А ты не по академическим статейкам сравнивай. Ей-богу, не поверю, что у тебя нет опыта работы с Ц/Ц++. Тем более что в данной статье говорится лишь про то, что у них одинаково отсутствует рантаймовый контроль типов. А я сейчас про проверку на этапе компиляции говорю.

← →
DrPass © (2009-10-22 11:43) [12]

> oxffff © (22.10.09 11:36) [10]
>
> Поэтому ошибки вида
>
> var BaseclassVar:Tbaseclass;
>
> BaseclassVar:=TdescendantClass2.create;
>
> TdescendantClass3(BaseclassVar)

А это называется "неправильно готовить кошек". Такое приведение следует делать оператором as в Delphi и dynamic_cast в Ц++, и проблема сама собой отпадет.

← →
oxffff © (2009-10-22 11:44) [13]

> DrPass © (22.10.09 11:39) [11]

Ну и в чем разница? Покажи. :)

← →
DrPass © (2009-10-22 11:46) [14]

> oxffff © (22.10.09 11:44) [13]
>
> > DrPass © (22.10.09 11:39) [11]
>
> Ну и в чем разница? Покажи. :)

В Сях у тебя получится присвоить символьную переменную целочисленной, и присвоить значение указателя переменной без разименования.

← →
oxffff © (2009-10-22 11:50) [15]

> DrPass © (22.10.09 11:46) [14]

Я тебе про свой пример для С++ и Delphi.

← →
DrPass © (2009-10-22 11:53) [16]

> oxffff © (22.10.09 11:50) [15]

В конкретно этом примере разницы нет. Но в
> DrPass © (22.10.09 11:43) [12]

я про это уже написал

← →
oxffff © (2009-10-22 12:05) [17]

> DrPass © (22.10.09 11:43) [12]
>
> > oxffff © (22.10.09 11:36) [10]
> >
> > Поэтому ошибки вида
> >
> > var BaseclassVar:Tbaseclass;
> >
> > BaseclassVar:=TdescendantClass2.create;
> >
> > TdescendantClass3(BaseclassVar)
>
> А это называется "неправильно готовить кошек". Такое приведение
> следует делать оператором as в Delphi и dynamic_cast в Ц++,
> и проблема сама собой отпадет.

Только это уже совсем не явное привидение.

Хочелось бы возложить такую проверку на компилятор и избавиться от проверки в run time(для меня это очень очень очень критично). Сделав так

TsomeClass<T>=class(someBaseClass)
end;
Somevar:TsomeClass<someotherType> по причине subj
он валится на строчке
Somevar:=TsomeClass<someotherType>.create(..);

← →
oxffff © (2009-10-22 12:16) [18]

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

← →
DrPass © (2009-10-22 12:21) [19]

> oxffff © (22.10.09 12:05) [17]

> Хочелось бы возложить такую проверку на компилятор и избавиться
> от проверки в run time(для меня это очень очень очень критично).

Согласен, потребности бывают специфические. У меня другой случай - мне важнее, чтобы программа работала у 5% тех наших пользователей, которые до сих пор используют Win9x. Поэтому прелести Delphi 2009/10 мне недоступны :)

← →
Alkid © (2009-10-22 14:59) [20]

> oxffff ©

Программируй на чем-нибудь, где type inference работает :-)

> Alkid © (22.10.09 14:59) [20]

Приветствую, дорогой.
Решил освоить какой нибудь фукнциональный язык, хотел у тебя поинтересоваться с какого начать Хаскел или OCAML.
Мне собственно нужно чтобы понимать примеры из книги по теории типов
Бенджамина Пирса "Типы в языках программирования".
Какой выбрать?

> Alkid © (22.10.09 14:59) [20]

нашел еще подпорочку статей.
http://brainslugs.blogspot.com/2007/08/links-types.html

P.S. Ты же тоже любишь мозг поразминать. :)

← →
Дмитрий Белькевич (2009-10-22 17:19) [23]

Подай в суд на Эмбаркадеро. За баги ;) Ну и моральную компенскацию за нарушение душевного спокойствия.

> oxffff © (22.10.09 15:18) [21]

Не такой уж я и дока в этом деле, что бы такие советы давать :)
ИМХО, Haskell "чище" в идологическом плане. С другой стороны, есть язык F#, который есть диалект ML (точнее OCaml), реализованный, как можно догадаться, для .NET. Причем реализованный самим MS, и в 2010-ую студию он войдет "по умолчанию". Т.е. Ocaml "ближе к жизни". Еще есть интересный язык - Nemerle, который занятен тем, что он:
1. Функционально-императивый.
2. Реализован для .NET.
3. Имеет развиты возможности метапрогарммирования, следующие духу Лиспа, при это поддерживает ООП и имеет статическую систему типов.

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

P.S. Лично у меня в планах стоит поизучать F#.

> oxffff © (22.10.09 15:25) [22]

Слушай, занятные ссылки! Спасибо, читаю с огромным интересом!
(когда потомок разрешает :D)

> (когда потомок разрешает :D)

Мне это знакомо. :)

А вы могли бы показать как оно будет с дженериками и без них. Чтобы сравнить разницу. Просто интересно где там можно ошибится..

← →
jack128_ (2009-10-22 23:06) [28]

> ИМХО, Haskell "чище" в идологическом плане.

не просто "чище", а абсолютно чистый. И ленивый. А вот уже - вынос мозга ИМХО. проще c энергичных языков начинать по моему. и гибридных.

> jack128_ (22.10.09 23:06) [28]

Гы-гы. Монады я до сих пор не до конца понял :) Ленивость, кстати, весьма хорошая вещь в некоторых местах. Например, ленивые списки (и вообще структуры данных) - очень хорошая вещь.

Кстати, интересно, а как в ФП можно поддержать концепцию частично определённых структур данных a-la Prolog?

generics в 2010. Есть баги Найти похожие ветки