Как написать вариадический оператор по SFINAE для умного указателя на Т, который может быть функцией?

Question

[Павел Соколов]

у меня есть умный указатель, в данном вопросе назовем его smart_pointer
он шаблонен по template
у меня есть std::is_function_v для проверки, является ли Т функцией (но я думаю что класса return_type будет достаточно, он описан ниже)
я хотел воспользоваться SFINAE для того чтобы выключить перегрузку
в итоге наклепал такой код:

template<typename T>
struct return_type;
template<typename R, typename... Args>
struct return_type<R(Args...)>
{
	using type = R;
};
//-------------------
template<typename R = return_type<T>::type, typename ...Args>
R operator()(Args... args) const {
	return (*reference->instance)(args...);
}

объявил функцию как typedef bool (*function)(short_args&&);
и я не могу взять и сделать так:

smart_pointer<function> sm(foo);
sm(short_args())

потому что возникает ошибка error C3889
в чем ошибка?

Comments

[Wataru]

Дайте, что ли полный текст ошибки.

А потом, зачем вам умный указатель на функцию? Это очень плохая затея вообще. Подумайте, надо ли освобождать память, на которую указывает указатель вообще? Когда и где она создается?

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

Если же у вас какой-то класс с определенным оператором (), который и хранит какие-то еще данные, кроме кода (вроде забинденных аргументов), то у него тип вообще не функции. Это просто какой-то класс с оператором () и все.

[Павел Соколов]

Wataru, я знаю, что высвобождение инструкций не сулит ничем хорошим, умный указатель мне нужен для того, чтобы отслеживать, является ли функция выгруженной (все сильные ссылки оборваны, я использую в местах выполнения только слабые).
полный текст ошибки:
1>D:\DTE\DynamicTokenEngine\TokenOperator\token\source\stream.cpp(14,4): error C3889: вызов объекта типа класса "dte_utils::weak_ref": не найден соответствующий оператор вызова
1>D:\DTE\DynamicTokenEngine\TokenOperator\utils\include\pointer.h(118,6): message : может быть "R dte_utils::weak_ref::operator ()(Args...) const"
1>D:\DTE\DynamicTokenEngine\TokenOperator\token\source\stream.cpp(14,19): message : "R dte_utils::weak_ref::operator ()(Args...) const": не удается вывести аргумент шаблон для "R"

[rPman]

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

[Павел Соколов]

rPman,

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

[rPman]

Павел Соколов, зачем, какую задачу решает отслеживание выгруженности функции, что бы это ни значило?

[Павел Соколов]

rPman, решает проблему, возможно ли запускать вложенные функции внутри невыгруженной функции. Можно конечно следить выгружаемыми dll кто использует, но это вариант не лучше

[res2001]

Павел Соколов, По моему этим вариантом вы проблему вообще ни как не решаете.
DLL может быть выгружена, а указатель при этом останется, только он теперь будет указывать в не распределенное пространство памяти. И вызов функции через этот указатель приведет к падению программы.

[rPman]

Все что дает компилятор - фиксируется на момент компиляции obj файла (плюс что то во время линковки в бинарник)... dll-же это динамически загружаемое, методы как минимум должны регистрироваться (или их таблица) средствами ОС но никак не компилятором.

[res2001]

Для защиты от выгрузки DLL ваш умный указатель должен так же принимать в параметре и дескриптор открытой DLL. При вызове проверять средствами ОС, существует ли до сих пор дескриптор. Если не существует, то указателю можно присвоить какое-то не корректное значение и уже в следующий раз ничего не проверять.

То же самое можно сделать, написав функцию обертку над функцией DLL, в которой будет все это проверяться.

Обычно проще один раз грузить DLL при старте и получать указатели на функции, которые будут валидны все время выполнения программы. Тогда можно в принципе не заморачиваться на какую-то сложную защиту.

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

[rPman]

res2001, можно написать приложение, генерирующее h-файл с описанием мета-класса с функциями из указанной dll, которая при первом вызове любого метода делала бы загрузку и инициализацию .dll (понятно флаг завести чтобы повторно не делать) но выгружать такую .dll можно либо по команде либо только по звершению программы..

[Павел Соколов]

rPman, в случае dllimport - так и есть, но у меня LoadLibrary, так что в определении функции может быть другая функция
res2001, rPman, да HANDLE может быть использован и очищается в 0 при FreeLibrary (и подсчете), однако у меня нет гарантий того, что именно dll всегда отвечает за функции, просто это будет чаще всего (и возможно будет например с функторами т.д.)
мне нужна именно слабая связь, чтобы считать - если слабые владельцы остались, это значит нужно создать одну слабую связь, которая будет для них всех (ибо референс для них един), которая всем сразу и установит нужную функцию после выгрузки
сильная ссылка будет уничтожена после выгрузки dll поэтому она рациональна в использовании

Answer 1

[Wataru]

Вот минимальный рабочий пример. В вашей реализации return_type проблема в том, что вы этот шаблон применяете к указателю на функцию. Если там поставить * в специализации шаблона - то все компилируется и даже работает.

template<typename T>
struct return_type;
template<typename R, typename... Args>
struct return_type<R(*)(Args...)>
{
	using type = R;
};

typedef bool (*function)(int);

template<typename T>
class smart_pointer {
public:    
    smart_pointer(T func) : func_(func) {}
    
    template<typename R = typename return_type<T>::type, typename ...Args>
    R operator()(Args... args) const {
        return func_(args...);
    }
    
    T func_;
};

bool foo(int t) {
    return t % 2 == 0;
}


int main() {
    smart_pointer<function> sm(&foo);
    std::cout << sm(5);

    return 0;
}