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

Цитата

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

В Delphi если у метода есть дефолтная реализация, то обязать перекрыть его в потомке средствами языка нельзя. Но к чему этот вопрос? Я по прежнему смогу в перекрытом потомке вызвать inherited.

Добавлено 07.03.08, 11:09

Цитата

Насколько я понял, в приведенном коде функции не виртуальные?

Серьезно что ли? Я синтаксис хорошо не знаю, воспринял их как виртуальные...

Цитата Romkin @ 07.03.08, 11:06

Насколько я понял, в приведенном коде функции не виртуальные? Это специально? И в С++ идет привязка по именам?

Это я слово virtual забыл.

Цитата Flex Ferrum @ 07.03.08, 11:12

Это я слово virtual забыл.

Фух!
Вот практически буквальный перевод, я только b1 выкинул (и добавил забытое):

type
  TBase = class
  protected
    procedure FooImpl; virtual;
    procedure BarImpl; virtual;
  public
    procedure Foo;
    procedure Bar;
  end;
 
  TDerived = class(TBase)
  protected
    procedure FooImpl; override;
  end;
 
{ TBase }
 
procedure TBase.Bar;
begin
  BarImpl;
end;
 
procedure TBase.BarImpl;
begin
  writeln('Base::BarImpl');
end;
 
procedure TBase.Foo;
begin
  FooImpl;
end;
 
procedure TBase.FooImpl;
begin
  writeln('Base::FooImpl');
end;
 
{ TDerived }
 
procedure TDerived.FooImpl;
begin
  inherited FooImpl;
  writeln('Derived::FooImpl');
end;
 
var
  d1: TDerived;
  b2: TBase;
 
begin
  d1 := TDerived.Create;
  try
    b2 := d1;
    b2.Foo;
    b2.Bar;
  finally
    d1.Free;
  end;
  readln; //Чисто посмотреть
end.

Выводит как и требовалось. А вот если убрать виртуальность - то никакого Derived не выведется.
Можно и d1 выкинуть, писать просто b2 := TDerived.Create; и b2.Free; это так, пояснить.
Другое дело, что из метода потомка ты можешь вызвать только метод непосредственного предка, вызвать дедушку при живом папе нельзя Насколько я понимаю, это и правильно: если тебе требуется прыгнуть через голову предка, то у тебя неправилная реализация иерархии, и ее надо править. Очень неплохой способ контроля идеологии, на мой взгляд.

Цитата

Насколько я понимаю, это и правильно: если тебе требуется прыгнуть через голову предка, то у тебя неправилная реализация иерархии, и ее надо править. Очень неплохой способ контроля идеологии, на мой взгляд.

Полность согласен Дабы по этому поводу не начался новый спор, предлагаю желающим поспорить посетить ссылку, так как лично для меня этот спор интереса не представляет, как уже давно пройденный. Ничего нового по сравнению с тем, что сказано там, я не скажу.
http://www.delphikingdom.com/asp/answer.asp?IDAnswer=49046

Цитата --Ins-- @ 07.03.08, 07:46

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

--Ins--, ладно, сошлёмся на мою температуру, сопли и, как следствие, неспособность достаточно ясно выражаться, потому объясняю ещё раз.
Я это не "не учёл", я на этом сделал акцент(чуешь разницу? ).
Итак, ещё раз, дано:
- есть модуль(unit) A, в нём класс С, имеющий private члены.
- есть модуль B, никак не связанный с A, в нём класс D из которого необходимо получить доступ к private-членам класса С.
Решение: в модуле B делаем forward declaration класса C, что позволяет всему модулю B(любой ф-ции внутри него) иметь доступ к любым членам класса С.

Цитата --Ins-- @ 07.03.08, 07:46

существуют секции strict private и strict protected, которые ограничивают видимость именно внутри класса, а не внутри модуля, private/protected оставлены для совместимости со старым кодом.

