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

untyped · Регистрация: 18.08.2012

Author24 — интернет-сервис помощи студентам

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

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

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

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

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

@vxg · 20.08.2012, 09:54

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

untyped · 21.08.2012, 09:07 **[ТС]**

Сообщение от vxg

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

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

@vxg · 21.08.2012, 09:46

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

untyped · 08.01.2013, 05:50 **[ТС]**

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

Сообщение от sam063rus

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

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

И главное:

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

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

@vxg · 08.01.2013, 12:51

Сообщение от sam063rus

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

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

Сообщение от sam063rus

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

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

Сообщение от sam063rus

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

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

Сообщение от sam063rus

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

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

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

Сообщение от sam063rus

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

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

Сообщение от sam063rus

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

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

Сообщение от sam063rus

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

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

Сообщение от sam063rus

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

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

Новые блоги и статьи
Какой локальный веб-сервер выбрать InfoMaster 19.01.2025 В современной веб-разработке локальные веб-серверы играют ключевую роль, предоставляя разработчикам надежную среду для создания, тестирования и отладки веб-приложений без необходимости использования. . .	Почему планшеты и iPad уже не так популярны, как раньше InfoMaster 19.01.2025 Эра революционных инноваций История планшетных компьютеров началась задолго до того, как эти устройства стали привычными спутниками нашей повседневной жизни. В начале 1990-х годов появились первые. . .	Как самому прошить BIOS ноутбука InfoMaster 19.01.2025 BIOS (Basic Input/ Output System) представляет собой важнейший компонент любого компьютера или ноутбука, который обеспечивает базовое взаимодействие между аппаратным и программным обеспечением. . .	Какой Linux выбрать для домашнего компьютера InfoMaster 19.01.2025 Современные реалии выбора операционной системы В современном мире выбор операционной системы для домашнего компьютера становится все более важным решением, которое может существенно повлиять на. . .	Как объединить два словаря одним выражением в Python InfoMaster 19.01.2025 В мире программирования на Python работа со словарями является неотъемлемой частью разработки. Словари представляют собой мощный инструмент для хранения и обработки данных в формате "ключ-значение". . . .	Как без исключения проверить существование файла в Python InfoMaster 19.01.2025 При разработке программного обеспечения на Python часто возникает необходимость проверить существование файла перед выполнением операций с ним. Это критически важная задача, которая помогает избежать. . .
Как определить, содержит ли строка подстроку в JavaScript InfoMaster 19.01.2025 При разработке веб-приложений часто возникает необходимость выполнять различные операции со строками, среди которых особое место занимает поиск подстрок. JavaScript предоставляет несколько встроенных. . .	Что такое метаклассы в Python InfoMaster 19.01.2025 Метаклассы в Python представляют собой один из самых мощных и одновременно сложных механизмов языка, позволяющий программистам контролировать процесс создания классов. По своей сути, метакласс. . .	Как удалить свойство из объекта JavaScript InfoMaster 19.01.2025 В современной веб-разработке объекты JavaScript играют фундаментальную роль в организации и структурировании данных. Они представляют собой контейнеры, которые хранят связанные данные и. . .	Какая разница между String и string в C# InfoMaster 19.01.2025 В языке программирования C# существует интересная особенность: для работы со строками можно использовать как String, так и string. Эта двойственность часто вызывает вопросы у разработчиков, особенно. . .	Как в Git откатить репозиторий к предыдущему коммиту InfoMaster 19.01.2025 В современной разработке программного обеспечения система контроля версий Git стала неотъемлемой частью рабочего процесса, предоставляя разработчикам мощные инструменты для управления изменениями в. . .	Как работают замыкания (closure) в JavaScript InfoMaster 19.01.2025 В мире современной веб-разработки замыкания (closures) представляют собой один из фундаментальных концептов языка JavaScript, который часто вызывает затруднения у начинающих разработчиков, но при. . .

untyped 531 / 180 / 39 Регистрация: 18.08.2012 Сообщений: 907
		1
	Графический контрол в dll 18.08.2012, 14:36. Показов 1809. Ответов 5 Метки нет (Все метки) *Всем, привет!* Ковыряясь в стороннем коде (в частности в dll) - заметил одну странность: очень часто разработчики не оформляют графический контрол, как activeX или просто COM-объект. То есть все методы контрола доступны через секцию экспорта dll. Почитав в интернете соответствующую литературу попытался найти основания для этого. В основном мотивируют тем, что COM много жрёт памяти и быстродействия. Но что насчёт гибкости в использовании? Сейчас пишу заголовочные файлы для этого контрола, чтоб подцепить его к своей программе на delphi, оттестировать правильность заголовочных файлов и безболезненно заменить этот контрол на свой в основной программе. Контрол, который я мучаю отвечает за рисование графика с биржевой информацией (цена, объём, дата) средствами winapi. загружается в основной программе, как обычный плагин - через loadlibrary-getprocaddress. если основная программа не находит нужную dll - ничего страшного не присходит - просто возможность строить графики в программе пропадает. Собственно, вопрос: почему разработчики пошли по этому пути? почему нельзя было всё это сделать на COM? Сейчас, чтоб построить 30 графиков у меня сжирается основной программой около 300МБайт. Ладно хоть период обновления биржевой информации 1 сек, а если бы был 0,1сек вообще труба. Или разработчики боятся, что их контрол быстрее "стащить" если использовать COM? 0

