Pure C++ delay load - Исходники

__>Я не про размер говорю.
__>Я имею ввиду что стоит сделать 2 версии классов CModule и CDynFunction.

Нет, по приведенным ранее причинам.

__>P.S.
__>Поговорим насчет стиля ?

Да ну, у каждого свои понятия красоты кода

Вот если таки хватит сил или общественность поддержит инициативу официального выкладывания этой поделки на RSDN — тогда уже будем все там править, что соответствовало тому, что принято на RSDN.
Впрочем, в любом случае — использоваться в 99% случаях будут только макросы, так что стиль оформления кода внутри наймспейса не так и важен, только из эстетических соображений. А мне текущий вариант более (или менее) нравится

Лучше еще что-нибудь по улучшению функционала придумать... Да вот не думается ничего

Здравствуйте, Andrew S, Вы писали:

__>>Я не про размер говорю.
__>>Я имею ввиду что стоит сделать 2 версии классов CModule и CDynFunction.

AS>Нет, по приведенным ранее причинам.

__>>P.S.
__>>Поговорим насчет стиля ?

AS>Да ну, у каждого свои понятия красоты кода

Само собой.
AS>Вот если таки хватит сил или общественность поддержит инициативу официального выкладывания этой поделки на RSDN — тогда уже будем все там править, что соответствовало тому, что принято на RSDN.
AS>Впрочем, в любом случае — использоваться в 99% случаях будут только макросы, так что стиль оформления кода внутри наймспейса не так и важен, только из эстетических соображений. А мне текущий вариант более (или менее) нравится

Если макросы будут, то это конечно не важно

Задача чтобы от них избавиться.

AS>Лучше еще что-нибудь по улучшению функционала придумать... Да вот не думается ничего

Уменьшит количество макросов.

__>Если макросы будут, то это конечно не важно

__>Задача чтобы от них избавиться.

Боюсь, что не получится. Во-первых, не поддерживается специализация строковым литералом. Приходится с макросами извращаться — никак иначе. Во-вторых — макросы заворачивают ненужные и нудные телодвижения (например, декларация глобального для объявления модуля в единице трансляции типа модуля). В данном случае без них было бы кисло.

AS>>Лучше еще что-нибудь по улучшению функционала придумать... Да вот не думается ничего

__>Уменьшит количество макросов.

Вариантов не вижу. Их вроде и так минимально возможное количество

Здравствуйте, Andrew S, Вы писали:

__>>Если макросы будут, то это конечно не важно

__>>Задача чтобы от них избавиться.

AS>Боюсь, что не получится. Во-первых, не поддерживается специализация строковым литералом. Приходится с макросами извращаться — никак иначе. Во-вторых — макросы заворачивают ненужные и нудные телодвижения (например, декларация глобального для объявления модуля в единице трансляции типа модуля). В данном случае без них было бы кисло.

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

Здравствуйте, Andrew S, Вы писали:

DL_USE_MODULE_END стоит изменить на:

#define DL_USE_MODULE_END() \
 };

__>DL_USE_MODULE_END стоит изменить на:

А в чем смысл, ну кроме необходимости ставить еще и () для макроса без параметров?

Здравствуйте, Andrew S, Вы писали:

__>>DL_USE_MODULE_END стоит изменить на:

AS>А в чем смысл, ну кроме необходимости ставить еще и () для макроса без параметров?

Однообразие.

DL_MODULE_BEGIN(...)

DL_MODULE_END()

Например карты сообщений в MFC и WTL сделанны так и оно смотрится лучше.
Я очень был удивлен что скобок не надо ставить.

__>Например карты сообщений в MFC и WTL сделанны так и оно смотрится лучше.

Это сильный аргумент

Ок, подумаю.

__>>Например карты сообщений в MFC и WTL сделанны так и оно смотрится лучше.

AS>Это сильный аргумент

Ок, подумаю.

Кстати, тут поступило предложение изменить макросы DL_DECLARE_FUN_xxx(name, ret, ...) на DL_DECLARE_FUN_xxx(ret, name, ...). Как общественность смотрит на это? С одной стороны, это вроде как больше походит на обычное С определение функции, с другой стороны, мне почему то более логичным кажется сначала указание имени импортируемой функции, а потом уже типов (может, просто привычка, конечно). Какие будут мнения? Если положительные, то последствия для тех мест, где используется старый вариант, я надеюсь, вы представляете