Да, до 8-й версии я благо не дожил .
1. Если взглянуть на начало данного холивара, то можно заметить, что некоторые утверждали, что "private на весь модуль" - это хорошо(а не оставили ради совместимости), а, как следствие, private'ом пользоваться хорошо, а, как следствие, к private'у можно полуить доступ средствами языка из любого модуля - вот вам и инкапсуляция. Вот ты насколько часто пользуешься private? А strict версией?
2. А что насчёт private + strict private = вседозволенность? В своём глазу бревно не заметили, сударь .

Цитата --Ins-- @ 07.03.08, 07:46

где в Delphi встроены понятия user-mode, kernel-mode, API А то ведь слово - оно не воробей А заодно, когда будешь говорить о платформозависимости языка, вспомни о Kilyx и Delphi.NET

Да, да, хотел ответить, но забыл - болею, рассеяный...
Я имел ввиду не совсем это. Ессно, понятий kernel/user-mode в языке нет, но есть множество "рюшечек" ориентированных на конкретную ОС(озвучивать её название, думаю, не нужно). Понятие API - я подразумевал как раз те самые DLL и премудрые возможности импорта . Как выглядит объявление внешней ф-ции из dll? А как выглядит объявление ф-ций из .so? Дальше, встроенные возможности для COM - это ли не привязка к винде? Дальше, так широко используемая VCL - она далеко не кроссплатформена. Кроссплатформена CLX, которой никто не пользуется . Боюсь, что далеко не весь список зашитых в язык рюшечек - о каких-то забыл, о каких-то не знаю.

Сообщение отредактировано: b-a1 - 07.03.08, 11:45

Цитата

Я это не "не учёл", я на этом сделал акцент(чуешь разницу? ).
Итак, ещё раз, дано:
- есть модуль(unit) A, в нём класс С, имеющий private члены.
- есть модуль B, никак не связанный с A, в нём класс D из которого необходимо получить доступ к private-членам класса С.
Решение: в модуле B делаем forward declaration класса C, что позволяет всему модулю B(любой ф-ции внутри него) иметь доступ к любым членам класса С.

Во-первых, для чужих классов ты это не проделаешь (не полезешь же ты писать код в их юните?). А для своих, тебе эта возможность ничего не даст. Если бы тебе нужна было в своих же классах сломать инкапсуляцию, ты бы все запихал в public.
* Не внимательно прочел. Правильный ответ ниже привел Romkin

Цитата

Я имел ввиду не совсем это. Ессно, понятий kernel/user-mode в языке нет, но есть множество "рюшечек" ориентированных на конкретную ОС(озвучивать её название, думаю, не нужно). Понятие API - я подразумевал как раз те самые DLL и премудрые возможности импорта . Как выглядит объявление внешней ф-ции из dll? А как выглядит объявление ф-ций из .so? Дальше, встроенные возможности для COM - это ли не привязка к винде? Дальше, так широко используемая VCL - она далеко не кроссплатформена. Кроссплатформена CLX, которой никто не пользуется . Боюсь, что далеко не весь список зашитых в язык рюшечек - о каких-то забыл, о каких-то не знаю.

Что за премудрые возможности импорта? А что, в C++ нет встроенных в язык возможностей импорта из DLL? Насчет интерфейсов - так они с COM связаны не так тесно, как ты думаешь. Наличие интерфесов в языке открывает некие другие возможности (множественное наследование объявлений и т.д.), а с COM - они просто совместимы. Кстати, в кроссплатформенной Java тоже есть интерфейсы. Насчет VCL - не стоит переносить ограничения БИБЛИОТЕКИ на недостатки ЯЗЫКА. И ограничения компилятора - тоже к языку не имеют никакого отношения. Не так ли? Так что рюшечек зашитых в язык ты не привел

Сообщение отредактировано: --Ins-- - 07.03.08, 12:17

Цитата --Ins-- @ 07.03.08, 11:54

Насчет VCL - не стоит переносить ограничения БИБЛИОТЕКИ на недостатки ЯЗЫКА.

Дык, делфи -- язык одной библиотеки. Или он используется как-то ещо? Или VCL компилится на каком нить другом компилере?

Что-то довольно часто адепты C++ говорят о гибкости языка и свободе разработчика. В связи с этим пара вопросов:

• Возможно ли в C++ вызвать виртуальный метод из конструктора класса (именно как виртуальный, разумеется)?
• Возможно ли предотвратить конструкцию или деструкцию объекта, породив исключение?

Цитата

Дык, делфи -- язык одной библиотеки. Или он используется как-то ещо?

Delphi.NET, Kilyx. Теоретически ничего не мешает породить другие компиляторы и библиотеки, язык этому никак не препятствует (живой пример - библиотека KOL). Кстати, другие компиляторы вроде даже есть, только я о них знаю мало (FreePascal и т.д.)

Цитата b-a1 @ 07.03.08, 11:42

Итак, ещё раз, дано:
- есть модуль(unit) A, в нём класс С, имеющий private члены.
- есть модуль B, никак не связанный с A, в нём класс D из которого необходимо получить доступ к private-членам класса С.
Решение: в модуле B делаем forward declaration класса C, что позволяет всему модулю B(любой ф-ции внутри него) иметь доступ к любым членам класса С.

Это ты про С++ сказал?
В Delphi ты хоть какие декларации делай в B, к привату класса из другого модуля не доберешься. Ты пытался привести доступ к protected путем повышения видимости метода в потомке, что совершенно легально.

Цитата wind @ 07.03.08, 11:58

Что-то довольно часто адепты C++ говорят о гибкости языка и свободе разработчика. В связи с этим пара вопросов:

Как бы небыл гибок инструмент, у него всегда будут какие-либо ограничения. У С++ естественно они(ограничения) тоже есть.

Цитата wind @ 07.03.08, 11:58

# Возможно ли в C++ вызвать виртуальный метод из конструктора класса (именно как виртуальный, разумеется)?

нет

Цитата wind @ 07.03.08, 11:58

Возможно ли предотвратить конструкцию или деструкцию объекта, породив исключение?

да.нет.

Цитата b-a1 @ 07.03.08, 11:42

Дальше, встроенные возможности для COM - это ли не привязка к винде?

И опять в очередной раз "слышал звон". НЕ путай реализацию интерфейсов с СОМ. Привязка к СОМ начинается с использования модуля ActiveX. А интерфейс я спокойно могу объявить вообще ничего не используя, точно так же, как и класс.

Цитата --Ins-- @ 07.03.08, 12:01

Delphi.NET, Kilyx.

Оба случая никак не опровергают моё утверждение. В обоих случаях имеем язык делфи и неотъемлимую библиотеку VCL.

Цитата --Ins-- @ 07.03.08, 12:01

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

Теоретически -- ключевое слово. Да и пример не такой уж и живой.

Цитата --Ins-- @ 07.03.08, 12:01

Кстати, другие компиляторы вроде даже есть, только я о них знаю мало (FreePascal и т.д.)

Другие компиляторы паскаля ни имеют отношения ни к делфи, ни к VCL. Т.к. их исходники на них написанные не компилятся ни в одну, ни в другую сторону. Ну.. хелловорды разве что только.

Цитата

Теоретически -- ключевое слово.

Насколько мне известно - это юридический момент. Delphi - это бренд, и никто другой не имеет право использовать это название в своем компиляторе. Тут могу ошибаться. А Delphi.NET хоть и имеет библиотеку, подобную VCL (она даже называется так же) - это совсем другой компилятор и совсем другая библиотека, предназначенная для безболезненного перехода с Delhpi for Win32. Кстати, VCL в .NET можно и не использовать, а работать точно так же, как и в майкрософтовском C# - с теми же классами из пространства имен System (кажется так).

Цитата

Другие компиляторы паскаля ни имеют отношения ни к делфи, ни к VCL. Т.к. их исходники на них написанные не компилятся ни в одну, ни в другую сторону.

Секунду. VCL - это что-то типа MFC. Я могу использовать MFC в C++ Builder, скажем?

Цитата LuckLess @ 07.03.08, 12:09

Как бы небыл гибок инструмент, у него всегда будут какие-либо ограничения. У С++ естественно они(ограничения) тоже есть.

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