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

[D_KEY]

Цитата Romkin @ 06.06.11, 10:51

Цитата D_KEY @ 06.06.11, 10:44

Почему явно? Зачем клиенту-то знать об этой зависимости?

Какому клиенту? Я говорю о реализации объекта доступа. Клиент ничего не знает, он объект использует, а не методы класса.

И я о том же.

Цитата

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

Что тебе это дает? Позволить интерфейсам определять не только методы объекта, но и "методы типа" и точно также будет достаточно наследования интерфейсов.

[Romkin]

Цитата Qraizer @ 06.06.11, 10:58

Romkin, а вот по-моему нелогично вычислять параметры слева направо, когда они передаются в cdecl функцию. Ладно, если в pascal. Так что как тут будет оптимимальней, ещё вопрос.

ДЫк я ж цитировал. cdecl и stdcall - как раз справа налево. Порядок зависит от соглашения вызова.

Добавлено 06.06.11, 11:06

Цитата D_KEY @ 06.06.11, 11:02

Что тебе это дает? Позволить интерфейсам определять не только методы объекта, но и "методы типа" и точно также будет достаточно наследования интерфейсов.

Мне это дает всю функциональность в одном классе. А не разбросанную по нескольким, которые еще и правильно сочетать надо.

[D_KEY]

Цитата Romkin @ 06.06.11, 11:05

Цитата D_KEY @ 06.06.11, 11:02

Что тебе это дает? Позволить интерфейсам определять не только методы объекта, но и "методы типа" и точно также будет достаточно наследования интерфейсов.

Мне это дает всю функциональность в одном классе. А не разбросанную по нескольким, которые еще и правильно сочетать надо.

Тогда почему ты против множественного наследования ?

Добавлено 06.06.11, 11:12

Цитата Romkin @ 06.06.11, 11:05

Мне это дает всю функциональность в одном классе.

С другой стороны... God object

[Romkin]

Цитата D_KEY @ 06.06.11, 11:08

Тогда почему ты против множественного наследования

А зачем оно нужно-то? Это слишком усложняет использование, а случаи, когда вот точно оно нужно крайне редки.
Слишком большая плата, стоит только посмотреть, как Питон решает из какого класса атрибут, например. Порядок объявлений используется.
В Delphi другая идеология, классы и объекты как правило связываются функционально, и дополняют друг друга. Класс при этом может выполнять несколько ролей. Фактически имеем две связанные иерархии, классов и объектов, способов использования связки довольно много. Класс может быть делегатом, фабрикой, синглетоном, объектным пулом... Ты предлагаешь от этого отказаться ради примитивного множественного наследования?

[D_KEY]

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

Ты предлагаешь от этого отказаться ради примитивного множественного наследования?

От этого не надо отказываться
Множественное наследование не является чем-то примитивным, и оно логично. Запрет множественного наследования объясняется лишь мнимыми проблемами в плане реализации...
Когда вам нужно сэмулировать множественное наследование, то вы разбиваете классы на интерфейсы и класс-реализацию, при этом утверждаете, что такое разделение нормально и костылем не является. Тогда зачем вам одиночное наследование, если его точно также можно заменить ?
Или ваша эмуляция является приемлемым решением(тогда наследование реализации не нужно в принципе), или не является(тогда необходимо полноценное множественное наследование).
А то двойные стандарты вырисовываются

[Romkin]

Цитата D_KEY @ 06.06.11, 11:08

С другой стороны... God object

Ну тут ты меня поддел
Вроде в этом случае этого нет, но то что это болезнь дельфистов - это точно.
В данной реализации я разомкнул функциональность, но вот уже и сомневаться начал...
Хм. Собственно что предоставляет ключ:
1. Доступ к перечню лицензий
2. Шифрование массива данных и дешифрование
3. Запись/чтение памяти
Собственно на все функциональности у меня объявлены объекты, но доступ к ним предоставляется именно этим объектом, что я описал. То есть, у него запрашиваются экземпляры.
Вроде бы все же это не божественный объект.

Добавлено 06.06.11, 11:35

Цитата D_KEY @ 06.06.11, 11:32

