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

TB>Здравствуйте, ollv, Вы писали:

O>> так typedef TYPE_OF_3_PARAMETER(func(int(), int(), int(), int())) third_parameter_type; ?\

TB>Ну например, только троечка должна быть параметром, а не частью имени, конечно же.
Отлично. Напиши, как ты это видишь?

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

O>Здравствуйте, T4r4sB, Вы писали:

TB>>Здравствуйте, ollv, Вы писали:

O>>> так typedef TYPE_OF_3_PARAMETER(func(int(), int(), int(), int())) third_parameter_type; ?\

TB>>Ну например, только троечка должна быть параметром, а не частью имени, конечно же.
O>Отлично. Напиши, как ты это видишь?

typedef TYPE_OF_PARAMETER(func(int(), int(), int(), int()), 3) third_parameter_type;

Здравствуйте, rg45, Вы писали:
R>А что препятствует переходу на что-то более свеженькое?
Да, коней на переправе не меняют. С новым проектом будет и новая студия. Не хочется тратить время на адаптацию перед релизом.

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

TB>Здравствуйте, ollv, Вы писали:

O>>Здравствуйте, T4r4sB, Вы писали:

TB>>>Здравствуйте, ollv, Вы писали:

O>>>> так typedef TYPE_OF_3_PARAMETER(func(int(), int(), int(), int())) third_parameter_type; ?\

TB>>>Ну например, только троечка должна быть параметром, а не частью имени, конечно же.
O>>Отлично. Напиши, как ты это видишь?
TB>

TB>typedef TYPE_OF_PARAMETER(func(int(), int(), int(), int()), 3) third_parameter_type;
TB>

погоди, так это плюсовой вариант и есть. Просто за макросом кое что будет написано. Но ты волен скипать это с глаз долой )

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

O>погоди, так это плюсовой вариант и есть. Просто за макросом кое что будет написано.

Кое-что из 100 строк копипасты.
То есть если мне понадобится чуть иной вариант, то я должен писать свою копипасту.
Ну и без библиотек, хранящих тонны платформозависимых костылей на каждую платформу, на С++ по сути уже писать нельзя.

Здравствуйте, night beast.
Жаль, std::apply только с С++17 появляется Ну, у меня есть велосипедный tuple_call.

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

W>Жаль, std::apply только с С++17 появляется Ну, у меня есть велосипедный tuple_call.

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

там кстати можно попробовать не тупл, а [args...] захватывать.
не знаю правда, сработает ли в 11 стандарте.

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

TB>Здравствуйте, ollv, Вы писали:

O>>погоди, так это плюсовой вариант и есть. Просто за макросом кое что будет написано.

TB>Кое-что из 100 строк копипасты.
Так необязательно смотреть этот код. А кейсы и их количество, ну извини пока экспоненциального роста кейсов не наблюдается никаких проблем я не вижу. Более того половина кода такого — генерится.
TB>То есть если мне понадобится чуть иной вариант, то я должен писать свою копипасту.
В нормальной библиотеке оч тяжело найти кейс который не покрыт. Если это самописная — можно подойти к тому кто саппортит этот код.
TB>Ну и без библиотек, хранящих тонны платформозависимых костылей на каждую платформу, на С++ по сути уже писать нельзя.
)) ха — смешно. А на чем можно ?

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

O>Более того половина кода такого — генерится.

В С++ настолько развитое метапрограммирование, что приходится брать внешние генераторы.
Расстрелять комитет нахрен.

Здравствуйте. Короче, получилось что-то такое:

using namespace md;

namespace md {

void add_to_queue(const std::function<void()>& fnc)
{
  fnc(); // Для проверки просто вызываем
}

template<typename Sig>
struct defer_proxy
{
  template<typename... Args>
  void operator()(Args&&... args)
  {
    // Чтобы протащить в лямбду...
    stdext::call_traits<Sig>::parameter_types args_tuple(std::forward<Args>(args)...);  // Пакуем аргументы в туплу
    auto fn_ = std::move(fn);                                                           // И функцию в локал 

    add_to_queue([fn_, args_tuple](){stdext::call_elements(fn_, args_tuple);}); // call_elements = std::apply
  } 

  std::function<Sig> fn;
};


template<typename T>
auto defer(const T& fn) -> typename std::function<typename stdext::call_traits<T>::signature>
{
  return defer_proxy<typename stdext::call_traits<T>::signature>{fn};
}

} // md

int main(int argc, char * argv[])
{
  auto x = [](int i, float f)
  {
    std::cout << i << " " << f << std::endl;
  };
  defer(x)(1, 1.0f);

  std::function<void(int, float)> y = x;
  defer(y)(2, 2.0f);

  return 0;
}

Запустить "как есть" его не получится (call_traits и call_elements), но, может, будут какие-то замечания просто при взгляде на него?

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

W>Запустить "как есть" его не получится (call_traits и call_elements), но, может, будут какие-то замечания просто при взгляде на него?

Я бы предложил сделать такое упрощение

    add_to_queue([fn_ = std::move(fn), args_tuple](){stdext::call_elements(fn_, args_tuple);});} // call_elements = std::apply

А то выходит, что ты сначала делаешь move и тут же копирование.

