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

В данном случае это вполне правильный подход. То, что возможно ведет к 4100, я поправил и выложил на сайт — http://gzip.rsdn.ru/File/8583/delayimphlp.zip

Андрей, может Вы тогда и исправите предупреждение С4702 ?
Генерируется оно тут CFunProxyThrowPolicy::FunctionTrait метод MakeReturn строка 467

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();  // ТУТ генерируется С4702
}

Судя потому, что там написано, return действительно лишний. Без него VC++ 7.1 компилирует это код без ошибок и предупреждений. Я понимаю что библиотека универсальная. Но может следует внести некоторые изменения, например так:

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);
#if (_MSC_VER<1300) || !defined(_MSC_VER)
    return ret_type();
#endif
}

Такой код вроде бы не разрушает логики библиотеки и не приводит к неприятностям с варнингами.

P.S.:
Ну и не забудьте поднять верисю до 1.1.2

23W>Такой код вроде бы не разрушает логики библиотеки и не приводит к неприятностям с варнингами.

Я попробовал на VC6, там тоже без это строчки компилится. Думаю, можно просто ее закомментить.
Выложил в файлы.

Андрей, огромное СПАСИБО.
У меня все компилируется, ошибок и предупреждений нет.
Теперь легко перешел на новую версию.
Библиотека просто класс!

23W>Андрей, огромное СПАСИБО.
23W>У меня все компилируется, ошибок и предупреждений нет.
23W>Теперь легко перешел на новую версию.

Вам тоже спасибо — несколькими недочетами, хоть и мелкими, но стало меньше.

Успехов.

И сново здравствуйте!
Андрей, Вы будете смеяться, но дождавшись наконец-то полного ребилдинга проекта
я заметил еще один варнинг (он тоже из области 4-го уровня).Это C4512!
Проявляется он далеко не всегда, напримерм у меня в проекте есть несеколько модулей оптимизированные под
высокую производительность, поэтому они не искрользуют никаких библиотек, кроме некоторых шаблонов STL, и
в настройки этих подпроэктов выкручены "по максимуму".
Так вот в этих модулях, зачем-то компилятор начинает меня предупреждать что
для структуры CLWMutex и шаблона CAutoLock<T> невозможно автоматически сгенерировать оператор присваивания.
При этом сам оператор в явном виде нигде не вызывается. Я уже слышал про такую особенность VC++ 7.1 и встерчался
с ней в своем коде. Дело в том что этот "умный" компилятор хочет в некоторых местах "соптимизировать" использование
структур и не может это сделать т.к. не может автоматически сгенерировать этот самый оператор (из-за наличия ссылок внутри класса или структуры). После этого он работает как положено, т.е. ошибкой или потенциальной ошибкой это не
считается. Но осадок остался
Во многих форумах встречал такой способ отучить компилятор от глупостей — объявить в приватной секции класса или шаблона конструктор копирования и оператор присваивания, но не реализовывать их. Причем этот способ не влияет на другие компиляторы и дает возможность компилятору "догадатся" что для данного класса или структуры запрещено явное и неявное копирование. В своем коде я делал такое не раз — работает.
В соответствии с этим я, набравшись наглости, модифицировал Ваши классы так:

#ifdef DL_MT
//  MT only
struct CLWMutex
{
    CLWMutex(volatile LONG &pFlag):m_pFlag(pFlag)
    {
    }
    void Lock()
    {
        while(::InterlockedExchange(&m_pFlag, TRUE))
            ::Sleep(1);
    }
    void Unlock()
    {
        ::InterlockedExchange(&m_pFlag, FALSE);
    }
    volatile LONG &m_pFlag;

private:
    // private section with blocked explicit/implicit assignments
    CLWMutex( const CLWMutex& ) throw();
    CLWMutex operator=( const CLWMutex& ) throw();
};

template<class T>
struct CAutoLock
{
    CAutoLock(T& obj):m_objLock(obj)
    {
        m_objLock.Lock();
    }
    ~CAutoLock()
    {
        m_objLock.Unlock();
    }
    T &m_objLock;


private:
    // private section with blocked explicit/implicit assignments
    CAutoLock( const CAutoLock& ) throw();
    CAutoLock operator=( const CAutoLock& ) throw();
};

#endif //DL_MT

Это мизерные правки кода, если сочтете нужным — измените исходники и Вашего варианта.

С уважением, 23W

23W>И сново здравствуйте!
23W>Андрей, Вы будете смеяться, но дождавшись наконец-то полного ребилдинга проекта
23W>я заметил еще один варнинг (он тоже из области 4-го уровня).Это C4512!

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

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

Библиотека классная.

Есть одно очень МАЛЕНЬКОЕ замечание

в строке 478 формируется сообщение "Can'n resolve procedure <%s>: %d".

Мне кажется что должно быть так "Can't resolve procedure <%s>: %d".

A>Библиотека классная.
A>Есть одно очень МАЛЕНЬКОЕ замечание
A>в строке 478 формируется сообщение "Can'n resolve procedure <%s>: %d".
A>Мне кажется что должно быть так "Can't resolve procedure <%s>: %d".

Ага, точно. Этот баг фиксился несколько раз, но, как феникс, он постоянно возрождался от версии к версии Вот и сейчас.
Выложил в файлы исправленный вариант. http://gzip.rsdn.ru/File/8583/delayimphlp.zip
Спасибо за замечание.

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

