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

Цитата MyNameIsIgor @ 01.11.11, 06:43

А что происходит в Delphi, если в разных интерфейсах есть методы с одинаковой сигнатурой, а мы реализуем оба интерфейса?

Я ж написал: компилятор потребует явно указать, что и куда. Вот из хелпа:

For example, the class declaration:
 
type
  TMemoryManager = class(TInterfacedObject, IMalloc, IErrorInfo)
    function IMalloc.Alloc = Allocate;
    procedure IMalloc.Free = Deallocate;
    // ...
  end;
maps IMalloc's Alloc and Free methods onto TMemoryManager's Allocate and Deallocate methods.
 
A method resolution clause cannot alter a mapping introduced by an ancestor class.

Цитата D_KEY @ 01.11.11, 06:36

В С++ нет концепции интерфейсов, так что о каком выборе в С++ идет речь мне до сих пор не понятно.

А как же абстрактные классы? Неужто они не являются концепциями интерфейсов в в частных случаях?

Цитата scorpion @ 01.11.11, 08:00

Цитата D_KEY @ 01.11.11, 06:36

В С++ нет концепции интерфейсов, так что о каком выборе в С++ идет речь мне до сих пор не понятно.

А как же абстрактные классы? Неужто они не являются концепциями интерфейсов в в частных случаях?

Я уже говорил, что наличие абстрактных классов и множественного наследования в языке приводит к тому, что интерфейсы(в том виде, что есть в Java/C#/etc.) не востребованы. Но их этого не следует, что абстрактные классы и интерфейсы - одно и тоже.

Цитата D_KEY @ 01.11.11, 08:02

Я уже говорил, что наличие абстрактных классов и множественного наследования в языке приводит к тому, что интерфейсы(в том виде, что есть в Java/C#/etc.) не востребованы. Но их этого не следует, что абстрактные классы и интерфейсы - одно и тоже.

Впрочем как и не следует, что интерфейсы должны быть в виде концептов

Цитата D_KEY @ 01.11.11, 08:02

Я уже говорил, что наличие абстрактных классов и множественного наследования в языке приводит к тому, что интерфейсы(в том виде, что есть в Java/C#/etc.) не востребованы.

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

Цитата D_KEY @ 01.11.11, 08:02

Но их этого не следует, что абстрактные классы и интерфейсы - одно и тоже.

Этого никто вроде как и не говорил. Но при этом абстрактным классам ничто не мешает быть интерфейсами. А вот интерфейс != абстрактный класс, тут уже не поспоришь. Хотя наоборот возможно.

Сообщение отредактировано: scorpion - 01.11.11, 08:09

Цитата scorpion @ 01.11.11, 08:08

Цитата D_KEY @ 01.11.11, 08:02

Я уже говорил, что наличие абстрактных классов и множественного наследования в языке приводит к тому, что интерфейсы(в том виде, что есть в Java/C#/etc.) не востребованы.

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

Именно.

Цитата

Но при этом абстрактным классам ничто не мешает быть интерфейсами.

Мешает. Отличия были описаны выше в постах Romkin'a и Flex'а.

Добавлено 01.11.11, 08:17

Цитата MyNameIsIgor @ 01.11.11, 08:06

Цитата D_KEY @ 01.11.11, 08:02

Я уже говорил, что наличие абстрактных классов и множественного наследования в языке приводит к тому, что интерфейсы(в том виде, что есть в Java/C#/etc.) не востребованы. Но их этого не следует, что абстрактные классы и интерфейсы - одно и тоже.

Впрочем как и не следует, что интерфейсы должны быть в виде концептов

Чего?

Цитата D_KEY @ 01.11.11, 08:14

Мешает. Отличия были описаны выше в постах Romkin'a и Flex'а.

Конкретно в каком месте?
Вот например:

struct ISomeInterface
{
   virtual void SomeMethod1(/*...*/) = 0;
   virtual void SomeMethod2(/*...*/) = 0;
   ...
};

Где конкретно предоставленный интерфейскласс противоречит концепции интерфейсов ?

Сообщение отредактировано: scorpion - 01.11.11, 08:18

Цитата scorpion @ 01.11.11, 08:17

Где конкретно предоставленный интерфейскласс противоречит концепции интерфейсов ?

Например, вот такой код не будет работать, так, как планировалось:

struct B
{
   void SomeMethod1(/*...*/);
   void SomeMethod2(/*...*/);
};
 
struct D : B, ISomeInterface
{
};

D будет считаться абстрактным классом.

Цитата scorpion @ 01.11.11, 08:17

Где конкретно предоставленный интерфейскласс противоречит концепции интерфейсов ?

Тогда перепиши на C++ пример из этого поста: Delphi vs C++ vs C# (сообщение #3016643) , только без введения новых линий наследования.

Цитата Flex Ferrum @ 01.11.11, 08:25

Тогда перепиши на C++ пример из этого поста: Delphi vs C++ vs C# (сообщение #3016643) , только без введения новых линий наследования.

Так?

struct IFoo /*interface*/
{
   virtual void Foo() = 0;
   virtual void Bar() = 0;
};
 
struct Base
{
   void Foo() {/* something */}
};
 
struct Derived : IFoo, Base
{
   void Bar(){ /*something else*/ }
   void Foo(){ Base::Foo(); }
};

Цитата D_KEY @ 01.11.11, 08:25

D будет считаться абстрактным классом.

А на шарпе или в делфи это все отработает без ошибок хочешь сказать? Компилятор сам реализует методы интерфейса чтоле?

Цитата scorpion @ 01.11.11, 08:40

А на шарпе или в делфи это все отработает без ошибок хочешь сказать? Компилятор сам реализует методы интерфейса чтоле?

В дельфях - не знаю, а вот Шарп - он да. Он сам свяжет методы из интерфейса с методами из базового класса. Без участия разработчика.

Цитата Flex Ferrum @ 01.11.11, 08:44

В дельфях - не знаю, а вот Шарп - он да. Он сам свяжет методы из интерфейса с методами из базового класса. Без участия разработчика.

Не, я именно про код который привел D_KEY, заметь у него ни в классе B, ни в классе D нет реализаций методов.
А касательно этого примера, ну свяжет, и что? Я это сделал вручную. К тому же, если оно делает это все автоматом, без предупреждений, мне кажется можно и отгребсти. Я точно знаю, что без реализации метода Foo, я не смогу создать объект класса Derived, и компилятор мне подскажет это в виде ошибки, даже если я случайно упущу этот момент. И я тут же реализую его как мне нужно, либо вызову из базового класса, либо реализую непосредственно свой. А вот как быть если на шарпе я не хочу чтобы оно мне связывало? Упустил момент, компилится, работает вроде все нормально. А потом оказалось что я не тот метод использую, так?

Добавлено 01.11.11, 08:52
Кстати, а где собственно этот синтаксический сахар, привязывается к концепции интерфейсов? Речь шла ведь как раз таки о концепции, а не о каких то частных выдуманных случаях. Покажите мне?

Сообщение отредактировано: scorpion - 01.11.11, 08:53

Цитата scorpion @ 01.11.11, 08:50

А касательно этого примера, ну свяжет, и что? Я это сделал вручную. К тому же, если оно делает это все автоматом, без предупреждений, мне кажется можно и отгребсти. Я точно знаю, что без реализации метода Foo, я не смогу создать объект класса Derived, и компилятор мне подскажет это в виде ошибке, даже если я случайно упущу этот момент. И я тут же реализую его как мне нужно, либо вызову из базового класса, либо реализую непосредственно свой. А вот как быть если на шарпе я не хочу чтобы оно мне связывало? Упустил момент, компилится, работает вроде все нормально. А потом оказалось что я не тот метод использую, так?

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

Цитата scorpion @ 01.11.11, 08:50

я именно про код который привел D_KEY, заметь у него ни в классе B, ни в классе D нет реализаций методов.

Почему нет ?
Ты видишь в B абстрактные методы?

Цитата

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

Странно.

Добавлено 01.11.11, 08:59

Цитата scorpion @ 01.11.11, 08:50

Кстати, а где собственно этот синтаксический сахар, привязывается к концепции интерфейсов?

Разница в том, что нет наследования. Класс не наследует интерфейс, а реализует его. Кстати, и то, чтобы метод класса, реализующий метод интерфейса, был виртуальным, не требуется.

Цитата Flex Ferrum @ 01.11.11, 08:53

Зависит от семантики термина "интерфейс". По факту, у тебя объект реализует все методы интерфейса.

Да, именно. Есть конкретный интерфейс, для него есть конкретный набор классов, который гарантированно должен реализовать все методы интерфейса.

Цитата Flex Ferrum @ 01.11.11, 08:53

Только часть непосредственно, а другую - унаследованно.

Но ведь нужно понимать, что это своего рода синтаксический сахар. Ведь, может возникнуть неоднозначная ситуация, когда ты наследуешься от интерфейса и двух классов, и при этом эти классы никак не наследуются от интерфейса, но при этом во всех трех сущностях присутствует метод Foo, тогда как автоматически связывать? Имеено по этому в С++ этот подход не требуется, имхо. Но это никак не противоречит концепции интерфейсов. Я нигде не встречал в описании интерфейсов именно такой отличительной черты от абстрактных классов. Это синтаксический сахар и не более, я так считаю.

Добавлено 01.11.11, 09:07

Цитата D_KEY @ 01.11.11, 08:53

Почему нет ?
Ты видишь в B абстрактные методы?

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

Цитата D_KEY @ 01.11.11, 08:53

Странно.

Что именно странного?

Цитата D_KEY @ 01.11.11, 08:53

Разница в том, что нет наследования. Класс не наследует интерфейс, а реализует его.

А где написанно что класс реализует интерфейс, если это вообще две разные сущности, которые могут быть попросту разными библиотеками разных компаний?

Цитата D_KEY @ 01.11.11, 08:53

Кстати, и то, чтобы метод класса, реализующий метод интерфейса, был виртуальным, не требуется.

Кстати в С++ тоже самое, чтобы метод класса, реализующий метод интерфейса был виртуальным, не требуется.

Сообщение отредактировано: scorpion - 01.11.11, 09:08