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

Цитата Romkin @ 31.10.11, 10:42

Куча объектов для подключения - это не фонтан.

Это где? что-то не припомню кучи объектов

Цитата korvin @ 31.10.11, 12:31

Это где? что-то не припомню кучи объектов

Все твои предложения так или иначе к этому сводятся

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

Цитата Romkin @ 31.10.11, 13:05

Все твои предложения так или иначе к этому сводятся

безосновательный вывод, у меня к этому ничего не сводится

Цитата Flex Ferrum @ 31.10.11, 13:08

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

Вот и предложи.

Цитата Flex Ferrum @ 31.10.11, 12:05

Цитата D_KEY @ 31.10.11, 12:00

Напомни, как твои свойства получают this своего объекта-владельца?

class Unit
{
public:
    Unit() : properties__(this) {/* ... */;}
};

Ага. И фриендов, наверное, на каждую инстанцию.

Цитата Повстанець @ 31.10.11, 16:47

Ага. И фриендов, наверное, на каждую инстанцию.

В смысле?

Цитата Flex Ferrum @ 31.10.11, 18:44

В смысле?

ну а как твой properties__ получает доступ к private секции того this, что ты передаёшь?

Цитата Повстанець @ 31.10.11, 18:46

ну а как твой properties__ получает доступ к private секции того this, что ты передаёшь?

А. Ну да. Через friend. По новому стандарту этого не требуется.

scorpion, я тот код закинул ради свойств. Ну и заодно на множественное наследование обратил внимание, коли пришлось в том же коде. Если тебе так уж интересна та библиотека, давай свалим отсюда, чё тут korvin-у мешать блистать знанием теории, а народу делать вид, что им жутко интересно что-то ему доказать. Хотя я если правильно понял суть претензий korvin-а, у меня нет тех "недостатков", которые его так сильно заботят.
Если вкратце, то только факты.

Цитата scorpion @ 30.10.11, 23:23

Я подозреваю это был костыль.

Неправильно подозреваешь. Библиотека получилась масштабируемой и гибкой. Новый физический канал или новый протокол обмена реализуются не сложнее, чем просто взять и написать, т.е. полностью изолированно от остальных интерфейсов иерархии, параметры нового физического канала или нового протокола - не сложнее придумывания POD-структуры с полями, интеграция этого в стек - добавление case в фабрику. Рекомпиляция.

Цитата scorpion @ 30.10.11, 23:23

Я все понимаю, ты можешь излить душу, я тебя выслушаю.

Та ты что. Я горжусь той библиотекой. Во-первых, это была первая практическая задача, на которую множественное наследование изящно накладывалось и плотно прилегало. Во-вторых, это был мой первый серьёзный архитектурный опыт. Напомню, писалось 8 лет назад. Я тогда и языка-то не знал ещё. Ну как не знал, знал, конечно... блин, как сказать-то... в общем, думал, что знал. Во. Конечно, с позиции 2011 года видны косяки, но.. э-э-э... скорее косметические, ибо на функциональность в пределах ТЗ никак не влияют. Прикинь, там даже API был вынесен в отдельные классы (ну да, вместо namespace-ов ), так что при желании можно было портануть под POSIX. И прикинь - в ней не было шаблонов!! Я ещё не читал Александреску! Правда, юзать std::vector<> и std::list<> уже потихоньку пробовал.

Цитата scorpion @ 30.10.11, 23:23

Если у вон того полудуплексного парня возникли проблемы...

Ему было банально лень читать ГОСТ. Он так его открыл, полистал, сказал "танунафик, я сам протокол придумаю, попроще, делать мне нечего под DSPёй это программить. Запрограммишь?" На что я ответил "танунафиг за тебя программить, сам программь" и за 3 минуты рассказал о стеке и показал, потомка чего ему надо будет написать и куда вставить case с придуманным им именем новой enum-константы. Больше я его не видел. Через месяц только поинтересовался, тот с трудом вспомнил, о чём речь, мол, сделал за три дня, на обоих концах, включая отладку, включая комплексную отладку с железкой, отчитался и уже забыл. Правда, насчёт полного дуплекса он-таки приврал, тех.канал такого не позволял.

Цитата Romkin @ 31.10.11, 07:04

При чем здесь дизайн? Как раз с интерфейсами все и хорошо, в отличие от множественного наследования. Если кто-то не знает принципов окромя примитивных объектов С++, то конечно будет говнодизайнить, вопросов нет.

