Шаблоны и перегрузка операторов

← →
euru (2003-12-24 14:30) [0]

В C++ и C# есть шаблоны и перегрузка операторов. Наличие таких конструкций предоставляет некоторые удобства в написании программ. А можно ли достичь тех же результатов, введя какие-то другие конструкции языка?

← →
JibSkeart (2003-12-24 14:32) [1]

что значит другие конструкции языка ?

← →
PVOzerski (2003-12-24 14:34) [2]

На "королевстве Delphi" был материал, как через include-файлы добиться эффекта шаблонов. Перегружаемые процедуры/функции - почти ничем не хуже, чем перегружаемые операторы (IMHO). А вообще идеология Паскаля такова, что скорость компиляции во многом связана со слабостью препроцессора. Отсюда и ограничения в синтаксисе.

← →
Vuk (2003-12-24 14:34) [3]

В C# шаблонов пока нет. Будут только в версии 2.0

← →
Serginio666 (2003-12-24 14:43) [4]

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

← →
euru (2003-12-24 15:12) [5]

>Vuk © (24.12.03 14:34) [3]
Я знаю. Будем считать, что под "C++ и C#" я подразумевал "С++ (начиная с версии такой-то - ведь там тоже не сразу, насколько я помню, появились шаблоны) и C# 2.0"

>Serginio666 (24.12.03 14:43) [4]
Шаблоны или дженерики - какая разница? Их введение в языки преследует одну цель: сделать алгоритм независимым от передаваемых в него и используемых в нем типов параметров.

>PVOzerski © (24.12.03 14:34) [2]
Знаком. В свое время даже несколько усовершенствовал эту идею. Но это всего лишь попытка имитации оригинальной идеи С++. Перегружаемые функции - это частичное решение. Они позволяют абстрагировать название процедуры от передаваемых параметров, но саму функцию придется реализовывать для каждого возможного варианта этих параметров.

>JibSkeart © (24.12.03 14:32) [1]
>что значит другие конструкции языка ?
Допустим, в Delphi тоже решат ввести идею независимости алгоритма от типа параметров. Это можно сделать так, как поступили в C#. А можно это сделать каким-нибудь иным способом?

← →
Serginio666 (2003-12-24 15:17) [6]

Подожди 2 версии и только на Net т.к. поддержка дженериков в самой платформе а не фича языка. И их главное отличие от шаблонов это уже настоящие классы только с неопределенными типами. ООП и подсказка через точку все при них.

← →
Vuk (2003-12-24 15:19) [7]

to euru:
>А можно это сделать каким-нибудь иным способом?
Зависит от алгоритма.

← →
euru (2003-12-24 15:43) [8]

>Vuk © (24.12.03 15:19) [7]
А при чем здесь сам алгоритм? Ведь в С++ шаблоны вводили как некий механизм абстрагирования, без оглядки на какие-либо алгоритмы.

>Serginio666 (24.12.03 15:17) [6]
По поводу поддержки платформой шаблонов или дженериков ничего не скажу (здесь vuk, наверно, специалист), а вот перезагрузку операторов платформа поддерживает совсем не так, как это делает C#.

← →
Vuk (2003-12-24 15:57) [9]

to euru:
>А при чем здесь сам алгоритм?
А при том. Вот, к примеру, алгоритм перебора элементов чего-либо может быть реализован как итератор и шаблоны здесь вообще ни при чем. Сама по себе библиотека контейнерных классов тоже может быть написана без использования шаблонов. Обобщенное программирование просто добавляет к этим вещам дополнительную типобезопасность.

← →
Serginio666 (2003-12-24 16:15) [10]

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

← →
euru (2003-12-24 16:55) [11]

>Vuk © (24.12.03 15:57) [9]
Да? А как же хранение этих самых элементов в котейнерах? В Delphi, где нет шаблонов, и TList, и TContainer нужно каждый раз специально подстраивать под хранимый ими тип элементов.

>Serginio666 (24.12.03 16:15) [10]
>Вообще перегрузка это из - за шаблонов
Перегрузка операторов в .net появилась раньше шаблонов.

>Перегрузка операторов на самом деле не есть хорошо, т.к. скрываются многие вещи...
То же самое можно сказать и про классы, потому что, не имея описания класса и его методов, невозможно ничего сказать о поведении самого класса. Неужели фраза
if A < B then...
менее понятна, чем
if A.less(B) then...

← →
Vuk (2003-12-24 17:07) [12]

to euru:
>Да? А как же хранение этих самых элементов в котейнерах?
Я что-то не понял, какие с этим проблемы?

>В Delphi, где нет шаблонов, и TList, и TContainer нужно каждый
>раз специально подстраивать под хранимый ими тип элементов.
Если не очень волнует типобезопасность - не нужно.

← →
euru (2003-12-24 17:18) [13]

Допустим, мне нужно хранить в списке значения типа Extended. Будет ли мне удобно воспользоваться сервисом класса TList?

← →
Vuk (2003-12-24 17:21) [14]

to euru:
> Будет ли мне удобно воспользоваться сервисом класса TList?
TList - нет. Но если написать что-то свое, более универсальное, то почему бы и нет?

← →
Serginio666 (2003-12-24 17:38) [15]

2 euru © (24.12.03 16:55) [11]
Вообщето перегрузка операторов чисто сишная фича.А когда там появились шаблоны чесно говоря не знаю. Но например
сравнение классов если нет перегруженного оператора == идет сравнение только ссылок. С перегруженным оператором непонятно так как ReferenceEquals или перегруженный оператор. Для известных классов все прекрасно а когда неизвестен оссобенно когда класс является синглтоном.

Тот же TList в алгоритме 10 строчек основного кода.
Ко всему прочему вставляя в TList структуру большого объема ты получишь только тормоза вместо увеличения скорости, т.к. затраты на MOVESW и Realloc будут больше. Кстати увеличение каппасити нужно делать сразу в 2 раза, а не четверть как в TList.
Дождись 2 ФреймВорка, или коди на C# в видби. Согласен, что дженериков явно нехватает, но борланд уже махнул рукой на Native компилятор.

← →
euru (2003-12-24 18:18) [16]

Наиболее универсальным, при прочих равных условиях, мы получим класс TList только в том случае, если он не будет зависить типа его элементов. А так как в Delphi это невозможно, то всегда можно будет найти такой тип, который будет сложно или вообще невозможно использовать с этим классом. Поэтому нужен некий механизм, аналогичный template C++ и C#. Вопрос в том, должен ли он быть именно таким?

← →
Vuk (2003-12-24 18:20) [17]

to euru:
>А так как в Delphi это невозможно
А аргументы в пользу невозможности где? ;o)

← →
euru (2003-12-24 18:53) [18]

Нет механизмов - нет возможности. :)

Косвенным подтверждением служит отсутствие таковых разработок на Delphi, Java и C# 1.0, а также появление их на С++ и C# только после того, как туда было введено понятие шаблонов.

← →
Serginio666 (2003-12-24 18:58) [19]

2(euru) Я уже задолбался спорить с Сишниками.

Вот пример упрощенный пример TList на дженериках
http://www.rsdn.ru/Forum/Message.aspx?mid=450320&only=1

Вот некоторые аналоги на Delphi
http://www.rsdn.ru/Forum/Message.aspx?mid=377407&only=1
http://www.rsdn.ru/Forum/Message.aspx?mid=390648&only=1

http://www.rsdn.ru/Forum/Message.aspx?mid=376351&only=1

← →
Vuk (2003-12-24 19:01) [20]

to euru:
>Нет механизмов - нет возможности.
Нет ручек - нет варенья. (c) анекдот.

Каких механизмов не хватает-то? Я уже говорил - если не беспокоит типобезопасность, то проблем нет.

>Косвенным подтверждением служит отсутствие таковых разработок на
>Delphi, Java и C# 1.0
Ни в Java ни в .net нет библиотеки коллекций? Ведь есть. И без всяких generics.

← →
Serginio666 (2003-12-24 19:01) [21]

2(euru © (24.12.03 18:53) [18] )
Ну только не надо путать шаблоны с Дженериками. Да они решают общие задачи только совсем дркгими способами. Кстати в Яве именно аналоги дженериков тоже появились.

← →
euru (2003-12-24 20:29) [22]

>Vuk © (24.12.03 19:01) [20]
Насколько я знаю в Java библиотека контейнеров работает с элеметами Object и его потомками, не позволяя явным образом работать с элементарными типами (int, char и т.д.). С контейнерами в .net я не знаком, но думаю, что они в чем-то аналогичны Java, а работа с элементарными типами и типами struct ведется опосредованно с использованием механизма упаковки/распаковки.

В Delphi наиболее распространены три способа подстройки контейнеров к определенному типу:
1. Создание специализированных классов (TList, TStringList, TObjectList) путем перекрытия некоторых методов или вообще заменой другим классом с такой же функциональностью.
2. Создание для каждого типа внешнего обработчика, уточняющего работу не привязанного к типам контейнера.
3. Явное преобразование типа элемента к типу, предлагаемому контейнером (V := Integer(List[i]); List[i] := Pointer(V)).
В первых двух случаях будет дублирование кода. Третий некорректно работает, если размер типа внешнего элемента больше размера типа элемента контейнера.