В общем, высказывайтесь. Я в сомнениях.

Здравствуйте, Andrew S, Вы писали:

AS>Итак, версия 1.09.

AS>Список изменений:

...

AS>Исходники доступны по адресу ниже.
AS>http://www.rsdn.ru/File/8583/delayimphlp.zip

AS>P.S. Как уже писалось ранее, есть мысль выложить все это в файлы в качестве отдельной библиотеки или функционала (с соотв. маленьким описанием классов, макросов и примером использования). Если общественность в виде титулованных rsdn'енеров поддержит это (т.е. сочтет данную библиотеку как минимум полезной) — можно будет устроить и это.

"Так они шептались целую неделю
и заодно делали большой железный сундук. Над ним трудились и
папа Карло, и Ферручино, и Буратино, который понемногу научился
мастерить. Артемон приносил различные железные предметы и ловко
смахивал хвостом металлические стружки. Мальвина шлифовала
готовые детали маленьким напильничком. Пьеро постукивал,
побрякивал, подтачивал, закручивал гаечки"

(c)Александр Кумма, Сакко Рунге. Вторая тайна золотого ключика

Милейший, если у вас есть какие то конкретные предложения по библиотеке, либо по функционалу — вперед. Если же нет — просьба не засорять подобными сообщениями эту ветку, для них есть специальные форумы. Заранее спасибо.

Fuz>

Fuz>"Так они шептались целую неделю
Fuz>и заодно делали большой железный сундук. Над ним трудились и
Fuz>папа Карло, и Ферручино, и Буратино, который понемногу научился
Fuz>мастерить. Артемон приносил различные железные предметы и ловко
Fuz>смахивал хвостом металлические стружки. Мальвина шлифовала
Fuz>готовые детали маленьким напильничком. Пьеро постукивал,
Fuz>побрякивал, подтачивал, закручивал гаечки"

Fuz>(c)Александр Кумма, Сакко Рунге. Вторая тайна золотого ключика

Здравствуйте, Andrew S, Вы писали:

AS>Милейший, если у вас есть какие то конкретные предложения по библиотеке, либо по функционалу — вперед. Если же нет — просьба не засорять подобными сообщениями эту ветку, для них есть специальные форумы. Заранее спасибо.

Не хотите, не буду... да и правила вроде не разрешают... просто расслабляться иногда тоже нужно.
Извините, если задел.

Fuz>Не хотите, не буду... да и правила вроде не разрешают... просто расслабляться иногда тоже нужно.

Не хочу. А вообще-то, до этого момента тут никто и не напрягался

Гм. Неожиданное обновление.

Выяснился один небольшой недостаток

— отсутствие поддержки функций без параметров.
Как реализовать это в рамках текущих макросов, я придумать не смог, в связи с чем пришлось добавить макросы с индексом 0... Если есть какие предложения по другой реализации всего этого — с интересом обсудим.

Итак, версия 1.1.0.

Список изменений:

Добавлены макросы для поддержки функций без параметров:
DL_DECLARE_FUN_0_ERR_POLICY
DL_DECLARE_FUN_0
DL_DECLARE_FUN_0_THROW
DL_DECLARE_FUN_0_ERR

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

To do

Багфиксы
Что то еще?

Исходники доступны по адресу ниже.
http://www.rsdn.ru/File/8583/delayimphlp.zip

Здравствуйте, Andrew S, Вы писали:

AS>Гм. Неожиданное обновление.

AS>Выяснился один небольшой недостаток

— отсутствие поддержки функций без параметров.

Есть еще как минимум один...
Поддержка UNICODE.

Я уже давно писал в этой теме, что GetProcAddress не принимает UNICODE строк.
Попробуйте в тестовом проекте поставить UNICODE вместо _MBCS.

AS>>Гм. Неожиданное обновление.

AS>>Выяснился один небольшой недостаток

— отсутствие поддержки функций без параметров.

MS>Есть еще как минимум один...
MS>Поддержка UNICODE.

MS>Я уже давно писал в этой теме, что GetProcAddress не принимает UNICODE строк.
MS>Попробуйте в тестовом проекте поставить UNICODE вместо _MBCS.

Так никто туда его и не передает. По крайней мере, не думал передавать — обратите внимание на макрос DECLARE_NAME_ID_A. Другое дело, что DL_GetProcAddressImpl пользовала LPCTSTR — это уже по недосмотру при оптимизации. Это я поправил, спасибо, а вот остальное вроде все работает. Так что ваше давнишнее замечание к этому багу никакого отношения не имеет.

