m
на сайте boost написано что он не работает с mingw компилятором
Size: a a a
2021 February 08
AS
Возможно, вопрос не сюда, но в общем есть у меня в коде такая штука HMODULE hPlugin = LoadLibrary(...) и дальше GetProcAdress(...). Оно работает, но, во первых это C, а все остальное C++, а во вторых есть подозрение что оно не кросс-платформенное (остальное написано на WTL, но переписываю на Qt). Есть какой-то более современный способ это сделать? Вроде была boost::dll, но чем-то не понравилась (хотя, это было пару лет назад)
Раз на Qt переписываете, берите https://doc.qt.io/qt-5/qlibrary.html :
typedef void (*MyPrototype)();
MyPrototype myFunction =
(MyPrototype) QLibrary::resolve("mylib", "mysymbol");
if (myFunction)
myFunction();
MK
Спасибо.
AF
Является ли валидным (по Стандарту) такой код?
void some_async_c_api_func(void(*callback)(void*));
...
void foo() {
auto async_callback = [](void* context){ /*do smth*/};
some_async_c_api_func(async_callback);
}
да
АК
Является ли валидным (по Стандарту) такой код?
void some_async_c_api_func(void(*callback)(void*));
...
void foo() {
auto async_callback = [](void* context){ /*do smth*/};
some_async_c_api_func(async_callback);
}
что в нём может быть невалидным?
AF
Является ли валидным (по Стандарту) такой код?
void some_async_c_api_func(void(*callback)(void*));
...
void foo() {
auto async_callback = [](void* context){ /*do smth*/};
some_async_c_api_func(async_callback);
}
только лямбде нельзя конвеншн прописать вроде есличто
D
что в нём может быть невалидным?
Меня немного смущает передача указателя на функцию (в который кастится лябмда) в
some_async_c_api_func, которая отрабатывает асинхронноMK
лямбда? не факт, что это то же самое что и сишная функция.
AS
Является ли валидным (по Стандарту) такой код?
void some_async_c_api_func(void(*callback)(void*));
...
void foo() {
auto async_callback = [](void* context){ /*do smth*/};
some_async_c_api_func(async_callback);
}
лябмда без захвата может быть использована в таком контексте
АК
только лямбде нельзя конвеншн прописать вроде есличто
она при конвертации сама нужный выберет, проверено
АК
Меня немного смущает передача указателя на функцию (в который кастится лябмда) в
some_async_c_api_func, которая отрабатывает асинхроннодля лямбды без захвата ты здесь получаешь не "каст лямбды", а просто указатель на некоторую функцию, которая имеет такое же тело, как и лямбда. грубо говоря,
static аналог для operator() этой лямбдыD
для лямбды без захвата ты здесь получаешь не "каст лямбды", а просто указатель на некоторую функцию, которая имеет такое же тело, как и лямбда. грубо говоря,
static аналог для operator() этой лямбдыПонял, благодарю)
MK
для лямбды без захвата ты здесь получаешь не "каст лямбды", а просто указатель на некоторую функцию, которая имеет такое же тело, как и лямбда. грубо говоря,
static аналог для operator() этой лямбдыА соглашение о вызове у нее будет cdecl?
АК
А соглашение о вызове у нее будет cdecl?
будет то, которое ожидается на принимающей стороне.
это не входит в стандарт, как я понимаю, но в случае MSVC x86 лямбда успешно "кастится" к vectorcall/stdcall/cdecl
это не входит в стандарт, как я понимаю, но в случае MSVC x86 лямбда успешно "кастится" к vectorcall/stdcall/cdecl
AT
какие части STL не удастся использовать, если сделать
-fno-exceptions? В их числе std::make_unique (легко заменить на свою обёртку с new (std::nothrow)), std::sto* (<charconv>). Что ещё?D
какие части STL не удастся использовать, если сделать
-fno-exceptions? В их числе std::make_unique (легко заменить на свою обёртку с new (std::nothrow)), std::sto* (<charconv>). Что ещё?Все контейнеры?
АК
какие части STL не удастся использовать, если сделать
-fno-exceptions? В их числе std::make_unique (легко заменить на свою обёртку с new (std::nothrow)), std::sto* (<charconv>). Что ещё?что подразумевается под "не удастся использовать"?
std::make_unique продолжит работать, просто приведёт к terminate вместо bad_alloc, как и все контейнерыAT
что подразумевается под "не удастся использовать"?
std::make_unique продолжит работать, просто приведёт к terminate вместо bad_alloc, как и все контейнерыохота все ситуации без завершения обрабатывать
АК
охота все ситуации без завершения обрабатывать
если речь про безопасность (возвращать nullptr вместо terminate), то всё плохо - абсолютно любой класс, который бросает исключения для сигнализации об ошибках, придётся переписать.
я видел проприетарные аналоги stl, где был режим no exceptions и все сигнатуры всех контейнерных методов были в виде
я видел проприетарные аналоги stl, где был режим no exceptions и все сигнатуры всех контейнерных методов были в виде
MACRO(bool, void) insert(const T& elem)