И второе, несколько смущает такая одноразовость объектов defer_proxy. Повторное использование чревато UB. Я бы подумал, как можно обезопасить код.

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

W>Здравствуйте. Короче, получилось что-то такое:

W>Запустить "как есть" его не получится (call_traits и call_elements), но, может, будут какие-то замечания просто при взгляде на него?

вроде бы [fn, args...]() { fn_(std::move(args)...); }
должно сработать.

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

NB>вроде бы [fn, args...]() { fn_(std::move(args)...); }
NB>должно сработать.

В результате move можно получить нежелательное преобразование к rvalue и нарваться на несовместимость фактических и формальных параметров.

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

NB>>вроде бы [fn, args...]() { fn_(std::move(args)...); }
NB>>должно сработать.

R>В результате move можно получить нежелательное преобразование к rvalue и нарваться на несовместимость фактических и формальных параметров.

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

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

W>Запустить "как есть" его не получится (call_traits и call_elements), но, может, будут какие-то замечания просто при взгляде на него?

Виталик, а можешь объяснить, чем не устраивает "лобовой" вариант? Повторный вызов defer_proxy ведь у тебя все равно невозможен (UB), так какой смысл отделять функтор от параметров?

http://coliru.stacked-crooked.com/a/be68f70b50a6c00b

#include <iostream>
#include <functional>

namespace md {

void add_to_queue(const std::function<void()>& fnc)
{
  fnc(); // Для проверки просто вызываем
}

template<typename F, typename...Args>
void defer(F&& fn, Args&&...args)
{
  return add_to_queue([=](){fn(args...);});
}

} // md

int main(int argc, char * argv[])
{
  auto x = [](int i, float f)
  {
    std::cout << i << " " << f << std::endl;
  };
  md::defer(x, 1, 1.0f);

  std::function<void(int, float)> y = x;
  md::defer(y, 2, 2.0f);
}

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

W>Запустить "как есть" его не получится (call_traits и call_elements), но, может, будут какие-то замечания просто при взгляде на него?

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

http://coliru.stacked-crooked.com/a/3f41b4c768c465c2

#include <iostream>
#include <functional>

namespace md {

void add_to_queue(const std::function<void()>& fnc)
{
  fnc(); // Для проверки просто вызываем
}

template<typename F>
struct defer_proxy
{
  template<typename... Args>
  void operator()(Args&&... args) const
  {
    auto&& fn_ = fn;
    add_to_queue([=](){fn_(args...);}); // call_elements = std::apply
  } 
  F fn;
};


template<typename F>
defer_proxy<F> defer(const F& fn)
{
  return {fn};
}

} // md

int main(int argc, char * argv[])
{
  auto x = [](int i, float f)
  {
    std::cout << i << " " << f << std::endl;
  };
  md::defer(x)(1, 1.0f);

  std::function<void(int, float)> y = x;
  md::defer(y)(2, 2.0f);
}

Здравствуйте, rg45, Вы писали:
R>Я бы предложил сделать такое упрощение
R>

R>    add_to_queue([fn_ = std::move(fn), args_tuple](){stdext::call_elements(fn_, args_tuple);});} // call_elements = std::apply
R>

R>А то выходит, что ты сначала делаешь move и тут же копирование.
Увы, в С++11 присвоение внутри списков захвата не завезли...

R>И второе, несколько смущает такая одноразовость объектов defer_proxy. Повторное использование чревато UB. Я бы подумал, как можно обезопасить код.
Да, с одноразовостью я погорячился, ее там быть не должно. Придется делать обычное копирование, еще и 2 раза.

Здравствуйте, night beast, Вы писали:
NB>вроде бы [fn, args...]() { fn_(std::move(args)...); }
NB>должно сработать.
Проверю, но не уверен, что в С++11 есть захват паков параметров...

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

W>Да, с одноразовостью я погорячился, ее там быть не должно. Придется делать обычное копирование, еще и 2 раза.

Ты локальный fn_ можешь сделать ссылкой на мембер. Лямбда все равно по значению его возьмет.

Здравствуйте, rg45, Вы писали:
R>Виталик, а можешь объяснить, чем не устраивает "лобовой" вариант? Повторный вызов defer_proxy ведь у тебя все равно невозможен (UB), так какой смысл отделять функтор от параметров?
R>http://coliru.stacked-crooked.com/a/be68f70b50a6c00b
Во-первых, я погорячился, и повторный вызов должен работать корректно
Во-вторых, вызов функции defer не должен добавлять вызов в список сразу, а должен создавать функцию эквивалентной сигнатуры, вызов которой уже "сбиндит" прокси-функцию и положит ее в очередь обработки.
Вот небольшой пример использования (функции и классы из головы):

// Какая-то демо-функция
void log(std::string text)
{
  log() << text;
}

Socket<void(std::string)> n_input;

int main()
{
  // Это код вызовет запись в лог немедленно
  n_input.connect(&log);
  n_input("Instant notification"); // То есть после этой строчки в логе уже надпись "Instant notification"
  n_input.disconnect_all();

  // А этот код покладет запись в лог в очередь, которая обработается "когда-то потом"
  n_input.connect(defer(&log));
  n_input("Defered notification"); // То есть после этой строчки в логе сразу ничего не появится

  process_queue(); // А после этой строчки - в логе появится "Defered notification"
}