AS>Ага, точно. Этот баг фиксился несколько раз, но, как феникс, он постоянно возрождался от версии к версии Вот и сейчас.



Еще вопросик в тему: в вашей статье нигде не упоминается про лицензию? есть какие-нибудь ограничения на использования вашей библиотеки в коммерческих проектах?

AS>>Ага, точно. Этот баг фиксился несколько раз, но, как феникс, он постоянно возрождался от версии к версии Вот и сейчас.

A>

A>Еще вопросик в тему: в вашей статье нигде не упоминается про лицензию? есть какие-нибудь ограничения на использования вашей библиотеки в коммерческих проектах?
Иначе был бы смысл выкладывать ее в общий доступ... Конечно, нет ограничений, по крайней мере, с моей стороны — пользуйте, изменяйте и улучшайте на здоровье. Если какие баги\улучшательства найдете — пишите, поправим\добавим в новые версии.

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

A>>Еще вопросик в тему: в вашей статье нигде не упоминается про лицензию? есть какие-нибудь ограничения на использования вашей библиотеки в коммерческих проектах?
AS>Иначе был бы смысл выкладывать ее в общий доступ... Конечно, нет ограничений, по крайней мере, с моей стороны — пользуйте, изменяйте и улучшайте на здоровье. Если какие баги\улучшательства найдете — пишите, поправим\добавим в новые версии.

Ок. Спасибо.

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

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

1. Немного изменены макросы DL_REPEAT_XXXX Теперь нумерация параметров начинается с 0, а не с 1. Для совместимости с бустом. На внешнем интерфейсе библиотеки это никак не отразилось.
2. Расширен список поддерживаемых компиляторов: добавлена возможность вместо предлагаемой библиотекой реализации использовать порождающие макросы от boost::preprocessor. Для этого надо в свойствах проекта или же перед включением заголовка библиотеки определить макрос

#define DL_USE_BOOST_PP

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

To do

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

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

Версия 1.2.0

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

1. Генерируемые макросами типы, надобные для внутренних нужд библиотеки, находятся теперь в наймспейсе internal_types. Т.о., чтобы добраться до типа модуля, надо теперь писать нечто вроде module_name::internal_types::module_type. Решение, в принципе, спорное — если есть аргументы за\против, можно пообсуждать.
2. Добавлены макросы DL_UNLOAD_MODULE(nmspace) и DL_RESET_FUN(nmspace, name_id). Первый выгружает модуль, а второй приводит функцию в состояние до загрузки (т.е. при следующем ее вызове опять будет вызван прокси-объект). Понадобится это может, например, если необходимо выгрузить и опять загрузить библиотеку, хотя и будет выглядеть довольно муторно. Если есть лучшие предложения — можно обсудить.
3. Багфиксы юникодной конфигурации (за это отдельное спасибо Вечяславу).
4. Новый пример.

To do

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

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

Спасибо за новую версию.

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

AS>Версия 1.2.0

Скачал новую версию. Компилирую. Запускаю прогу. При загрузке функции получаю Debug Error:

...
File: delayimphlp.h
Line: 611

Run-Time Check Failure #0 — The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling conversion with a function pointer declared with a different calling conversion.

Abort Ignore Retry

Вашу библиотеку использую так:

DL_USE_MODULE_BEGIN(foo, _T("foo.dll"))

    DL_DECLARE_FUN_THROW(
          Bar
        , result
        , (char const*)(short)(char const*)(char const*)(char const*)(HWND)(char const*)
        )

DL_USE_MODULE_END()

где то в коде...

result bar_result = foo::Bar( // на этой строчке вываливается message box Debug Error'а
      str1_.c_str()
    , short1_
    , str2_.c_str()
    , str3_.c_str()
    , str4_.c_str()
    , m_hWnd
    , str5_.c_str()
    );

Где грабли?

P.S. Если делаю по простому LoadLibrary, GetProcAddress — все ОК.

ssi>Где грабли?

Грабли в соглашениях о вызове. У вас, скорее всего, используется __сcall. В библиотеке — __stdcall, и добавлять поддержку других конвенций не планируется.

ssi>P.S. Если делаю по простому LoadLibrary, GetProcAddress — все ОК.

А кто бы сомневался. Там-то вы функцию определяете как __ccall.

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

ssi>>Где грабли?

AS>Грабли в соглашениях о вызове. У вас, скорее всего, используется __сcall. В библиотеке — __stdcall, и добавлять поддержку других конвенций не планируется.

ssi>>P.S. Если делаю по простому LoadLibrary, GetProcAddress — все ОК.

AS>А кто бы сомневался. Там-то вы функцию определяете как __ccall.

Как выйдти из положения? Dll-ка не моя, поэтому использовать другие соглашения о вызове не могу, в то же время хочу использовать Вашу библиотеку, имхо очень удобная.

Здравствуйте, Аноним, Вы писали:

А>Как выйдти из положения? Dll-ка не моя, поэтому использовать другие соглашения о вызове не могу, в то же время хочу использовать Вашу библиотеку, имхо очень удобная.

Ну так просто замени везде в библиотеке WINAPI на на что надо. Правда её тогда нельзя будет использовать с системными функциями.