Графический контрол в dll

Всем, привет!

Ковыряясь в стороннем коде (в частности в dll) - заметил одну странность: очень часто разработчики не оформляют графический контрол, как activeX или просто COM-объект. То есть все методы контрола доступны через секцию экспорта dll.

Почитав в интернете соответствующую литературу попытался найти основания для этого. В основном мотивируют тем, что COM много жрёт памяти и быстродействия. Но что насчёт гибкости в использовании? Сейчас пишу заголовочные файлы для этого контрола, чтоб подцепить его к своей программе на delphi, оттестировать правильность заголовочных файлов и безболезненно заменить этот контрол на свой в основной программе.

Контрол, который я мучаю отвечает за рисование графика с биржевой информацией (цена, объём, дата) средствами winapi. загружается в основной программе, как обычный плагин - через loadlibrary-getprocaddress. если основная программа не находит нужную dll - ничего страшного не присходит - просто возможность строить графики в программе пропадает.

Собственно, вопрос: почему разработчики пошли по этому пути? почему нельзя было всё это сделать на COM? Сейчас, чтоб построить 30 графиков у меня сжирается основной программой около 300МБайт. Ладно хоть период обновления биржевой информации 1 сек, а если бы был 0,1сек вообще труба.
Или разработчики боятся, что их контрол быстрее "стащить" если использовать COM?

0

думаю они сделали так что бы люди или среды разработки испытывающие проблемы с COM могли тоже к ним подцепиться. не более того. просто DLL могут пользоваться очень многие (не так много как следовало бы, но все таки). а вот COM...

0

Сообщение от vxg думаю они сделали так что бы люди или среды разработки испытывающие проблемы с COM могли тоже к ним подцепиться. не более того. просто DLL могут пользоваться очень многие (не так много как следовало бы, но все таки). а вот COM...

данный контролл является закрытым - разработчики не разглашают заголовочные файлы к нему

0

это сути не меняет. они просто озаботились теми людьми которые не переносят COM и сразу предоставили им (а может себе - неясно что было первым в проекте - DLL или COM-обертка) большее (на любителя) удобство (и в узком случае - скорость) работы.

0

Наконец, нашёл разумный ответ на свой вопрос:

Сообщение от sam063rus Собственно, вопрос: почему разработчики пошли по этому пути? почему нельзя было всё это сделать на COM? Сейчас, чтоб построить 30 графиков у меня сжирается основной программой около 300МБайт. Ладно хоть период обновления биржевой информации 1 сек, а если бы был 0,1сек вообще труба. Или разработчики боятся, что их контрол быстрее "стащить" если использовать COM?

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

И главное:

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



________________________
ТЕМА ЗАКРЫТА

0

Сообщение от sam063rus компилятор будет вынужден полностью включить в его состав также код родительского класса

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

Сообщение от sam063rus Вызов методов класса производится через таблицу, что увеличивает время вызова

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

Сообщение от sam063rus вызов проходит через десять таблиц

фигня. таблица всегда одна - с ростом родословной у нее просто хвост растет.

Сообщение от sam063rus Писать программы придется только на чистом api

в принципе да, но у ООП своя ниша. иногда архитектура программы получается настолько своеобразной, что в api человек просто утонет.

Добавлено через 15 секунд

Сообщение от sam063rus компилятор будет вынужден полностью включить в его состав также код родительского класса

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

Сообщение от sam063rus Вызов методов класса производится через таблицу, что увеличивает время вызова

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

Сообщение от sam063rus вызов проходит через десять таблиц

фигня. таблица всегда одна - с ростом родословной у нее просто хвост растет.

Сообщение от sam063rus Писать программы придется только на чистом api

в принципе да, но у ООП своя ниша. иногда архитектура программы получается настолько своеобразной, что в api человек просто утонет.

0