Информация об изменениях

Сообщение Re[3]: side virtual method implementation от 14.02.2018 13:28

Изменено 22.04.2019 9:23 deleted2

Re[3]: side virtual method implementation
R>>Предлагаю сместить абстракцию ближе к клиентскому коду.
R>>Например, что-то типа:
R>>[ccode]
R>>class UniversalFeatures {
R>>#ifdef _WIN32
R>> WindowsFeatures
R>>#else
R>> MacOSFeatures
R>>#endif
R>> features;
R>> ...

CS>Не получится. Разные файлы .mm (MacOS Objective-C++) и .cpp для остальных.


Получится. Вместо #ifdef используются разные файлы. В своей ветке линкуются свои файлы, чужие даже не трогаются.
Это стандартный путь почти во всех кросс-платформенных библиотеках, какие я видел.
Objective-C++ не помеха для линковки. Оно понимает C++ и кросс-платформенный код никогда даже не узнает, что линкуется с mm.

R>>Только не virtual. Это не решит задачу разницу между платформами.

CS>Там не только между платформами. Например для Linux поддерживать три типа window backend: GTK/Gnome, KDE/Qt, XWindow... и все это в одном binary.

А как собираетесь решать проблему отсутствия требумых dll? Оно же не запустится, если не будет чего-то на машине.
Или все предполагается в рамках LSB стандарта?

R>>PS. Множественное наследование — зло. Лучше юзеру его не давать, внутри себя можно, но в классах, какие никогда не будут видны пользователю.

CS>Чего это? А как же COM ?

Оно же не видно пользователю. Видна только VMT, а что там с объектом, никого не волнует, поскольку обращения к полям только через методы.
Re[3]: side virtual method implementation
deleted