std::async deprecated (на самом деле нет)

Еще раз, вы перечитайте написанное Джосаттисом.

Перечитал. Скажи уже прямо, не томи, что я там такого могу найти кроме истерик и ванильных цитат из Твиттера (и это документ рабочей группы!)?

Он там называет вещи своими именами.

Нет. Он везде заключает слово «problem» в кавычки, типа «это не проблема, ребят, ну вы чо))0»

Просто взять и задеприкейтить — это худший вариант

Просто взять и задеприкейтить — это лучший вариант

и тому Джосаттис приводит нормальные обоснования.

Сплошные истерики вида «что подумают о нас и C++, если мы признаем, что облажались?»

Т.е. люди понимают проблему и стараются найти выход.

Ничего никто не старается. Решено сохранить status quo и сделать вид, что это нормально.

Если мосье Д'Артаньян

Казуистика уже была, теперь переход на личности...

Просто взять и задеприкейтить — это лучший вариант

Вы читать умеете? Вот, что Джосаттис написал про это:

To deprecate a feature of C++, the following conditions must all hold:

- There must be something seriously broken, such that the a pplication of the feature is a dangerous. A “not-prefect” design is not enough.

- At the time of deprecation we have to provide an alternative, which has proven to be at least as powerful as the existing solution and fixing the problem that caused the deprecation.

- If possible, the alternative should not break existing code that was valid before. Especially a deprecated feature should still be able to use when the alternative solution is available.

- You have to wait X years/standards to remove a deprecated feature.

То, что вы призываете задепрекейтить std::async показывает, что вы не отдаете себе отчет о последствиях. Но этого мало, вы ведь и альтернативы std::async-у предложить вряд ли сможете. А, обидчивый вы наш?

Вы читать умеете? Вот, что Джосаттис написал про это:

Вы читать умеете? Я просил что-нибудь кроме истерик и субъективщины. Честно говоря, меня эти Ваши манёвры начали утомлять.

Я просил что-нибудь кроме истерик и субъективщины.

Ну да, ну да. Без истерик и субъективщины...

Приходится долго решать, выпиливать фичу из стандарта или, раз уж Джосаттису так нравится его кривой высер, то пусть остаётся. Нет, вы только гляньте на этот скулёж

В теме по ссылке - об (пока?) отсутствующих возможностях.

Можно и про C++ сказать, что в этой теме — об (пока?) отсутствующем task-based параллелизме.

Пойти что ли ржавчину поучить.

Мне тоже не нравится, но если я уберу "(на самом деле нет)", то модераторы скажут что тред это вброс и снесут его.

std::async, который может запускаться иначе, чем асинхронно, — например, отложенно, — уже вызывает подозрения в адекватности тех, кто его утвердил в стандарте.

Трагедия в том, что уже в момент принятия этого в стандарт, любому соискателю на должность выше уборщика на собеседовании предлагалось рассказать, что такое SOLID. И буква L в этой аббревиатуре означает, что я не имею права в своём, наследованном классе, реализовывать что-то этакое, что приведёт к тому, что с моим наследованным классом не сможет работать код, написанный для базового. И тут смотрим по ссылке, когда не то что наследник, тот же самый класс future ведёт себя совершенно по-разному в зависимости от того, какие флажки установлены при его создании. Вот есть у меня std::future, и пусть я даже знаю, что он создан через std::async. Как мне правильно извлечь данные? get() и повесить GUI-поток на пару минут, когда вычисления закончатся? wait*() и никогда не дождаться, потому что он отложенный? запустить get() через std::async() и получить косяк, потому что deferred future был не рассчитан на запуск в другом потоке о чём создатель явно указал в policy при создании?

любому соискателю на должность выше уборщика на собеседовании предлагалось рассказать, что такое SOLID.

Какими-то идиотами предлагалось, честное слово. Таким людям нельзя доверять проводить собеседования: они наберут теоретиков и заставят их забивать гвозди. Микроскопом.

И тут смотрим по ссылке, когда не то что наследник, тот же самый класс future ведёт себя совершенно по-разному в зависимости от того, какие флажки установлены при его создании. Вот есть у меня std::future, и пусть я даже знаю, что он создан через std::async. Как мне правильно извлечь данные? get() и повесить GUI-поток на пару минут, когда вычисления закончатся? wait*() и никогда не дождаться, потому что он отложенный?

Создаётся не класс, а объект, принадлежащий классу, а ведёт он себя так, как задумано. Объектно-ориентированный подход сам по себе не даёт гарантий насчёт времени исполнения. Это вообще отдельная тема.

Можно и про C++ сказать, что в этой теме — об (пока?) отсутствующем task-based параллелизме.

Сказать можно всё что угодно, но процитированное правдой не будет.

Вот так всегда в C++: впопыхах напихали нерабочих фич в стандарт — потом подпирают кастылями.

Так ведь борьба с собственным сложнейшим инструментом идёт неустанно :-) А кто-то в то же самое время просто использует pthread :-)

Какими-то идиотами предлагалось, честное слово

И тем не менее, это общепринятые принципы, снижающие склонность к ошибкам.

Создаётся не класс, а объект, принадлежащий классу,

Молодец, умыл.

