Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата Flex Ferrum @ 29.04.11, 11:41

Да вот мне интересно - как? И чем это тогда отличается от сборки экземпляров классов "из предков"?

Тем что в делфи, все это собирать ты будешь ручками, в этом и вся фишка

Цитата Romkin @ 29.04.11, 11:20

Цитата D_KEY @ 29.04.11, 10:57

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

Дык понятно, зачем нужен другой язык, если есть С++

Да нет же. Я использую питон, всяческие "небольшие дополнительные" языки(awk и т.п.), понимаю, зачем java, зачем руби и питон, и т.д. и т.п.

Цитата

Видишь ли, мы уже спорим очень долго, что само по себе указывает на тот факт, что на Delphi можно делать почти то же, что на С++. Просто на нем это можно делать проще и с удобствами для программиста.

Во-первых, у делфи узкая ниша, по сравнению с С++ и речь мы ведем исключительно о ней(по скольку в других delphi обсуждать не имеет смысла), поэтому дискуссия скорее говорит о том, что не смотря на то, что delphi рассчитана на создание прикладных программ для win32, она не превосходит С++(а должна бы).

Цитата

Цитата D_KEY @ 29.04.11, 11:16

Romkin, так а на абстрактных классах почему нельзя будет также сделать? Или я опять запутался и мы не о том спорили

Хм. Ну покажи, как можно уничтожить TCollectionItem, оставив от него часть, которая реализует функциональность IPing?
У меня-то все понятно: он делегировал этот функционал объекту, который уже есть, причем без доступа к коду этого объекта и без своей реализации интерфейса.

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

Добавлено 29.04.11, 11:49

Цитата Romkin @ 29.04.11, 11:27

D_KEY, а, и учти еще, что у меня в этом коде все защищено: объект, реализующий IPing, не уничтожится пока он есть в коллекции.

Ну так в языке со сборкой мусора ты бы даже не задумывался об этом. В С++ при использовании shared_ptr тоже(в данном случае).

Цитата Flex Ferrum @ 29.04.11, 11:41

Да вот мне интересно - как? И чем это тогда отличается от сборки экземпляров классов "из предков"?

Тем что сборки нет. Есть инициализация.

  TInterfacedObject = class(TObject, IInterface)
...
  class function NewInstance: TObject; override;
...
 
class function TInterfacedObject.NewInstance: TObject;
begin
  Result := inherited NewInstance;
  TInterfacedObject(Result).FRefCount := 1;
end;

Цитата Romkin @ 29.04.11, 11:50

Тем что сборки нет. Есть инициализация.

Вот поэтому вам и приходится, в случае исключения в инициализаторе, ручками удалять в деинициализаторе - те члены, которые уже успели создастся, а в С++, это делается автоматически, машиной...

Сообщение отредактировано: KILLER - 29.04.11, 11:53

Цитата Romkin @ 29.04.11, 11:50

Есть инициализация.

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

Цитата D_KEY @ 29.04.11, 11:48

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

Элемент коллекции есть IPing Ты ж хотел множественного наследования, вот оно.

Цитата D_KEY @ 29.04.11, 11:48

Во-первых, у делфи узкая ниша, по сравнению с С++ и речь мы ведем исключительно о ней(по скольку в других delphi обсуждать не имеет смысла), поэтому дискуссия скорее говорит о том, что не смотря на то, что delphi рассчитана на создание прикладных программ для win32, она не превосходит С++(а должна бы).

Не должна. Интересно, что такого есть в Питоне или Яве, что нельзя было бы сделать в С++?
Тут скорее вопрос удобства.

Добавлено 29.04.11, 12:00

Цитата Flex Ferrum @ 29.04.11, 11:55

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

Уффф. Тем что ты не можешь повлиять на последовательность вызовов, а в Delphi это можно сделать. Тем, что можно вызывать при конструировании виртуальные методы, и даже конструктор может быть виртуальным.

Цитата Romkin @ 29.04.11, 11:57

Цитата D_KEY @ 29.04.11, 11:48

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

Элемент коллекции есть IPing Ты ж хотел множественного наследования, вот оно.

А чем он еще является, кроме IPing?

Цитата

Цитата D_KEY @ 29.04.11, 11:48

Во-первых, у делфи узкая ниша, по сравнению с С++ и речь мы ведем исключительно о ней(по скольку в других delphi обсуждать не имеет смысла), поэтому дискуссия скорее говорит о том, что не смотря на то, что delphi рассчитана на создание прикладных программ для win32, она не превосходит С++(а должна бы).

Не должна. Интересно, что такого есть в Питоне или Яве, что нельзя было бы сделать в С++?

Много чего.

Цитата

Тут скорее вопрос удобства.

Можно и так назвать. Использовать то, что лучше подходит для задачи.

Цитата

Цитата Flex Ferrum @ 29.04.11, 11:55

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

Уффф. Тем что ты не можешь повлиять на последовательность вызовов, а в Delphi это можно сделать. Тем, что можно вызывать при конструировании виртуальные методы, и даже конструктор может быть виртуальным.

Виртуальные методы чего вызываются при конструировании? Пеленаем еще не родившегося ребенка?

Добавлено 29.04.11, 12:07

Цитата Romkin @ 29.04.11, 11:57

Цитата D_KEY @ 29.04.11, 11:48

