Про улучшение DLL

SashaMercury
Вчера я решил заняться чем-нибудь интересным.

Вот опять как и у автора topic возникает необходимость изобретать велосипед.
Сейчас разрабатываю library, которая будет предоставлять расширенный функционал при работе с dll файлами.
В частности:

- (1) производить demangle без использования UnDecorateSymbolName function http://msdn.microsoft.com/en-us/library/windows/desktop/ms681400(v=vs.85).aspx.

- (2) вызывать во время run-time работы программы на выполнение функции из произвольных dll

...

(1) нужен для того, чтобы получить данные об параметрах и возвращаемом значении функции
(2) думаю будет интересен многим /про свои потребности пока говорить не буду/

Для реализации (2) нужно знать все об аргументах функции и обязательно их size.
Для "стандартных" типов данных все относительно просто, а вот для "не стандартных" вопрос довольно не прост.
Пока еще не знаю путей его решения.
Текущая разрабатываемая ветка решения этого вопроса основывается на том, что алгоритм знает где находятся необходимые *.h.
Так вот придется парсить *.h и выуживать из них необходимые данные.

PS: Так как уже не один раз приходилось решать подобного рода задачи, то скорее всего придется изучить уже
кем-то изготовленные "велосипеды" llvm.org ...

Сейчас только приступаю к реализации (2) пункта ...

Владимир2012
/про свои потребности пока говорить не буду/

от потребностей решение зависит

Владимир2012
- (2) вызывать во время run-time работы программы на выполнение функции из произвольных dll Для реализации (2) нужно знать все об аргументах функции и обязательно их size. Для "стандартных" типов данных все относительно просто, а вот для "не стандартных" вопрос довольно не прост. Пока еще не знаю путей его решения.

Не всегда можно вызвать ф-ю из ДЛЛ, даже имея прототип.

Anatoly Moskovsky
Не всегда можно вызвать ф-ю из ДЛЛ, даже имея прототип

Безусловно. Тем более многие функции "работают" если для них подготовлена "среда обитания".

Суть данного проекта не в том, что этот механизм не реализован другими, а в том, чтобы
уменьшить трудоемкость возлагаемую на программиста при кодировании.

Поясню.
К примеру посмотрим на http://www.script-coding.com/dynwrapx.html /библиотека для вызова функций Win 32 API/
Решает вопрос?
Да.
Вообщем то как молоток и кувалда хороши если их применять тогда когда они наиболее полезны, так и это
решение безусловно очень полезно ...

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

PS: Вообще то лукавлю.
То что пытаюсь сделать будет иметь уменьшение трудоемкости в кодировании всего лишь как побочный эффект.

автор
Текущая разрабатываемая ветка решения этого вопроса основывается на том, что алгоритм знает где находятся необходимые *.h. Так вот придется парсить *.h и выуживать из них необходимые данные.

В чём проблема ?? Создайте свой синтаксический анализатор.
Тем более если вы программируете на С/С++.

Владимир2012
PS: Вообще то лукавлю. То что пытаюсь сделать будет иметь уменьшение трудоемкости в кодировании всего лишь как побочный эффект.

вы хотите сказать- "если я не буду писать анализатор своими руками, а скачаю какую-то библиотеку, реализующую то что нужно, то я добьюсь поставленной задачи и плюс минимизирую время на разработку." ?



Очевидно, это так.

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

K&R
Обращения к функциям, вложенные операции присваивания, операции увеличения и уменьшения приводят к так называемым "побочным эффектам" — некоторые переменные изменяются как побочный результат вычисления выражений.

Ещё ссылка

SashaMercury
вы хотите сказать- "если я не буду писать анализатор своими руками, а скачаю какую-то библиотеку, реализующую то что нужно, то я добьюсь поставленной задачи и плюс минимизирую время на разработку." ?

Ну да ладно приоткрою немножко свои потребности.
Данный проект в какой-то мере позволит решить вопрос создания программ, которые без
перекомпиляции смогут "на лету" использовать функции находящиеся в разных dll
/извиняюсь за некоторую корявость фразы .../.
Поясню.
Обычно программа использует какой-либо API, который реализован в каких-либо dll.
Так вот хочет добиться того, чтобы программа без перекомпиляции смогла бы использовать
аналогичные функции находящиеся в других dlls

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

Владимир2012,

То, что вы хотите, называется шаблон проектирования Адаптер.
И для его реализации вообще не нужны все эти извращения с анализом ДЛЛ.

Если вам надо работать с разными, но аналогичными АПИ, то надо ввести дополнительный уровень абстракции.
Назовите его Обертка.
Основная программа работает только с АПИ обертки, а оберток несколько и они реализуются в виде отдельных ДЛЛ, каждая из которых вызывает свое конкретное апи.
Таким образом для добавления нового АПИ вам не надо перекомпилировать программу, а надо только скомпилировать новую обертку и указать ее в конфиге программы.

Anatoly Moskovsky
, а надо только скомпилировать новую обертку и указать ее в конфиге программы.

Обратите внимание на post выше:

... Данный проект в какой-то мере позволит решить вопрос создания программ, которые без
перекомпиляции смогут "на лету" ...