А кто-то разве против? Принцип хорош, еще бы синтаксис был по проще, вообще было бы отлично. Тот же список на делфи реализован как список указателей. Нельзя сказать, что сильно удобно работать с указателями, при этом всегда держать в голове какого типа у тебя указатель. Весьма неудобно. Правда тот же механизм можно реализовать путем наследования. Таким образом получены TStringList, TImageList, TMemoStrings, TRichStrings и т.д. Получается, что в С++ объекты более самостоятельные и сами полностью в себе реализовывают. В делфи часть операций ложиться на объект контейнер. С другой стороны шаблон тоже иногда нужно "доробатывать" скажем тот же вектор или лист требуют присутствия определенных операторов, которые определены для стандартных классов, но для нестандартных их необходимо определять самостоятельно. Эта операция по сути схожа написанием класса наследника от Tlist, ведь для нормальной его работы нужно просто переопределить несколько его методов Insert(), Delete(), assign(), которые по своей сути аналогичны + и присвоить. Т.е. операторы заключены уже в контейнере, а не в самом объекте.

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

  К чему это?

  Общий предок совсем неплохо - это основа RTTI и интерфейсов. До BDS 2006 были старые паскалевские объекты без общего предка. В BDS2006 для этих целей ввели advanced record, которые являются простыми объектами с данными, методами, конструкторами и переопределенными операторами и т.д. Они не имеют общего наследника, могут передаваться по значению, копироваться и т.д. Уже добили проблему.



  Это существенно только для атомарных типов, кроме того все зависит от реализации самого объекта. Если у него в реализации будут использоваться виртуальные методы, а это нормальная практика программирования при построении схемы от простого к сложному, то для тех же операций будут тоже вызываться виртуальные методы наследника. 
  Атомарных типов не так много, потому ввести для них оптимизированные уникальные классы совсем не сложно. А чем выше поднимаемся тем больше использование виртуальных методов, при любой концепции. Но там это уже не существенно, так как накладные расходы на виртуальность тонут в обилии производимых над данными операций. Плата невелика и оправдана.

del

Это сообщение отредактировал(а) nerezus - 22.1.2007, 12:26

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


Это сообщение отредактировал(а) VectorMan - 22.1.2007, 16:08

А можно вместо шаблонов встроенных в язык, сделать генерацию кода по образцу. Шаблоны 99% нужны для создания контенеров в которых достаточно поменять имя класса. Просто скопировать объявления заменяя строку А на Б не самая сложная операция и весь код будет виден.

 Но не у всех классов он есть.
Т.е. придется расширять каждый класс интерфейсом, чтобы заюзать подобное в C++?
И работать уже с этими "своими" классами-оболочками?

P.S.
Beltar, т.е. ты за шаблоны, но тебе просто не нравится их текущий синтаксис?

  Ну я не совсем верно сказал. Интерфейсный класс это предок большинства класов VCL. Он реализует IUnknown. Самый нижний Cobject не интерфесный. Интерфес ничего особенного не накладывает. Просто объект содержит 2 дополнительных метода для реализации IUnknown. Это удобно для создания наследников от IUnknown, поскольку не нужно думать о связывании интерфеса с объектом который его реализует. А вот RTTI начинается с Cobject. В общем он только его и содежит, тем самым автоматически распространяя RTTI на все классы. 

nerezus



Я за автоматизацию рутинной работы, а также за то, чтобы в полученный при автоматической генерации код можно было зайти step-by-step отладчиком, т. е. он д/б виден и спокойно редактируем. А не как текст получаемый в C++ после препроцессора, когда неверное понимание того, что должно получиться после выполнения, какого-нибудь заковыристого #define может привести к не очень приятным последствиям.
Вообще проектировать язык следует с учетом того, какие IDE для него возможны. На современном этапе развития IDE и продвинутый компилятор может устранить ряд недостатков самого языка, например, фигурные скобки С можно подсветить, в огромной процедуре Delphi объявить новую переменную из контекстного меню не прокручивая код.
А конструкцию

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



Ну вообще-то TObject. Я как-то не вдавался в особенности RTTI, но в книжечке Фаронова "Исскуство создания компонентов Delphi" написано при директиву M, которая вкл/выкл RTTI и в VCL RTTI вкл у TPersistent.

Конечно TObject   . Просто в последнее время пишу только на С++, вот и все классы у меня автоматом начинаются с "С"   





Возможно это и отключит RTTI как механизм, но из объекта никак не удалит   
   class function - это и есть методы класса идентифицирующие класс.

жесть

можно пояснений?

Имеем класс



Ну и на основании этого несколькими кликами мыши генерим код для TMyList1, контейнера для TMyType1.



И подобный код, если нет привязок к VCL можно перенести во Free Pascal.

понятно. Но шаблоны намного гибче. А копи-паст, хоть и встроенный, никогда до их функциональности не дойдет. Хотя конечно эта идея проще в реализации.

Тоже понравилось  А можно еще ориентироваться на GUI-библиотеки для данного языка на данной платформе 


При условии, что образец писан свими руками или изучен вдоль и поперек. Еще раз ткну пальцем в Boost.

А ведь если переформулировать этот тезис как: «стоит создавать языки с возможно более простой грамматикой», он уже не кажется таким смешным, нет?