IZ
Насколько помню, MSVC не особо любит чистый Си, и я бы не ждал от них строгой конформности стандарту))
Ну, да, кто бы спорил...
Size: a a a
2020 October 15
SE
Так выше, показал...
и шо?
ПК
Мы когда взяли футур, можно кастовать в
packaged_task<void()> спокойно (смотри в мастер ветке)Это требует пруфа
IZ
и шо?
ничего, просто прикольно...
SE
ничего, просто прикольно...
ну, если ты пропустил то msvc stl испльзует boost math :)
ПК
Ну а что мне ещё остаётся
Ты можешь хранить не packaged_tasks напрямую, а какой нибудь ITask интерфейс, которого будет метод Execute() виртуальный, который в конкретной реализации будет вызывать оператор() у таски
ПК
наследник у ITask шаблонный и инстанцируется при добавлении в контейнер как раз конкретным типом package_task
VF
Ты можешь хранить не packaged_tasks напрямую, а какой нибудь ITask интерфейс, которого будет метод Execute() виртуальный, который в конкретной реализации будет вызывать оператор() у таски
Там в любом случае будет
std::function, который и есть корень проблемы — его нельзя мувать в MSVCVF
Или вы предлагаете альтернативный способ хранения лямбд?
ПК
Или вы предлагаете альтернативный способ хранения лямбд?
Да
VF
Не могли бы вы набросать пример реализации такого контейнера?
ПК
Их можно хранить напрямую в шаблонном классе (от типа лямбды) а вызывать по виртуальному методу Execute()
ПК
У тебя вообще всё просто, у тебя даже паарметров нет
ПК
не надо их хранить отдельно
VF
Да, параметров нет. Но есть closure
ПК
Да, параметров нет. Но есть closure
Это неважно. Лямбда это функтор, её в шаблонном классе можно по значению хранить
ПК
Чтобы можно было хранить разные шаблонные инстансы в контейнере и нужен виртуальный интерфейс
VF
Пожалуйста, реализуйте пример. Без комментариев, не форматированный, но чтобы я уже от него отталкивался
VF
Кстати, важно то, что задания должны сами по себе храниться в контейнере (очереди)
VF
Надеюсь, вы не предлагаете делать
ThreadPool<variant_of_all_possible_futures>?