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

Цитата korvin @ 04.05.11, 10:27

Ромкин, я всё-таки не совсем понимаю, какие тут преимущества перед простой композицией объектов

Хм. Что ты называешь простой композицией? Явное делегирование?
Для композиции объектов нужно знать размер каждого объекта. Здесь - не надо, поэтому я и веду разговор про объект в dll, которая может поменяться.

Цитата korvin @ 04.05.11, 10:24

Цитата D_KEY @ 04.05.11, 09:51

"Какие-то объекты" - это как?

это объекты, описания классов и интерфейсов которых тебе не доступны на этапе компиляции

Зачем они тогда мне нужны?

Цитата

Цитата D_KEY @ 04.05.11, 09:51

А как еще ты собрался с ними работать? Откуда брать о них информацию? В любом случае должно быть нечто, что будет уметь понимать тип объекта. Как иначе-то?

у них и спрашивать

Как у бинарного потока что-то спросить?

Добавлено 04.05.11, 10:41

Цитата Romkin @ 04.05.11, 10:26

Цитата D_KEY @ 04.05.11, 09:51

Т.е. говорим, что реализовывать интерфейс IFoo будет не сам объект нашего класса, а Foo.
Нет? А что тогда это значит?

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

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

Цитата D_KEY @ 04.05.11, 10:40

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

Поясняю: есть абстрактный класс и есть его реализация в dll, которая динамически подгружается. В ней есть одна функция - получить конкретную реализацию. Как компоновать будешь?

Цитата Romkin @ 04.05.11, 09:49

D_KEY, ты похоже так и не понял. Вот дается тебе dll, в котрой метод получения IFoo и IBar, в твоей терминологии - абстрактных классов. Твоя задача - в своем приложении создать объект, реализующий одновременно IFoo и IBar, подгружая dll динамически (она может меняться). То есть, динамическое наследование от двух предков. На Delphi эта задача решается элементарно, просто вместо явного создания классов ставится получение интерфейсов.

Если класс-наследник IFoo, или IBar, то dll может вернуть указатель на любой из них. Либо же просто void-указатель с приведением. Правда стрёмно всё это. dll и прога должны быть скомплены одним компилятором и одними ключами.

Цитата korvin @ 04.05.11, 10:24

у них и спрашивать

Вот тебе поток:
0x00 0x00 0x00 0x0A 0x00 0x00 0x00 0x0A 0x00 0x00 0x00 0x0A 0x00 0x00 0x00 0x0A

Спрашивай)))

Цитата Romkin @ 04.05.11, 10:46

Цитата D_KEY @ 04.05.11, 10:40

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

Поясняю: есть абстрактный класс и есть его реализация в dll, которая динамически подгружается. В ней есть одна функция - получить конкретную реализацию. Как компоновать будешь?

Честно говоря, не понимаю, к чему ты клонишь.

Цитата Повстанець @ 04.05.11, 12:57

Вот тебе поток:
0x00 0x00 0x00 0x0A 0x00 0x00 0x00 0x0A 0x00 0x00 0x00 0x0A 0x00 0x00 0x00 0x0A

Спрашивай)))

да без проблем! Метод getAccessViolation я у этого объекта сразу нашёл.

Цитата Adil @ 04.05.11, 18:06

да без проблем! Метод getAccessViolation я у этого объекта сразу нашёл.

А метод DoBSOD там не выглядывает из последних нескольких байт?

Цитата Повстанець @ 04.05.11, 12:57

Вот тебе поток:
0x00 0x00 0x00 0x0A 0x00 0x00 0x00 0x0A 0x00 0x00 0x00 0x0A 0x00 0x00 0x00 0x0A

Это морзянка

Точно. Радисты с серии Ж начинают передачу, чтоь на том конце успели проснуться, подстроить приём и привыкнуть к скорости.

Тут подумалось...
Если в языке запрещают множественное наследование, но при этом есть интерфейсы и возможность делегирования реализации интерфейса своему полю/свойству/etc., то зачем в таком случае оставлять одиночное наследование от конкретных классов?
Если такое наследование запретить, то о проблеме ограничения по количеству базовых классов и речи бы не шло - наследовались бы только интерфейсы, а реализация бы работала всегда через агрегирование(которое всегда гибче наследования реализации).
Чуть напоминает подход Haskell, но только для ООП.

Сообщение отредактировано: D_KEY - 06.05.11, 04:38

Цитата D_KEY @ 06.05.11, 04:37

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