Во-первых, у делфи узкая ниша, по сравнению с С++ и речь мы ведем исключительно о ней(по скольку в других delphi обсуждать не имеет смысла), поэтому дискуссия скорее говорит о том, что не смотря на то, что delphi рассчитана на создание прикладных программ для win32, она не превосходит С++(а должна бы).

Не должна.

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

Сообщение отредактировано: D_KEY - 29.04.11, 12:07

Цитата D_KEY @ 29.04.11, 12:06

А чем он еще является, кроме IPing?

Элементом коллекции, он с ней взаимодействует. Хочешь потомка написать?

Цитата D_KEY @ 29.04.11, 12:06

Виртуальные методы чего вызываются при конструировании? Пеленаем еще не родившегося ребенка?

Что, по второму кругу? Родившегося уже. Хватит. В Java что, из конструктора тоже нельзя вызвать виртуальный метод? И как там живут?
Если ты никак не поймешь, что объект можно создавать без необходимости вызова конструкторов предков, то я тебе объяснить ничего уже не смогу, сорри.

Цитата D_KEY @ 29.04.11, 12:06

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

Чем Питон и java лучше C++?

Сообщение отредактировано: Romkin - 29.04.11, 12:23

Цитата Romkin @ 29.04.11, 12:19

Что, по второму кругу? Родившегося уже. Хватит. В Java что, из конструктора тоже нельзя вызвать виртуальный метод? И как там живут?
Если ты никак не поймешь, что объект можно создавать без необходимости вызова конструкторов предков, то я тебе объяснить ничего уже не смогу, сорри.

Понимаешь, в чём тонкость. Да, из за явного этапа инициализации ребёнок будет проинициализирован (в соответствии с перечисленными тобою правилами). Но! Формальная инициализированность экземпляра объекта не означает, что его состояние валидно. Валидным (с точки зрения объекта) его состояние будет только после отрабатывания его конструктора. И это неприятный факт ты обязан учитывать в тех виртуальных методах, которые вызываются из конструкторов предков. Ибо эти методы могут работать в условии нарушенного инварианта состояния объекта.

Добавлено 29.04.11, 12:44

Цитата Romkin @ 29.04.11, 11:57

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

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

Цитата Romkin @ 29.04.11, 12:19

Цитата D_KEY @ 29.04.11, 12:06

А чем он еще является, кроме IPing?

Элементом коллекции, он с ней взаимодействует. Хочешь потомка написать?

В смысле? Я имею в виду, есть ли тут множественное наследование?

Цитата

Цитата D_KEY @ 29.04.11, 12:06

Виртуальные методы чего вызываются при конструировании? Пеленаем еще не родившегося ребенка?

Что, по второму кругу? Родившегося уже. Хватит.

Ну так если у вас это не конструкторы, о чем мы все время говорим?

Цитата

В Java что, из конструктора тоже нельзя вызвать виртуальный метод? И как там живут?

"Они" во всех книжках предостерегают от таких вызовов, я уже цитировал.

Цитата

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

Ну так приведи такой пример, может получится. Потомок не знает, что и как делает конструктор базового класса. Вернее "что" - знает. Создает объект.

Цитата

Цитата D_KEY @ 29.04.11, 12:06

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

Чем Питон и java лучше C++?

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

Цитата Flex Ferrum @ 29.04.11, 12:37

И это неприятный факт ты обязан учитывать в тех виртуальных методах, которые вызываются из конструкторов предков. Ибо эти методы могут работать в условии нарушенного инварианта состояния объекта.

Естественно. Но на практике-то тоже бывает отложенная инициализация, типа создаем объект когда он понадобится, а не в конструкторе. И точно так же можно забыть вызвать из метода потомка метод предка, который и создает этот объект "по надобности".
Можно сказать, что у нас один четкий инвариант: поля на нулях. Об остальных заботится программист, и уверяю, это не сложнее чем с обычными методами в наследовании.
Или в С++ и с вариантом, когда поле-объект инициализируется при первом обращении к нему тоже есть автоматизация?

Цитата Romkin @ 29.04.11, 12:45

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

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

Цитата D_KEY @ 29.04.11, 12:45

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

Delphi тоже простой язык, может и посложнее Питона, но зато и побыстрее. Сборка мусора - велкам в дотнет, если так прикалывает. Мне-то как раз не нравится. Java - да, неплохой язык, но там вроде бы все методы виртуальные. А объекты - ссылки. Как тебя это не бесит?
Статическая типизация есть и в Delphi, куда она денется?

Цитата D_KEY @ 29.04.11, 12:45

Ну так приведи такой пример, может получится. Потомок не знает, что и как делает конструктор базового класса. Вернее "что" - знает. Создает объект.

Я для Флекса отрывок привел из TInterfacedObject. В нем конструктора вообще нет, зато есть кастомная инициализация, модифицирован метод метакласса, NewInstance.

Цитата Romkin @ 29.04.11, 12:45

Можно сказать, что у нас один четкий инвариант: поля на нулях.

"И эти люди борются за звание дома высокой культуры быта!"

Цитата Flex Ferrum @ 29.04.11, 12:50

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

Конструктор в Delphi - инициализатор, и ничего никому не обязан. Нет ситуации в Delphi, что часть объекта сконструирована, а часть - нет. Еще раз: объект - единая сущность, конструируется она одним вызовом функции, разом, как и должно.
Кстати, инициализация не размазывается, она наоборот, инкапсулируется в нужных местах. Порядок создания объекта четко определен, вот только не последовательностью предков, а шаблонным методом, единым для любого объекта.