В С++ все это устраняется с помощью шаблонов. Достаточно при описании контейнера указать, что его элементами являются не какие-то конкретные типы, а шаблон, который подставляется при объявлении этого контейнера (List<int> i_items; List<Object> o_items;)

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

← →
Vuk (2003-12-24 20:35) [23]

to euru:
>Третий некорректно работает, если размер типа внешнего элемента
>больше размера типа элемента контейнера.
О! А кто мешает размер элемента контейнера сделать настраиваемым? :o)

← →
Serginio666 (2003-12-24 20:38) [24]

По поводу Явы, шаблонов, дженериков

http://www.uneta.org/article.aspx?article=719A4A69-8390-483A-8478-A55F53AD1380

Между тем, компания Sun Microsystems® предложила дополнение к шаблонам в следующей версии языка программирования Java под кодовым названием "Tiger". Компания Sun выбрала реализацию, которая не требует изменения Виртуальной машины Java.

← →
euru (2003-12-24 21:35) [25]

Vuk © (24.12.03 20:35) [23]
А если размер элемента непостоянен? Типа String.

← →
Vuk (2003-12-24 21:45) [26]

to euru:
>Типа String.
String - динамическая структура и везде передается как указатель. Почему стоит поступать как-то иначе?

Кстати о птичках. Правила работы с конкретными типами - тоже алгоритмы. Что мешает построить контейнер так, чтобы получив некий класс, описывающий правила работы с конкретным типом (управление памятью, правила копирования, сохранения/загрузки и т.п), контейнер смог решить, как ему строить свою функциональность?

← →
PVOzerski (2003-12-25 11:04) [27]

Рискну резюмировать: реализация шаблонов а-ля C++ в Delphi привела бы: а) к "раздуванию" препроцессора и, как следствие, к замедлению скорости компиляции; б) к невозможности (по меньшей мере, затруднительности) использования заранее скомпилированных модулей (.dcu), если таковые содержат шаблоны (вариант с пришитыми "мини-интерпретаторами", сами понимаете, не особо привлекателен)...

← →
Serginio666 (2003-12-25 12:23) [28]

>>PVOzerski © (25.12.03 11:04) [27]

С точки зрения шаблонов, то Да.
Но с точки зрения дженериков Нет.
2 euru © (24.12.03 21:35) [25]
Подожди меньше года, а возможно уже в скором времени и в Альфа версии новой Delphi будут дженерики обязательно.
По поводу Коллекций, то на указателях делай что угодно, создавай свои структуры итд. Если хочешь типобезопасность применяй классы как в общем то и сделано в Net.

← →
euru (2003-12-25 12:35) [29]

>Vuk © (24.12.03 21:45) [26]
>String - динамическая структура и везде передается как указатель. Почему стоит поступать как-то иначе?
Потому что работа с размерными и ссылочными типами ведется по-разному.

>Что мешает построить контейнер так, ...
Это вариант 2 в [22]. Тогда придется для каждого типа писать свой класс-обработчик. При использовании шаблонов это как раз та работа, которую автоматически выполняет компилятор.

>PVOzerski © (25.12.03 11:04) [27]
Вопрос не в том, почему в Delphi нет шаблонов. Вопрос в том, почему они именно такие, а не какие-то другие.

← →
MV (2003-12-25 12:47) [30]

Интересно, есть ли кто-нибудь, больше года актовно использовавший Delphi после C++, и если есть, действительно ли он так страдал от отсутствия шаблонов?
Для перегрузки простых функций типа сравнения вполне можно (для простых типов) использовать Variant (он расширяемый, мы все знаем об это, конечно?), с последующим контролем типов; а для сравнения (etc) экземпляров классов никакие шаблоны не помогут. Один черт два экземпляра класса без перегрузки соответствующих операций не сравнишь.
Что это людей так беспокоит отсутствие шаблонов в Delphi?

← →
Serginio666 (2003-12-25 12:53) [31]

2 euru
Кстати о дженериках можно клепать очень сложные рекурсивные структуры например
http://www.rsdn.ru/Forum/Message.aspx?mid=445372#445372

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

Немного терпения. Ответ Дженерики нужны и будут везде.

← →
Vuk (2003-12-25 13:38) [32]

to euru:
>Тогда придется для каждого типа писать свой класс-обработчик.
Это да. НО опять же, скорее всего не для каждого типа данных, а для каждого вида данных, для которых нужно различать разные виды обработки данных. К примеру те же Integer и Extended по большому счету для контейнера отличаются только размером и поэтому алгоритм будет один и тот же, точно так же в одну группу попадают строки и динамические массивы.

>При использовании шаблонов это как раз та работа, которую
>автоматически выполняет компилятор.
Что-то не уверен...

← →
euru (2003-12-25 15:01) [33]