Потому что гораздо больше возможностей. Каждому - свое. При наследовании наследуется не только реализация, но и метакласс. Копание с классами-записями оставим старым языкам.
Да, кстати. В Питоне, который исповедует принцип "наименьшего удивления":

class foo:
    x=0
 
a = foo()
a.x = 2
b=a
b.x=3
print(a.x)

дает 3. Я действительно не удивлен

Добавлено 06.06.11, 07:26
Вдогонку:

int f (int x, int y) {
  return x + y;
}
 
int z () {
  int i = 0;
  return f (i, i++);
}

Что вернет функция z ?

Цитата Romkin @ 06.06.11, 07:25

Потому что гораздо больше возможностей.

Например?

Цитата

При наследовании наследуется не только реализация, но и метакласс.

Может и правда примерчик?

Цитата

Копание с классами-записями оставим старым языкам.

Цитата

Да, кстати. В Питоне, который исповедует принцип "наименьшего удивления":

class foo:
    x=0
 
a = foo()
a.x = 2
b=a
b.x=3
print(a.x)

дает 3. Я действительно не удивлен

Я тоже. А чему удивляться-то?

Добавлено 06.06.11, 07:29

Цитата Romkin @ 06.06.11, 07:25

Вдогонку

UB
И зачем ты это тут приводишь? Так, кстати, никто не пишет

Цитата D_KEY @ 06.06.11, 07:27

Я тоже. А чему удивляться-то?

Поменял поле у b, а оно у a тоже поменялось. Странно это, однако.

Цитата D_KEY @ 06.06.11, 07:27

Так, кстати, никто не пишет

Вот не надо. Пишут На Delphi ты просто так не сделаешь. На Питоне, кстати, тоже.

Цитата D_KEY @ 06.06.11, 07:27

При наследовании наследуется не только реализация, но и метакласс.

Может и правда примерчик?

Примеров было уже полно. Два уровня: класс и объект, мирно друг с другом взаимодействующие. Вообще говоря, в Delphi это очень привычно.

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

TDongle = class
  class function Login(...); virtual; abstract;
  class function Logout(...); virtual; abstract;
  constructor Create(...); //Вызывает Login...
...

Три потомка, каждый перекрывает функции класса для доступа по-своему. Объект же определяется предком.

Цитата Romkin @ 06.06.11, 09:20

Цитата D_KEY @ 06.06.11, 07:27

Я тоже. А чему удивляться-то?

Поменял поле у b, а оно у a тоже поменялось. Странно это, однако.

Чего странного? Ссылочная семантика. Хочешь копии - запроси явно. Для тебя может быть странно из-за того, что у вас в Delphi может быть и так и сяк, в зависимости от типа. В питоне все единообразно.

Цитата

Цитата D_KEY @ 06.06.11, 07:27

Так, кстати, никто не пишет

Вот не надо. Пишут

Ну... Мало ли кто чего пишет, за всех отвечать не могу

Цитата

На Delphi ты просто так не сделаешь.

Строго определен порядок вычисления аргументов функции?
Странно. Впрочем вам можно.

Цитата

Примеров было уже полно. Два уровня: класс и объект, мирно друг с другом взаимодействующие. Вообще говоря, в Delphi это очень привычно.

Да не пример метаклассов, а пример в плане наследования. При отмене наследования реализации метакласс класса можно указывать отдельно.

Цитата

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

TDongle = class
  class function Login(...); virtual; abstract;
  class function Logout(...); virtual; abstract;
  constructor Create(...); //Вызывает Login...
...

Три потомка, каждый перекрывает функции класса для доступа по-своему. Объект же определяется предком.

Не понял

Сообщение отредактировано: D_KEY - 06.06.11, 09:30

Цитата D_KEY @ 06.06.11, 09:29

Для тебя может быть странно из-за того, что у вас в Delphi может быть и так и сяк, в зависимости от типа. В питоне все единообразно.

ну да, ну да...

a=2
b=a
b=3
print(a)

Цитата D_KEY @ 06.06.11, 09:29

При отмене наследования реализации метакласс класса можно указывать отдельно.

Бррр Это уже я не понял.

Цитата D_KEY @ 06.06.11, 09:29

Строго определен порядок вычисления аргументов функции?
Странно. Впрочем вам можно.

Спасибо что разрешил.

Цитата

The register and pascal conventions pass parameters from left to right; that is, the left most parameter is evaluated and passed first and the rightmost parameter is evaluated and passed last. The cdecl, stdcall, and safecall conventions pass parameters from right to left.

Странно когда это не определено.

Цитата D_KEY @ 06.06.11, 09:29

Не понял

Хм... объявление "class function... virtual; abstract;" понятно?