Разница между boost :: ref и обычными ссылками

Question

В чем разница между boost::ref(i) и & i? В каких ситуациях мы не можем использовать обычные ссылки и вместо этого приходится использовать boost::ref? Пожалуйста, включите примеры, если это возможно.

Answer 1

Из документации Boost.Ref :

Цель boost :: reference_wrapper должен содержать ссылку на объект тип Т. Он в основном используется для «кормления» ссылки на шаблоны функций (алгоритмы), которые принимают их параметр по значению.

Примечание: важное различие между boost::reference_wrapper и std::reference_wrapper (по крайней мере, в Boost 1.52) заключается в способности std::reference_wrapper идеально обернуть функциональные объекты.

Это разрешает код, подобный этому:

// functor that counts how often it was applied
struct counting_plus {
  counting_plus() : applications(0) {}
  int applications;

  int operator()(const int& x, const int& y) 
  { ++applications; return x + y; }
};

std::vector<int> x = {1, 2, 3}, y = {1, 2, 3}, result;
counting_plus f;
std::transform(begin(x), end(x), begin(y), 
               std::back_inserter(result), std::ref(f));
std::cout << "counting_plus has been applied " << f.applications 
          << " times." << '\n';

Answer 2

In Boost.Thread , например:

Новый поток запускается путем передачи объект вызываемого типа, который может быть вызывается без параметров конструктор. Затем объект копируется во внутреннюю память, и вызывается на вновь созданный поток исполнения. Если объект не должен (или не может быть) скопировать, то boost :: ref можно использовать для передать ссылку на функцию объект. В этом случае пользователь Boost.Thread должен гарантировать, что упомянутый объект переживает вновь созданный поток исполнения.

Код из документа:

struct callable
{
    void operator()();
};

boost::thread copies_are_safe()
{
    callable x;
    return boost::thread(x);
} // x is destroyed, but the newly-created thread has a copy, so this is OK

boost::thread oops()
{
    callable x;
    return boost::thread(boost::ref(x));
} // x is destroyed, but the newly-created thread still has a reference
  // this leads to undefined behaviour