Объектно-ориентированный подход сам по себе не даёт гарантий насчёт времени исполнения. Это вообще отдельная тема.

Какой ещё объектно-ориентированный подход? Тут его нет. Проблемма просто в идиотском дизайне интерфейса.

Проблемма просто в идиотском дизайне интерфейса.

Интерфейса чего именно?

Ну и как, по-вашему, должен был бы выглядеть не идиотский дизайн?

https://ru.wiktionary.org/wiki/нелицеприятный

Интерфейса чего именно?

Хотелось бы сказать, что асинка, но, видимо, и асинка и фьючи.

Ну и как, по-вашему, должен был бы выглядеть не идиотский дизайн?

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

Хотелось бы сказать, что асинка, но, видимо, и асинка и фьючи.

Ну, т.е., после нескольких лет реальной эксплуатации выяснились просчеты во многих местах, но поливать нужно именно std::async...

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

Покажите пример.

Кроме того, выше давали ссылку на документ Джосаттиса, где один из вариантов решения проблемы был как раз такой — возврат из std::async-а не std::future, а какого-то другого типа (с возможностью взятия из него std::future вручную при необходимостью). Но этот вариант так же кого-то не устроил.

Ну, т.е., после нескольких лет реальной эксплуатации выяснились просчеты во многих местах, но поливать нужно именно std::async...

Ну как бы он - естественная жертва, эта функция создаёт нестандартную future, если асинк убрать, то future можно будет использовать однообразно. Ну, разве что ещё и задепрекатить методы wait* из future, если асинхронность через future не делать.

Покажите пример.

Какой пример тут может быть? Ну. например, могли бы быть 2 класса Lazy<T> и AsyncResult<T>, у обоих метод get() для получения результата, только у AsyncResult<T> были бы ещё методы wait*. Или что-то типа continue_with.

Кроме того, выше давали ссылку на документ Джосаттиса, где один из вариантов решения проблемы был как раз такой — возврат из std::async-а не std::future, а какого-то другого типа (с возможностью взятия из него std::future вручную при необходимостью). Но этот вариант так же кого-то не устроил.

Странная идея. Менять возвращаемое значение в С++ нельзя. Если имеется в виду другая функция, которая делала бы примерно то же, то, вроде как, уже есть такое, std::packaged_task.

Странная идея. Менять возвращаемое значение в С++ нельзя.

Идея как раз в духе того, о чем вы говорите: возвращать из std::async не std::future<T>, а std::async_result<T>. Получится, что std::future и std::async_result — два разных типа, может быть с очень похожими интерфейсами (плюс возможность получить std::future из std::async_result).

Такое изменение формата std::async, конечно же, нарушило бы совместимость. Но если std::async деприкейтить, то совместимость все равно нарушается, а где замена?

Ну как бы он - естественная жертва, эта функция создаёт нестандартную future, если асинк убрать, то future можно будет использовать однообразно. Ну, разве что ещё и задепрекатить методы wait* из future, если асинхронность через future не делать.

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

Есть у меня ощущение, что одно без другого бы просто так в стандарте не оказалось. Сделали, как представлялось правильным лет 7-8 назад. Потом опыта поднакопили и стало лучше понятно, где именно лежали грабли. Нормальный рабочий процесс.

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

Кроме тебя, всем понятно, что пара promise/future первична, а async это (якобы удобный и высокоуровневый) способ спрятать promise и треды.

Кроме тебя, всем понятно, что пара promise/future первична, а async это (якобы удобный и высокоуровневый) способ спрятать promise и треды.

Ваша уверенность в собственной правоте не позволяет вам понять о чем именно идет речь. Меня интересует то, как определения std::future и std::async попадали в драфт стандарта C++0x и какое влияние они друг на друга оказывали.

Небольшой поиск по этой теме дал интересные результаты. Например, если идти от этой заметки в посте Энтони Уильямса https://www.justsoftwaresolutions.co.uk/cplusplus/cplusplus-standards-committ... к более свежим записям, то можно увидеть, что история была интересной и одновременно рассматривалось несколько вариантов async-а с разными типами возвращаемых значений. А вот здесь Уильямс резюмирует итог разборок: https://www.justsoftwaresolutions.co.uk/cplusplus/cplusplus-standards-committ... В стандарт включили async в предложениях от Саттера и Кроула, плюс к тому unique_future переименовали в future. Хотя на этом дело не остановилось и связку из future/async еще несколько раз уточняли: https://www.justsoftwaresolutions.co.uk/cplusplus/cplusplus-standards-committ... , https://www.justsoftwaresolutions.co.uk/cplusplus/cplusplus-standards-committ... , https://www.justsoftwaresolutions.co.uk/cplusplus/cplusplus-standards-committ... , https://www.justsoftwaresolutions.co.uk/cplusplus/cplusplus-standards-committ...

Так что лично у меня нет оснований считать, что std::async в стандарт попал по чьей-то глупости. Ну и высоки шансы, что теперешняя его критика является либо следствием послезнания, либо же всего одной из точек зрения (есть и другие точки зрения: http://scottmeyers.blogspot.com.by/2013/03/stdfutures-from-stdasync-arent-spe...).

А кто-то в то же самое время просто использует pthread

Давно в pthread появились таски?