Сообщение Re[2]: Интерфейс плагина и его vtable от 12.10.2017 10:21
Изменено 12.10.2017 10:59 AlexGin
Re[2]: Интерфейс плагина и его vtable
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, AlexGin, Вы писали:
AG>>А как бы сделалы Вы, уважаемые?
K>Если всё под винду, то я бы выбрал скорее всего COM, а всю сложность работы с ним спрятал в билдовую систему и заствил/научил всех использовать АТЛ.
Пока под винду, но мы используем Qt 5.9 и в перспективе можем перейти на кроссплатформу (Linux: Ubuntu, Debian).
Насчёт билдовой системы: работаем с QMake, которую можно применять как в родном для неё QtCreator, так и в MSVC (через QtAddin).
На данной стадии проекта применять что-то другое не планируем.
AG>>COM добавляет лишние сложности там, где их совсем даже не требуется.
K>Где, например?
Как в своих основах:
1) Базовый интрефейс IUnknown (вот: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx )
имеет в своём составе вирт-методы AddRef и Release. Да, в 1990-х это было актуально, однако теперь,
когда уже есть официально признанный std::shared_ptr ИМХО идея IUnknown потеряла всякую актуальность.
2) Лишнее наследование, совсем не продиктованное требованиями прикладной задачи, — также оверхед.
Так и в реализации:
a) Генерация сущностей в виде GUID, призванная исключить "DLL hell", кажется мне всё таки избыточной, за исключением ситуации —
если мы компания уровня M$, предлагающая свои продукты миллиардной аудитории
b) Язык определения интерфейсов MIDL ( https://msdn.microsoft.com/en-us/library/windows/desktop/aa367091(v=vs.85).aspx ) также
лишняя (в конетксте прикладных задач) сущность. Её наличие только усложняет коды проекта.
c) Поддержка и развитие проектов на базе COM куда более трудозатратная, чем без COM.
Здесь я подразумеваю как все пользовательские действия (в той же студии), котрые направлены на поддержку инфраструктуры COM, однако,
не актуальны (от слова совсем) для прикладной задачи; так и процесс сопровождения (документация по проекту и её поддержка).
Кроме всего этого, я (как тимлид) применяя COM должен набрать в мою рабочую группу людей, владеющих данной (ныне не актуальной) технологией,
или обучить существующую команду работой с нею. Это также — лишние телодвижения
P.S. Да, первоначельная идея — сделать COM компонент и применять в разных языковых средах (C, C++, VB) —
зародившаяся примерно четверть века назад, была революционна, но теперь идея актуальность потеряла, а излишняя сложность — осталась
K>Здравствуйте, AlexGin, Вы писали:
AG>>А как бы сделалы Вы, уважаемые?
K>Если всё под винду, то я бы выбрал скорее всего COM, а всю сложность работы с ним спрятал в билдовую систему и заствил/научил всех использовать АТЛ.
Пока под винду, но мы используем Qt 5.9 и в перспективе можем перейти на кроссплатформу (Linux: Ubuntu, Debian).
Насчёт билдовой системы: работаем с QMake, которую можно применять как в родном для неё QtCreator, так и в MSVC (через QtAddin).
На данной стадии проекта применять что-то другое не планируем.
AG>>COM добавляет лишние сложности там, где их совсем даже не требуется.
K>Где, например?
Как в своих основах:
1) Базовый интрефейс IUnknown (вот: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx )
имеет в своём составе вирт-методы AddRef и Release. Да, в 1990-х это было актуально, однако теперь,
когда уже есть официально признанный std::shared_ptr ИМХО идея IUnknown потеряла всякую актуальность.
2) Лишнее наследование, совсем не продиктованное требованиями прикладной задачи, — также оверхед.
Так и в реализации:
a) Генерация сущностей в виде GUID, призванная исключить "DLL hell", кажется мне всё таки избыточной, за исключением ситуации —
если мы компания уровня M$, предлагающая свои продукты миллиардной аудитории
b) Язык определения интерфейсов MIDL ( https://msdn.microsoft.com/en-us/library/windows/desktop/aa367091(v=vs.85).aspx ) также
лишняя (в конетксте прикладных задач) сущность. Её наличие только усложняет коды проекта.
c) Поддержка и развитие проектов на базе COM куда более трудозатратная, чем без COM.
Здесь я подразумеваю как все пользовательские действия (в той же студии), котрые направлены на поддержку инфраструктуры COM, однако,
не актуальны (от слова совсем) для прикладной задачи; так и процесс сопровождения (документация по проекту и её поддержка).
Кроме всего этого, я (как тимлид) применяя COM должен набрать в мою рабочую группу людей, владеющих данной (ныне не актуальной) технологией,
или обучить существующую команду работой с нею. Это также — лишние телодвижения
P.S. Да, первоначельная идея — сделать COM компонент и применять в разных языковых средах (C, C++, VB) —
зародившаяся примерно четверть века назад, была революционна, но теперь идея актуальность потеряла, а излишняя сложность — осталась
Re[2]: Интерфейс плагина и его vtable
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, AlexGin, Вы писали:
AG>>А как бы сделалы Вы, уважаемые?
K>Если всё под винду, то я бы выбрал скорее всего COM, а всю сложность работы с ним спрятал в билдовую систему и заствил/научил всех использовать АТЛ.
Пока под винду, но мы используем Qt 5.9 и в перспективе можем перейти на кроссплатформу (Linux: Ubuntu, Debian).
Насчёт билдовой системы: работаем с QMake, которую можно применять как в родном для неё QtCreator, так и в MSVC (через QtVsAddin).
На данной стадии проекта применять что-то другое, кроме данного простого решения, не планируем.
AG>>COM добавляет лишние сложности там, где их совсем даже не требуется.
K>Где, например?
Как в своих основах:
1) Базовый интрефейс IUnknown (вот: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx )
имеет в своём составе вирт-методы AddRef и Release. Да, в 1990-х это было актуально, однако теперь,
когда уже есть официально признанный std::shared_ptr ИМХО идея IUnknown потеряла всякую актуальность.
2) Лишнее наследование, совсем не продиктованное требованиями прикладной задачи, — также оверхед.
Так и в реализации:
a) Генерация сущностей в виде GUID, призванная исключить "DLL hell", кажется мне всё таки избыточной, за исключением ситуации —
если мы компания уровня M$, предлагающая свои продукты миллиардной аудитории
b) Язык определения интерфейсов MIDL ( https://msdn.microsoft.com/en-us/library/windows/desktop/aa367091(v=vs.85).aspx ) также
лишняя (в конетксте прикладных задач) сущность. Её наличие только усложняет коды проекта.
c) Поддержка и развитие проектов на базе COM куда более трудозатратная, чем без COM.
Здесь я подразумеваю как все пользовательские действия (в той же студии), котрые направлены на поддержку инфраструктуры COM, однако,
не актуальны (от слова совсем) для прикладной задачи; так и процесс сопровождения (документация по проекту и её поддержка).
Кроме всего этого, я (как тимлид) применяя COM должен набрать в мою рабочую группу людей, владеющих данной (ныне не актуальной) технологией,
или обучить существующую команду работой с нею. Это также — лишние телодвижения
P.S. Да, первоначельная идея — сделать COM компонент и применять в разных языковых средах (C, C++, VB) —
зародившаяся примерно четверть века назад, была революционна, но теперь идея актуальность потеряла, а излишняя сложность — осталась
K>Здравствуйте, AlexGin, Вы писали:
AG>>А как бы сделалы Вы, уважаемые?
K>Если всё под винду, то я бы выбрал скорее всего COM, а всю сложность работы с ним спрятал в билдовую систему и заствил/научил всех использовать АТЛ.
Пока под винду, но мы используем Qt 5.9 и в перспективе можем перейти на кроссплатформу (Linux: Ubuntu, Debian).
Насчёт билдовой системы: работаем с QMake, которую можно применять как в родном для неё QtCreator, так и в MSVC (через QtVsAddin).
На данной стадии проекта применять что-то другое, кроме данного простого решения, не планируем.
AG>>COM добавляет лишние сложности там, где их совсем даже не требуется.
K>Где, например?
Как в своих основах:
1) Базовый интрефейс IUnknown (вот: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx )
имеет в своём составе вирт-методы AddRef и Release. Да, в 1990-х это было актуально, однако теперь,
когда уже есть официально признанный std::shared_ptr ИМХО идея IUnknown потеряла всякую актуальность.
2) Лишнее наследование, совсем не продиктованное требованиями прикладной задачи, — также оверхед.
Так и в реализации:
a) Генерация сущностей в виде GUID, призванная исключить "DLL hell", кажется мне всё таки избыточной, за исключением ситуации —
если мы компания уровня M$, предлагающая свои продукты миллиардной аудитории
b) Язык определения интерфейсов MIDL ( https://msdn.microsoft.com/en-us/library/windows/desktop/aa367091(v=vs.85).aspx ) также
лишняя (в конетксте прикладных задач) сущность. Её наличие только усложняет коды проекта.
c) Поддержка и развитие проектов на базе COM куда более трудозатратная, чем без COM.
Здесь я подразумеваю как все пользовательские действия (в той же студии), котрые направлены на поддержку инфраструктуры COM, однако,
не актуальны (от слова совсем) для прикладной задачи; так и процесс сопровождения (документация по проекту и её поддержка).
Кроме всего этого, я (как тимлид) применяя COM должен набрать в мою рабочую группу людей, владеющих данной (ныне не актуальной) технологией,
или обучить существующую команду работой с нею. Это также — лишние телодвижения
P.S. Да, первоначельная идея — сделать COM компонент и применять в разных языковых средах (C, C++, VB) —
зародившаяся примерно четверть века назад, была революционна, но теперь идея актуальность потеряла, а излишняя сложность — осталась