@vxg Модератор 3401 / 2172 / 353 Регистрация: 13.01.2012 Сообщений: 8,422
	20.08.2012, 09:54	2
	думаю они сделали так что бы люди или среды разработки испытывающие проблемы с COM могли тоже к ним подцепиться. не более того. просто DLL могут пользоваться очень многие (не так много как следовало бы, но все таки). а вот COM... 0

untyped 531 / 180 / 39 Регистрация: 18.08.2012 Сообщений: 907
	21.08.2012, 09:07 [ТС]	3
	Сообщение от vxg думаю они сделали так что бы люди или среды разработки испытывающие проблемы с COM могли тоже к ним подцепиться. не более того. просто DLL могут пользоваться очень многие (не так много как следовало бы, но все таки). а вот COM... данный контролл является закрытым - разработчики не разглашают заголовочные файлы к нему 0

@vxg Модератор 3401 / 2172 / 353 Регистрация: 13.01.2012 Сообщений: 8,422
	21.08.2012, 09:46	4
	это сути не меняет. они просто озаботились теми людьми которые не переносят COM и сразу предоставили им (а может себе - неясно что было первым в проекте - DLL или COM-обертка) большее (на любителя) удобство (и в узком случае - скорость) работы. 0

untyped 531 / 180 / 39 Регистрация: 18.08.2012 Сообщений: 907
	08.01.2013, 05:50 [ТС]	5
	Наконец, нашёл разумный ответ на свой вопрос: Сообщение от sam063rus Собственно, вопрос: почему разработчики пошли по этому пути? почему нельзя было всё это сделать на COM? Сейчас, чтоб построить 30 графиков у меня сжирается основной программой около 300МБайт. Ладно хоть период обновления биржевой информации 1 сек, а если бы был 0,1сек вообще труба. Или разработчики боятся, что их контрол быстрее "стащить" если использовать COM? Процитирую его с другого сайта: ...Допустим, у нас есть класс, наследуемый от другого класса. При создании объекта этого класса компилятор будет вынужден полностью включить в его состав также код родительского класса, поскольку нет возможности определить, какие методы классов использоваться не будут. Если у нас целое дерево наследования классов, как обычно и бывает в реальных программах, то весь его код войдет в программу, и от этого никуда не денешься. Вызов методов класса производится через таблицу, что увеличивает время вызова. А когда метод наследуется от родителя в десятом поколении, то и вызов проходит через десять таблиц, прежде чем достигает обрабатывающего его кода. Получается, что вместе с кучей мертвого кода мы получаем еще низкую эффективность рабочего.... И главное: ...Те, кто хочет добиться действительно высокой эффективности кода, должны идти по принципиально другому пути: забыть про ООП и все, что с ним связано, раз и навсегда. Писать программы придется только на чистом api... ________________________ ТЕМА ЗАКРЫТА 0

@vxg Модератор 3401 / 2172 / 353 Регистрация: 13.01.2012 Сообщений: 8,422
	08.01.2013, 12:51	6
	Сообщение от sam063rus компилятор будет вынужден полностью включить в его состав также код родительского класса хм. в DLL тоже включаются все функции ибо мы не знаем какие из них пригодятся человеку. Сообщение от sam063rus Вызов методов класса производится через таблицу, что увеличивает время вызова фигня. таблица есть, но увеличение времени затрачиваемого на вызов по сравнению с вызовом обычного метода равно времени доступа к элементу массива указателей на функции. а это почти ноль. Сообщение от sam063rus вызов проходит через десять таблиц фигня. таблица всегда одна - с ростом родословной у нее просто хвост растет. Сообщение от sam063rus Писать программы придется только на чистом api в принципе да, но у ООП своя ниша. иногда архитектура программы получается настолько своеобразной, что в api человек просто утонет. Добавлено через 15 секунд Сообщение от sam063rus компилятор будет вынужден полностью включить в его состав также код родительского класса хм. в DLL тоже включаются все функции ибо мы не знаем какие из них пригодятся человеку. Сообщение от sam063rus Вызов методов класса производится через таблицу, что увеличивает время вызова фигня. таблица есть, но увеличение времени затрачиваемого на вызов по сравнению с вызовом обычного метода равно времени доступа к элементу массива указателей на функции. а это почти ноль. Сообщение от sam063rus вызов проходит через десять таблиц фигня. таблица всегда одна - с ростом родословной у нее просто хвост растет. Сообщение от sam063rus Писать программы придется только на чистом api в принципе да, но у ООП своя ниша. иногда архитектура программы получается настолько своеобразной, что в api человек просто утонет. 0

Опции темы