Как обычно. Кто б сомневался. Ты ответил на вопрос, который я не задавал, на вопрос, который я задал, ты не ответил. Согласно твоим только что сказанным словам

Цитата Romkin @ 30.10.11, 22:08

У интерфейса наследование только при реализации делается. А в Delphi вообще все интерфейсы от IInterface порождаются, ....

Определись, будь добр.

Цитата D_KEY @ 31.10.11, 07:18

Qraizer, кстати, обрати внимание на пост Flex'а про интерфейсы. Это так же отвечает на твои вопросы.

Я-то обратил. А ты? Тот пример вообще не проблема, и не имеет ничего общего к моему вопросу (на который я уже, можно сказать, получил ответ). Поведение, подобное интерфейсам в примере Flex Ferrum, получается запросто, достаточно всегда наследоваться виртуально, и никогда не опускать интерфейсы в списке баз тех потомков, которые их реализуют.

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

Удивили, тоже мне... Как обычно, C++ даёт возможность выбора, тогда как аппологеты других языков даже не представляют, что какой-то выбор вообще может быть.

Цитата Qraizer @ 01.11.11, 01:32

Цитата (Romkin @ Вчера, 10:04)
При чем здесь дизайн? Как раз с интерфейсами все и хорошо, в отличие от множественного наследования. Если кто-то не знает принципов окромя примитивных объектов С++, то конечно будет говнодизайнить, вопросов нет.
Как обычно. Кто б сомневался. Ты ответил на вопрос, который я не задавал, на вопрос, который я задал, ты не ответил. Согласно твоим только что сказанным словам
Цитата (Romkin @ Вчера, 01:08)
У интерфейса наследование только при реализации делается. А в Delphi вообще все интерфейсы от IInterface порождаются, ....
Определись, будь добр.

Наследование при реализации. Но предок указывается, именно а интерфейсе, а при реализации предок реализуется отдельно.
То есть, есть следующие правила:
1. Все интерфейсы явно или неявно порождаются от IInterface
2. Должны быть реализованы все методы интерфейса.
3. При реализации так или иначе должны быть реализованы все предки этого интерфейса, отдельно.
Наглядно, пусть есть сделующее:

type
  IFoo = interface
  ...
  end;
 
  IBar = interface(IFoo)
  ...
  end;

Тогда возможны следующие реализации (только заголовки):

type
  TFooBar = class(TInterfacedObject, IFoo, IBar) // IInterface уже реализован в TInterfacedObject
  TFoo = class(TObject, IInterface, IFoo) //ручками, методы IInterface и IFoo
  TBar = class(TFoo, IBar) //Предки интерфейса в TFoo, здесь только методы IBar

Невозможно следующее:

ype
  TBar = class(TInterfacedObject, IBar) //Нет реализации IFoo
  TFooBar = class(TObject, IFoo, IBar) //Нет IInterface

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

Цитата Qraizer @ 01.11.11, 01:32

Поведение, подобное интерфейсам в примере Flex Ferrum, получается запросто
...
Удивили, тоже мне...

Однако написал ты нечто совершенно другое

Цитата

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

И всего-то?

Цитата

Как обычно, C++ даёт возможность выбора

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

Цитата

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

Странные и ни чем не подкрепленные выводы

Цитата Qraizer @ 01.11.11, 01:32

Я-то обратил. А ты? Тот пример вообще не проблема, и не имеет ничего общего к моему вопросу (на который я уже, можно сказать, получил ответ). Поведение, подобное интерфейсам в примере Flex Ferrum, получается запросто, достаточно всегда наследоваться виртуально, и никогда не опускать интерфейсы в списке баз тех потомков, которые их реализуют.

Виртуальное наследование - совсем не то же самое. И применять его надо с большой осторожностью, хорошо понимая, к чему это приведёт.

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

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

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

Пишем либо одну общую реализацию методов, либо на каждый метод отдельную.

  IFoo = interface
    procedure SomeMethod;
  end;
 
  IBar = interface
    procedure SomeMethod;
  end;
 
  TFooBar1 = class(TInterfacedObject, IFoo, IBar)
    procedure SomeMethod; //IFoo и IBar
  end;
 
  TFooBar2 = class(TInterfacedObject, IFoo, IBar)
    procedure IFoo.SomeMethod = FooSomeMethod;
    procedure IBar.SomeMethod = BarSomeMethod;
    procedure FooSomeMethod; //IFoo
    procedure BarSomeMethod; //IBar
  end;