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

Цитата korvin @ 13.03.11, 15:24

а зачем виртуальное наследование?

Для разруливания ромбовидных наследований.

Цитата korvin @ 13.03.11, 15:24

Вы же интерфейс от класса отличаете?

Кто "мы"? "мы" пользуемся множественным наследованием. У кого нет множественного наследования -- пользуются интерфейсами.

Цитата MyNameIsIgor @ 13.03.11, 15:29

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

Цитата

так и запишем: идиоматический ООП-код в C++ не работает

а танцы со ссылками и переопределениями операторов, когда в других языках все просто, мне не очень интересны =)

Пусть лучше знатоки интерфейсов расскажут, как они обходят ситуации с коллизиями имён методов разных интерфейсов.

Цитата MyNameIsIgor @ 13.03.11, 15:29

И много вы дебажили шаблонов?

мне достаточно приведенной картинки и многочисленных (и, что важно, похожих) впечатлений в интернетах =)

Добавлено 13.03.11, 15:59

Цитата Qraizer @ 13.03.11, 15:51

Пусть лучше знатоки интерфейсов расскажут, как они обходят ситуации с коллизиями имён методов разных интерфейсов.

если в стат.типизированном ЯП:
1) совпадают только имена, количество и типы параметров разные -- просто два перегруженных метода. ты ж с Java знаком?
2) совпадают полностью сигнатуры -- никакой колизии, просто один и тот же метод, в чем проблема? пересечение множеств всего-навсего

в дин.типизированном Racket в интерфейсах задаются только имена, потому для него справедлив только пункт 2, ситуация под пунктом 1 просто невозможна.

т.е. это не является коллизией в общем-то. хотя как именно ведет себя C# и Delphi в таких ситуациях, я не знаю, сужу по Java/Go/Racket

Цитата Qraizer @ 13.03.11, 15:51

Пусть лучше знатоки интерфейсов расскажут, как они обходят ситуации с коллизиями имён методов разных интерфейсов.

type
  ta = class(TInterfacedObject,IIntf1,IIntf2)
    procedure f1;
    procedure IIntf1.f = f1;
    procedure f2;
    procedure IIntf2.f = f2;
  end;

Цитата MyNameIsIgor @ 13.03.11, 15:29

Да Боже упаси утверждать, что они делают фантастическое. Просто они делают достаточно, чтобы во многом облегчить жизнь программиста на C++.

ну дык дженерики делают все тоже самое, только что в рантайме, зато без километровых сообщений об ошибках

Цитата korvin @ 13.03.11, 15:18

ближе к теме возьмем те же дженерики C#/Delphi

Которые пришлось специально вводить как языковые конструкции. Фразу "специально вводить" понимаешь? И разницу между "специально вводить" и "реализовать имеющимися средствами".

Добавлено 13.03.11, 16:12

Цитата korvin @ 13.03.11, 16:01

ну дык дженерики делают все тоже самое, только что в рантайме

И поиск ошибок в рантайме.

Сообщение отредактировано: trainer - 13.03.11, 16:12

Цитата korvin @ 13.03.11, 15:51

а танцы со ссылками и переопределениями операторов, когда в других языках все просто, мне не очень интересны =)

"Танцы со сслыками"? Какие танцы? То, что f1 и f2 вызывается с аргументами по ссылке? Это что ли танцы?
А где там "переопределение" операторов то? Вы бы сначала хоть что-нибудь о C++ узнали бы, а то у меня тут два человека уже колики себе заработали, когда я им этот пост показал - пожалейте людей!
Впрочем, специально для вашей испорченной функциональными языками психики, могу привести пример попроще, сделав его из того недокода быдлокодера, который вы предоставили. Уж извините, самые откровенные ляпы исходного аффтара пришлось поправить...

class IA
{
public:
  virtual void f() = 0;
};
 
class IB : public IA
{
public:
  virtual void g() = 0;
};
 
class A : public IA
{
public:
  virtual void f() {}
};
 
class IB2 : public IB
{
  void f() { IB_f(); }
public:
  virtual void IB_f() = 0;
};
 
class B : public A, public IB2
{
public:
  virtual void g() {}
  virtual void IB_f() { A::f(); }
};
 
int main()
{
  B b;
 
  b.IB_f();
  b.g();
 
  return 0;
}

