Скотт Мейерс - Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14

• Захват перемещением. Лямбда-выражения С++11 не предоставляют возможности захвата перемещением, но его можно эмулировать с помощью комбинации лямбда- выражения и std::bind. Детали описываются в разделе 6.2, в котором также поясняется, что в С++14 поддержка инициализирующего захвата в лямбда-выражениях устраняет необходимость в такой эмуляции.

• Полиморфные функциональные объекты. Поскольку оператор вызова функции bind-объекта использует прямую передачу, он может принимать аргументы любого типа (с учетом ограничений на прямую передачу, описанных в разделе 5.8). Это может быть полезным, когда вы хотите связать объект с шаблонным оператором вызова функции. Например, для класса

class PolyWidget {

public:

template

void operator()(const T& param);

…

};

std::bindможет связать PolyWidgetследующим образом:

PolyWidget pw;

auto boundPW = std::bind(pw, _1);

После этого boundPWможет быть вызван с разными типами аргументов:

boundPW(1930); // Передача int в PolyWidget::operator()

boundPW(nullptr); // Передача nullptr в PolyWidget::operator()

boundPW("Rosebud"); // Передача строкового литерала

Выполнить это с помощью лямбда-выражений С++11 невозможно. Однако в С++14 этого легко достичь с помощью лямбда-выражения с параметром auto:

auto boundPW = [pw](const auto&param) // С++14

{ pw(param); };

Конечно, это крайние случаи, и они встречаются все реже, поскольку поддержка С++14 лямбда-выражений компиляторами становится все более распространенной.

Когда bindбыл неофициально добавлен в С++ в 2005 году, это было существенным усовершенствованием по сравнению с его предшественником 1998 года. Однако добавление поддержки лямбда-выражений в C++11 привело к устареванию std::bind, а с момента появления С++14 для него, по сути, не осталось применений.

• Лямбда-выражения более удобочитаемы, более выразительны и могут быть более эффективными по сравнению с std::bind.

• Только в C++11 std::bindможет пригодиться для реализации перемещающего захвата или для связывания объектов с шаблонными операторами вызова функции.

Одним из наибольших триумфов С++ 11 является включение параллелизма в язык программирования и библиотеку. Программисты, знакомые с другими потоковыми API (например, pthreads или Windows threads), иногда удивляются сравнительно спартанскому набору возможностей, предлагаемому С++, но это связано с тем, что по большей части поддержка параллельности в С++ имеет вид ограничений для разработчиков компиляторов. Получаемые в результате языковые гарантии означают, что впервые в истории С++ программисты могут писать многопоточные приложения со стандартным поведением на всех платформах. Это создает прочный фундамент, на котором могут быть построены выразительные библиотеки, а элементы параллелизма в стандартной библиотеке (задачи, фьючерсы, потоки, мьютексы, переменные условий, атомарные объекты и прочие) являются лишь началом того, что обязательно станет более богатым набором инструментов для разработки параллельного программного обеспечения на С++.

В последующих разделах нужно иметь в виду, что стандартная библиотека содержит два шаблона для фьючерсов: std::futureи std::shared_future. Во многих случаях различия между ними не важны, так что я часто говорю просто о фьючерсах , подразумевая при этом обе разновидности.

Если вы хотите выполнить функцию doAsyncWorkасинхронно, у вас есть два основных варианта. Вы можете создать std::threadи запустить с его помощью doAsyncWork, тем самым прибегнув к подходу на основе потоков :

int doAsyncWork();

std::threadt(doAsyncWork);

Вы также можете передать doAsyncWorkв std::async, воспользовавшись стратегией, известной как подход на основе задач :

auto fut = std::async(doAsyncWork); // "fut" от "future"

В таких вызовах функциональный объект, переданный в std::async(например, doAsyncWork), рассматривается как задача (task).

Подход на основе задач обычно превосходит свой аналог на основе потоков, и небольшие фрагменты кода, с которыми вы встретились выше, показывают некоторые причины этого. Здесь doAsyncWorkдает возвращаемое значение, в котором, как мы можем разумно предположить, заинтересован вызывающий doAsyncWorkкод. В случае вызова на основе потоков нет простого способа к нему обратиться. При подходе на основе потоков нет простого способа получить доступ к вызову. В случае же подхода на основе задач это можно легко сделать, поскольку фьючерс, возвращаемый std::async, предлагает функцию get. Эта функция getеще более важна, если doAsyncWorkгенерирует исключение, поскольку getобеспечивает доступ и к нему. При подходе на основе потоков в случае генерации функцией doAsyncWorkисключения программа аварийно завершается (с помощью вызова std::terminate).

Более фундаментальным различием между подходами на основе потоков и на основе задач является воплощение более высокого уровня абстракции в последнем. Он освобождает вас от деталей управления потоками, что, кстати, напомнило мне о необходимости рассказать о трех значениях слова поток (thread) в параллельном программировании на С++.

• Аппаратные потоки являются потоками, которые выполняют фактические вычисления. Современные машинные архитектуры предлагают по одному или по нескольку аппаратных потоков для каждого ядра процессора.

• Программные потоки (известные также как потоки ОС или системные потоки ) являются потоками, управляемыми операционной системой [21] В предположении, что таковая имеется. В некоторых встроенных системах ее нет. во всех процессах и планируемыми для выполнения аппаратными потоками. Обычно можно создать программных потоков больше, чем аппаратных, поскольку, когда программный поток заблокирован (например, при вводе-выводе или ожидании мьютекса или переменной условия), пропускная способность может быть повышена путем выполнения других, незаблокированных потоков.

• std::threadпредставляют собой объекты в процессе С++, которые действуют как дескрипторы для лежащих в их основе программных потоков. Некоторые объекты std::threadпредставляют “нулевые” дескрипторы, т.e. не соответствуют программным потокам, поскольку находятся в состоянии, сконструированном по умолчанию (следовательно, без выполняемой функции); потоки, из которых выполнено перемещение (после перемещения объект std::thread, в который оно произошло, действует как дескриптор для соответствующего программного потока); потоки, у которых выполняемая ими функция завершена; а также потоки, у которых разорвана связь между ними и обслуживающими их программными потоками.