>Vuk © (25.12.03 13:38) [32]
Тогда внутри вида придется использовать вариант 3 из [22], т.е. контроль типа и правила его обработки снова будут ложиться на программиста.

А в чем именно неуверенность?

>MV (25.12.03 12:47) [30]
Естественно, без явного наличия в языке программирования шаблонов и перегрузки операторов можно обойтись. Тогда они вручную эмулируются программистами (тот же copy/paste, специальные функции, типа concat, strcmp). В принципе, и без явного наличия ОО-расширения в языках можно обойтись - при желании это тоже можно сэмулировать вручную. А по поводу наличия или отсутствия шаблонов в Delphi я уже высказался в [29].

>Serginio666 (25.12.03 12:53) [31]
Компиляция шаблонов в С++ и дженериков в C# различается, но принцип их использования по большому счету и в том, и в другом языках схож. С другой стороны, и в C#, и в CLR используется перезагрузка операторов. Только в C# для этих целей используется специальная конструкция (operator+), а в CLR - специальная функция (op_XXX со специальным флагом). Поэтому в C# можно будет написать A + B, а в том же VB придется писать op_Summary(A, B).

>ALL
Попробуем подойти с другой стороны. Допустим, у нас есть какой-то гипотетический язык программирования со всеми необходимыми конструкциями. Каким образом можно было бы организовать шаблонное программирование в этом языке? Должны ли они выглядеть также, как шаблоны в C++, или использовать какой-то другой принцип? А может это не шаблонами можно решить, а каким-то другим способом?

← →
MV (2003-12-25 15:05) [34]

euru © (25.12.03 15:01) [33]
В принципе, и без явного наличия ОО-расширения в языках можно обойтись - при желании это тоже можно сэмулировать вручную.

Мощно задвинул, Евгений! Все бреют голову и посыпают пеплом.

← →
Serginio666 (2003-12-25 15:43) [35]

2 euru © (25.12.03 15:01) [33]
Ну ты читай
Serginio666 (25.12.03 12:53) [31]
Шаблонов C++ не будет как и доминация использования языка С++ совсем в ближайшее время.

Народ из-за усердного использования шаблонов компилирут проекты аж по часу, а форточки говорят аж за сутки.

А вот с дженериками совсем другая ситуация, но их мало кто еще знает.
По поводу перегрузки, то я ее не использую или использую в очень крайних случаях, т.к. в Net еще кучу операторов переопределять нужно, в основном implicit и explicit.
Очень хочется посмотреть нову Delphi.Net.

← →
euru (2003-12-25 17:25) [36]

>MV (25.12.03 15:05) [34]
А какие принципиальные проблемы? Только тогда вручную придется реализовывать VMT и поддерживать ее работоспособность.

>Serginio666 (25.12.03 15:43) [35]
Что-то мне все посты рекламу дженериков напоминают. :)

← →
Serginio666 (2003-12-25 17:31) [37]

Хе-Хе. Интересно а на чем ты работать собрался??? Delphi свое развитие видит только в Net, да и MC++ тоже, хотя тамкомбинация дженериков с шаблонами.
В Net отказались от шаблонов в пользу ООП и Дженериков.
Или у тебя есть выбор. А о дженериках говорю, потому, что оооочень мне они нравятся.

← →
MV (2003-12-25 17:37) [38]

euru © (25.12.03 17:25) [36]
>MV (25.12.03 15:05) [34]
А какие принципиальные проблемы? Только тогда вручную придется реализовывать VMT и поддерживать ее работоспособность.

Да, делали мы такое в юности на FORTH. Читали дедулю Страуструпа и лепили. Классно было. Жалко, Delphi появился.

← →
MV (2003-12-25 17:38) [39]

euru © (25.12.03 17:25) [36]
>MV (25.12.03 15:05) [34]
А какие принципиальные проблемы? Только тогда вручную придется реализовывать VMT и поддерживать ее работоспособность.

Интересно, как это на Fortran-IV выглядело бы?
Или на Pascal?

← →
euru (2003-12-25 18:06) [40]

MV (25.12.03 17:38) [39]
Как мы это делали на FoxPro 2.6 (где на имя функции отводилось 10 символов):
- каждому классу соответствовал один файл;
- внутри файла был case, элементами которого были строковые значения имен функций (это чтобы преодолеть длину в 10 символов);
- первым параметром передавался дескриптор объекта этого класса.
Коду на Паскале
var V: TMyClass; V.insert("X");
соответствовал код на FoxPro
=TMyClass("insert", V, "X")
где TmyClass - это имя файла

Таблица виртуальных методов хранилась в голове у разработчиков и в описании на бумаге.

Шаблоны и перегрузка операторов Найти похожие ветки