Цитата korvin @ 13.03.11, 15:53

мне достаточно приведенной картинки и многочисленных (и, что важно, похожих) впечатлений в интернетах =)

Странно... Мне, видимо, попадаются исключительно противоположные, но тоже друг на друга похожие, да, впечатления.

Цитата korvin @ 13.03.11, 16:01

ну дык дженерики делают все тоже самое, только что в рантайме

Да не то же самое...

Сообщение отредактировано: MyNameIsIgor - 13.03.11, 16:17

Цитата trainer @ 13.03.11, 16:04

Которые пришлось специально вводить как языковые конструкции. Фразу "специально вводить" понимаешь? И разницу между "специально вводить" и "реализовать имеющимися средствами".

конечно понимаю, вот в CL взяли и ввели средствами языка мощную ОО-систему, которой можно удобно пользоваться без кучи сопроводительного мусора, а не то, что Игорь привел. вот в C#, Delphi нет таких средств, они и взяли сделали абстракцию частью языка изнутри, зато этим пользоваться удобно, и без шансов где-то забыть поставить очередной virtual

Добавлено 13.03.11, 16:25

Цитата MyNameIsIgor @ 13.03.11, 16:16

Цитата korvin @ 13.03.11, 15:51

а танцы со ссылками и переопределениями операторов, когда в других языках все просто, мне не очень интересны =)

"Танцы со сслыками"? Какие танцы? То, что f1 и f2 вызывается с аргументами по ссылке? Это что ли танцы?
А где там "переопределение" операторов то? Вы бы сначала хоть что-нибудь о C++ узнали бы, а то у меня тут два человека уже колики себе заработали, когда я им этот пост показал - пожалейте людей!
Впрочем, специально для вашей испорченной функциональными языками психики, могу привести пример попроще, сделав его из того недокода быдлокодера, который вы предоставили. Уж извините, самые откровенные ляпы исходного аффтара пришлось поправить...

class IA
{
public:
  virtual void f() = 0;
};
 
class IB : public IA
{
public:
  virtual void g() = 0;
};
 
class A : public IA
{
public:
  virtual void f() {}
};
 
class IB2 : public IB
{
  void f() { IB_f(); }
public:
  virtual void IB_f() = 0;
};
 
class B : public A, public IB2
{
public:
  virtual void g() {}
  virtual void IB_f() { A::f(); }
};
 
int main()
{
  B b;
 
  b.IB_f();
  b.g();
 
  return 0;
}

еще раз повторяю:

Цитата

так и запишем: идиоматический ООП-код в C++ не работает

и какой еще IB_f? в исходном C#-коде нет никакого IB_f

Сообщение отредактировано: korvin - 13.03.11, 16:27

Цитата korvin @ 13.03.11, 16:22

и какой еще IB_f? в исходном C#-коде нет никакого IB_f

И что? У нас тут занятия по теме "напишем на языке А в точности как на языке B"? Я думал, что поставлена задача, которую надо было решить.
Кстати, давайте самую малость усложним пример

#include <iostream>
 
class IA
{
public:
  virtual void f() = 0;
};
 
class IB : public IA
{
public:
  virtual void g() = 0;
};
 
class A : public IA
{
public:
  virtual void f() { std::cout << "A::f()" << std::endl; }
};
 
class IB2 : public IB
{
  void f() { IB_f(); }
public:
  virtual void IB_f() = 0;
};
 
class B : public A, public IB2
{
public:
  virtual void g() { std::cout << "B::g()" << std::endl; }
  virtual void IB_f() { std::cout << "B::f()" << std::endl; }
};
 
void f1(IA& iface)
{
  iface.f();
}
 
void f2(IB& iface)
{
  iface.f();
  iface.g();
}
 
int main()
{
  B b;
 
  f1(static_cast<A&>(b));
  f2(b);
 
  return 0;
}

с выводом

A::f()
B::f()
B::g()

во-первых, IB2 у Вас уже не интерфейс, из-за наличия в нем реализации метода;
во-вторых, поскольку B наследует A, который реализует IA, то B должен автоматически считаться реализующим IA и передаваться в f1 без всяких static_cast. так ведут себя все ЯП с интерфейсами;
в-третьих, у нас нет задачи решить задачу более сложно, чем в оригинале, т.к. это fail для решающего, а в последнем примере Вы вообще все запутали непонятно зачем.

Добавлено 13.03.11, 16:53
а, пардон, static_cast умышленно был сделан; тоже не очень-то соотвествует ООП

Сообщение отредактировано: korvin - 13.03.11, 16:54

Цитата korvin @ 13.03.11, 16:51

во-первых, IB2 у Вас уже не интерфейс, из-за наличия в нем реализации метода;

Не интерфейс. Вас буковка I смущает? Вы думаете, что её сложно убрать?

Цитата korvin @ 13.03.11, 16:51

во-вторых, поскольку B наследует A, который реализует IA, то B должен автоматически считаться реализующим IA и передаваться в f1 без всяких static_cast

А он реализует IA. Но по-разному Потому и нужно приведение типов.

Цитата korvin @ 13.03.11, 16:51

так ведут себя все ЯП с интерфейсами

недоезыги без множественного наследования

Цитата korvin @ 13.03.11, 16:51

в-третьих, у нас нет задачи решить задачу более сложно, чем в оригинале

Вернее сказать, не было. Я её предложил. Имею ведь я право предложить задачу?

Цитата korvin @ 13.03.11, 16:51

а в последнем примере Вы вообще все запутали непонятно зачем.

Что вам не понятно? Просто использование множественного наследования. Мне интересно, как вы сделаете на языках без оного.

Добавлено 13.03.11, 16:58

Цитата korvin @ 13.03.11, 16:51

а, пардон, static_cast умышленно был сделан; тоже не очень-то соотвествует ООП

Странное какое-то у вас представление о ООП...

Цитата MyNameIsIgor @ 13.03.11, 16:58

Странное какое-то у вас представление о ООП...

да в общем-то почти такое же, как у одного из основателей:

Цитата

OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them.


Cheers,
Alan

статический полиморфизм сюда никак не вписывается

Цитата MyNameIsIgor @ 13.03.11, 16:58

Не интерфейс. Вас буковка I смущает? Вы думаете, что её сложно убрать?

да, она ввела меня в заблуждение, зачем Вы запутываете код? =))

Цитата MyNameIsIgor @ 13.03.11, 16:58

А он реализует IA. Но по-разному Потому и нужно приведение типов.

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

Цитата MyNameIsIgor @ 13.03.11, 16:58

недоезыги без множественного наследования

в CL есть множественное наследование, но есть и интерфейсы (фактически каждая generic-функция там является интерфейсом), однако ведет он себя как все нормальные языки, а не эта ваша ложка дегтя =)

Цитата MyNameIsIgor @ 13.03.11, 16:58

Вернее сказать, не было. Я её предложил. Имею ведь я право предложить задачу?

static_cast -- это не ООП-шно =)

Цитата MyNameIsIgor @ 13.03.11, 16:58

Что вам не понятно? Просто использование множественного наследования. Мне интересно, как вы сделаете на языках без оного.

множественное наследование тут не при чем. статический полиморфизм причем. точнее даже приведение типов

Сообщение отредактировано: korvin - 13.03.11, 17:45

Цитата korvin @ 13.03.11, 14:31

Цитата D_KEY @ 13.03.11, 14:17

korvin, то, что интерфейсов в С++ нет говорилось уже неоднократно. Другое дело, что если в языке есть множественное наследование и абстрактные классы, то интерфейсы и не нужны, по крайней мере такие, какие они в C#, Java и Delphi.

ты не прочитал вторую цитату:

Цитата

C#, C++ -- первое соберётся, второе - нет

=)

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

Добавлено 13.03.11, 17:48

Цитата trainer @ 13.03.11, 14:44

Цитата D_KEY @ 13.03.11, 12:51

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

можно сказать то, что в нем можно сделать то, чего первоначально не предполагалось.

Разве это не справедливо для любого языка?

Цитата

Цитата D_KEY @ 13.03.11, 12:51

зачем разработчики boost'а ТАК используют шаблоны

Странно слышать от тебя такой вопрос. Очевидно чтобы перенести максимум работы на стадию компиляции.

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

Цитата D_KEY @ 13.03.11, 17:44

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

возможность единообразно работать с разными классами, не связанными отношением наследования.
вот есть у тебя несколько классов, с разными предками, но с некоторыми методами с одинаковыми сигнатурами, как ты напишешь одну функцию для работы с ними?