Delphi vs C++ , Часть 1

[--Ins--]

AndNot, а че там, давай создавай тему " Delphi vs Asm"! Забавно будет смотреться! Типа как "Микроскоп vs Молоток"

[AndNot]

--Ins--, я не собираюсь ничего сравнивать, просто хотел разрядить обстановку, а то спор куда то не в ту сторону пошел Для меня то очевидно, способ объявлений прототипов неважен, это все равно что сравнивать procedure vs void

Цитата --Ins-- @ 05.03.08, 11:17

а че там, давай создавай тему " Delphi vs Asm"

Да уж, смотреться будет глупо Но я бы непроч сравнить ООП этих языков, т.е. скорость, компактность, а главное их возможности в этих направлениях Я, к примеру, сейчас начал использовать списки, на ООП, вот и интересно, насколько эффективно я это реализовал.

[--Ins--]

Цитата

Для меня то очевидно, способ объявлений прототипов неважен, это все равно что сравнивать procedure vs void

Согласен

Цитата

Но я бы непроч сравнить ООП этих языков, т.е. скорость, компактность, а главное их возможности в этих направлениях Я, к примеру, сейчас начал использовать списки, на ООП, вот и интересно, насколько эффективно я это реализовал.

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

[AndNot]

Цитата --Ins-- @ 05.03.08, 11:37

А мы вроде бы пытались что-то такое обсуждать поверхностно

Было дело, ты мне здорово помог

Цитата --Ins-- @ 05.03.08, 11:37

Мне бы тоже было интересно, свежий взгляд со стороны не помешает

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

Цитата --Ins-- @ 05.03.08, 11:37

Но попробовать можно

Думаю после 8-го марта появится немного времени, тогда и "созвонимся" Главное найти задачку, несложную, но по полной использующую ООП, желательно списки, стеки или очереди.

[--Ins--]

Цитата

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

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

[Romkin]

Цитата AndNot @ 05.03.08, 12:03

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

А это как раз и необязательно. Давно уже можно делать overload виртуальных методов:

If you overload a virtual method, use the reintroduce directive when you redeclare it in descendant classes. For example,
 
type
 
  T1 = class(TObject)
    procedure Test(I: Integer); overload; virtual;
  end;
  T2 = class(T1)
    procedure Test(S: string); reintroduce; overload;
  end;

Не это ли тебе было надо?

[wind]

Цитата Romkin @ 05.03.08, 15:04

Давно уже можно делать overload виртуальных методов

Какой ужас

[AndNot]

Цитата --Ins-- @ 05.03.08, 12:14

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

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

[--Ins--]

Цитата

Может это и неправильно, но очень удобно

По-моему, это и неправильно, и неудобно... Вот смотри, я так понимаю, у очереди и у списка есть общий абстрактный наследник, и он сделан не случайно, а для того, чтобы клиентский код мог не знать о внутреннем устройстве списка (очередь это, или стек), а работать с ним как с неким абстрактным контейнером одинаковым образом. Это несложно реализовать. Нужно у базового класса-списка объявить виртуальные (или даже абстрактные) методы Push, Pop, IsEmpty, может еще какие-то, но прототип у всех у них будет одинаковым. И это позволит клиенту ОДИН раз написать ОБЩИЙ код, но в зависимости от того, что мы этому коду подсунем (очередь или стек), он будет работать так или иначе. Если же клиент должен знать о специфике потомков базового класса, то весь полиморфизм при этом теряется. И тогда даже в общем предке у классов и виртуальных методах смысла мало.

[Romkin]

Цитата wind @ 05.03.08, 21:06

Давно уже можно делать overload виртуальных методов

Какой ужас

Почему? Что такого страшного в виртуальных методах?

[--Ins--]

Romkin, а я другого не понял... Зачем указывать reintroduce? В справке написано, что так надо, но если не указать, то что изменится?

[Romkin]

Цитата --Ins-- @ 06.03.08, 08:46

Зачем указывать reintroduce?

А ты посмотри справку по этой директиве
"The reintroduce directive suppresses compiler warnings about hiding previously declared virtual methods. "

[--Ins--]

Romkin, в том то и дело, что у меня варнинг не появляется, если reintroduce не указать.

Добавлено 06.03.08, 09:00
Ведь предыдущее объявление Test не скрывается!

[wind]

Цитата Romkin @ 06.03.08, 08:37

Что такого страшного в виртуальных методах?

Я не про виртуальные методы, а про нарушение контрактов.

[Romkin]

Цитата wind @ 06.03.08, 09:07

Я не про виртуальные методы, а про нарушение контрактов.

Поясни, что ты хотел сказать

Цитата --Ins-- @ 06.03.08, 08:57

Romkin, в том то и дело, что у меня варнинг не появляется, если reintroduce не указать.

Убери директиву overload у предка. Потому что обычно ее там нет.