Или ваша эмуляция является приемлемым решением(тогда наследование реализации не нужно в принципе), или не является(тогда необходимо полноценное множественное наследование).
А то двойные стандарты вырисовываются

А третий случай не рассматриваешь, когда выбирается то, что нужно в конкретном случае?

[D_KEY]

Цитата Romkin @ 06.06.11, 11:33

А третий случай не рассматриваешь, когда выбирается то, что нужно в конкретном случае?

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

[Romkin]

Цитата D_KEY @ 06.06.11, 11:39

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

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

[D_KEY]

Цитата Romkin @ 06.06.11, 11:48

Цитата D_KEY @ 06.06.11, 11:39

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

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

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

[Romkin]

Цитата D_KEY @ 06.06.11, 12:06

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

Помню конечно. Но, понимаешь, это было копирование. То есть, это была эмуляция именно решения на С++ в Delphi, вот в чем дело. Это не было решением задачи на Delphi, по крайней мере в большинстве случаев.
То есть, требуется именно множественное наследование - будут интерфейсы. Но во многих случаях без этого можно обойтись, используя класс, свойства и т.д.
В моем случае (с ключем) множественное наследование нафиг не нужно, там нужно агрегирование. Есть делегат, который предоставляет доступ к конкретному API, и есть объект, который им пользуется (он не выглядит как делегат, у него свой интерфейс). Причем линии наследования практически паралельны получаются, каждому объекту - свой делегат в большинстве случаев. Поскольку у делегата только методы, то для меня естественно отдать эту роль классу.

[trainer]

Цитата Romkin @ 06.06.11, 11:48

Тебе при компиляции нужен исходный код всех предков

Зачем?

[Romkin]

"Так не пишут". Вотъ, откопал:

struct TS3Functions {
 unsigned int (*getClientLibVersion)(char** result);
 unsigned int (*spawnNewServerConnectionHandler)(int port, uint64* result);
 unsigned int (*destroyServerConnectionHandler)(uint64 serverConnectionHandlerID);
 
 /* Error handling */
 unsigned int (*getErrorMessage)(unsigned int errorCode, char** error);
 
 /* Memory management */
 unsigned int (*freeMemory)(void* pointer);
 
 /* Logging */
 unsigned int (*logMessage)(const char* logMessage, enum LogLevel severity, const char* channel, uint64 logID);
 
 /* Sound */
 unsigned int (*getPlaybackDeviceList)(const char* modeID, char**** result);
 unsigned int (*getPlaybackModeList)(char*** result);
 unsigned int (*getCaptureDeviceList)(const char* modeID, char**** result);
 unsigned int (*getCaptureModeList)(char*** result);
 unsigned int (*getDefaultPlaybackDevice)(const char* modeID, char*** result);
 unsigned int (*getDefaultPlayBackMode)(char** result);
 unsigned int (*getDefaultCaptureDevice)(const char* modeID, char*** result);
 unsigned int (*getDefaultCaptureMode)(char** result);
 unsigned int (*openPlaybackDevice)(uint64 serverConnectionHandlerID, const char* modeID, const char* playbackDevice);
 unsigned int (*openCaptureDevice)(uint64 serverConnectionHandlerID, const char* modeID, const char* captureDevice);
};

Ну и что с этим делать?!

Добавлено 06.06.11, 12:42

Цитата trainer @ 06.06.11, 12:41

Тебе при компиляции нужен исходный код всех предков
Зачем?

Либо объектные файлы для данной версии...

[trainer]

Это C. Эмуляция ООП. Чтобы такое "откопать", достаточно заглянуть в заголовочные файлы COM.

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

[D_KEY]

Romkin, а что не так-то? Понадобилось кому-то значит. Какая-то низкоуровневая часть системы. Проблем не вижу.
Это скорее всего вообще голый С.

Добавлено 06.06.11, 12:46

Цитата trainer @ 06.06.11, 12:43

Эмуляция ООП

Не совсем. Нет какого-то типа, который бы принимали все функции(т.е. нет "методов").
Скорее просто инкапсуляция набора функции. Если мне память не изменяет, я что-то похожее делал для представления "драйвера" для набора железок.

[trainer]

Цитата Romkin @ 06.06.11, 12:42

Либо объектные файлы для данной версии...

Либо библиотека.