Хм. Еще одно неожиданное обновление предыдущего обновления.

>>Выяснился один небольшой недостаток — отсутствие поддержки функций без параметров.
>>Как реализовать это в рамках текущих макросов, я придумать не смог, в связи с чем пришлось добавить макросы с индексом 0... Если есть какие >>предложения по другой реализации всего этого — с интересом обсудим.

Немного подумав, как обойтись, придумать смог

В процессе придумывания было найдено несколько новых багов 6-ки, так что если непонятно, почему сделано именно, так, а не проще — см. комменты.

Итак, версия 1.1.1.

Список изменений:

1. Функции без параметров представлены в виде функций с одим параметром типа void. То бишь объявлять их надо примерно так DL_DECLARE_FUN(имя, ret_type, (void))

2. Убраны макросы для поддержки функций без параметров за ненадобностью:
DL_DECLARE_FUN_0_ERR_POLICY
DL_DECLARE_FUN_0
DL_DECLARE_FUN_0_THROW
DL_DECLARE_FUN_0_ERR

To do

Багфиксы
Что то еще?

Исходники доступны по адресу ниже.
http://www.rsdn.ru/File/8583/delayimphlp.zip

Здравствуйте, Andrew S!
Есть вопрос по новой версии вашей библиотеки.
При компиляции в VC++ 7.1 на 4 уровне предупреждений мне постоянно генерируются
варнинги C4702 и C4100. Причем первый по нескольку раз, он сильно забивает трей, что немного раздражает.
Единственный способ который я нашол, это "закрыть" подключение библиотеки в прагмы:

#pragma warning(disable: 4702)
#pragma warning(disable: 4100)
#include <delayimphlp.h>
#pragma warning(default: 4100)
#pragma warning(default: 4702)

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

23W>

23W>#pragma warning(disable: 4702)
23W>#pragma warning(disable: 4100)
23W>#include <delayimphlp.h>
23W>#pragma warning(default: 4100)
23W>#pragma warning(default: 4702)
23W>

23W>Для меня это не выход, т.к. библиотека используюется в очень многих файлах. Можете что-то подсказать как избавиться от этих предупреждени ? Возможно, я неправильно формирую описание функций ?

Я в другой ветке ответил. У меня в 2003-м генерится только один варнинг (4702) на код

        static  ret_type MakeReturn()
        {
            TCHAR szMessage[DynFunction::name_type::length + 64];
            _stprintf(szMessage, _T("Can'n resolve procedure <%s>: %d"), DynFunction::name_type::GetStr(), GetLastError());
            throw E(szMessage);
            return ret_type();
        }

Очевидно, нормального способа запретить его, кроме как прагмой (что вы и делаете), нет. Можете поместить ее непосредственно в заголовок библиотеки.

Если у вас генерится 4100, то наверняка это в line 303

    static BOOL Free(HMODULE hModule)

Исправляется это просто:

    static BOOL Free(HMODULE /*hModule*/)

B повторюсь. На мой взгляд, 4-й уровень предупреждений ничего полезного не несет, самый удобный вариант — 3-й.
Удачи.

Здравствуйте, Andrew S.

Спасибо за ответ.
Что же будут блокировать предупреждения через прагмы, вносить имземения в Ваш код не буду (я не сторонник таких действий).

P.S.:
В другой ветке я просто не смог удалить свои старые вопросы, после того как нашел эту. Извините — ламер

От:	Andrew S	http://alchemy-lab.com
Дата:	09.09.04 12:56
Оценка:

От:	_nn_	www.nemerleweb.com
Дата:	09.09.04 17:42
Оценка:

От:	Andrew S	http://alchemy-lab.com
Дата:	13.09.04 07:28
Оценка:

От:	_nn_	www.nemerleweb.com
Дата:	13.09.04 08:29
Оценка:

От:	_nn_	www.nemerleweb.com
Дата:	13.09.04 09:02
Оценка:

От:	23W	http://kyselgov.pp.ua/
Дата:	19.07.05 10:11
Оценка:

	От:	Fuz
	Дата:	05.10.04 05:03
	Оценка:	-1

	От:	Fuz
	Дата:	05.10.04 07:30
	Оценка:

	От:	MShura
	Дата:	10.02.05 13:12
	Оценка: