Pull to refresh

Comments 20

Мне кажется вы слишком усложнили себе жизнь, этот подход мало чем отличается от обычного через typedef.
Если же идти вашим методом, то могли бы имя функции передовать в конструктор и там уже вызывать GetProcAddress().
В отличие от использования указателя, я могу неявно контролировать нулевой указатель.
Что касается указания имени функции в параметре шаблона — мне это тут как раз неудобно, т. к. мне надо явно указать момент вызова GetProcAddress. Конструктор тут не подходит.
В отличие от использования указателя, я могу неявно контролировать нулевой указатель.
Что касается указания имени функции в параметре шаблона — мне это тут как раз неудобно, т. к. мне надо явно указать момент вызова GetProcAddress. Конструктор тут не подходит.
UFO just landed and posted this here
1 — ну-у, не знаю, я написал четко по стандарту. Если уж не обрабатывать ситуацию неверного указателя, то прав Airog, проще использовать typedef.
2, 3 — я не задумывал этот класс как нечто универсальное… Просто надоели кучи typedef-ов, захотелось Сpp-шнуть… Надо думать.
4 — я сам не дружу с тем и другим…

Да, за source я уже сам увидел
Эцсамое, а что конкретно помешало прилинковать либу через секцию импорта как все нормальные люди? Насколько я помню, это достаточно тривиальное занятие.
Не всегда это допустимо. Скажем, я делаю систему регистрации каких-нибудь данных и их интерпретации. При этом используются разные способы вывода. Очевидно — делаю базовый класс с функцией «нарисовать» и «настроить вывод». А потом подключаю DLL-ки с конкретными реализациями. А там какие-то DLL-ки подходят, какие-то нет. А там пользователь нашел еще чего-нибудь.
Я обычно в таких случаях экспортирую 1 функу, которая возвращает указатель на реализацию интерфейса, а дальше программа и либа через этот интерфейс общаются. Можно прикрутить базовую поддержку COM, реализовав заодно IUnknown (можно даже вручную, это не сложно, у меня даже где-то валяется примитивный шаблонный класс и набор макросов под это дело.
UFO just landed and posted this here
Э-э, в Boost-е, в смысле?.. Или в STL?
UFO just landed and posted this here
А можно подробней в чём проблема автоматической линковки?
Здесь речь идёт не о автоматической линковке, а о динамической. Мы сами делаем LoadLibrary, а не операционная система за нас.
Хотя, сорри, да, не заметил в самом начале, что были проблемы, именно, с автоматической линковкой.
Я уже не помню подробно. Факт в том, что пол дня промучился, плюнул и сделал такой вот код
Дело в том, что сама по себе обёртка может быть полезна и приятна. Например для использования «uxtheme.dll» — поддержка theme, которая появилась в XP, но не было в предыдущих версиях windows часто использовали подобный код (впрочем, проще это решается использованием delayed load).

В данном случае это просто ненужные костыли. Дело даже не в оверхеде вызова, а в том, что «я не разобрался как надо делать, поэтому сделал свой велосипед».

Конечно, иногда возникают проблемы с линковкой динамических библиотек (из-за name mangling например), но они проще решаются написанием соответствующего .def-файла.
В общем-то, не спорю — в итоге я все-таки разобрался с этим вопросом… Но не выкидывать же все-таки результат!
Как насчёт такой штуки?
#define Func0(ret) ret (*)()
#define Func1(ret, arg1) ret (*)(arg1)
#define Func2(ret, arg1, arg2) ret (*)(arg1, arg2)

А потом в коде:
Func0(int) f1 = GetProcAddress (hMod, «f1»); // int f1();
Func1(int,int) f2 = GetProcAddress (hMod, «f2»); // int f2(int);

Правда я без учета исключений и т.д.
Во-первых, это действительно без исключений. Во-вторых, я не вижу спецификации возвращаемого функцией типа
Возвращаемый тип идет первым параметром. Конечно, так получается меньше проверок на уровне синтаксического анализа, но так в сотню раз быстрее, чем создавать шаблон. Но раз уж шаблон существует — то может он и удобнее.
Sign up to leave a comment.

Articles