Время вычитания времени Ruby

Помните, что C ++ использует принцип «не платите за то, что вы не используете». Рассмотрим, например, мнимую платформу, которая использует непрозрачный тип для представления мьютекса; назовем этот тип mutex_t. Если интерфейс для работы с этим мьютеком использует mutex_t* в качестве аргументов, например, как void mutex_init(mutex_t* mutex); для «создания» мьютекса, вполне может случиться так, что адрес мьютекса - это то, что используется для однозначной идентификации мьютекса. Если это так, то это означает, что mutex_t не копируется:

mutex_t kaboom()
{
    mutex_t mutex;
    mutex_init(&mutex);
    return mutex; // disaster
}

Здесь нет никакой гарантии при выполнении mutex_t mutex = kaboom();, что &mutex имеет то же значение, что и &mutex в функциональный блок.

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

С другой стороны, хотя сейчас std::mutex является not подвижным, очень легко «вернуть» один из функция: верните std::unique_ptr<std::mutex>. Это все еще оплачивает затраты на динамическое распределение , но только в одном месте . Все остальные коды, которые не должны перемещать std::mutex, не должны оплачивать это.

Другими словами, поскольку перемещение мьютекса не является основной операцией того, что означает мьютекс , не требуя перемещения std::mutex, не снимает никаких функциональных возможностей (благодаря не подвижной T => подвижной std::unique_ptr<T> трансформации) и будет понести минимальные накладные расходы по сравнению с использованием собственного типа.

std::thread можно было бы аналогичным образом указать, чтобы он не был подвижным, что сделало бы типичное время жизни как таковое: running (связанный с потоком выполнение) после вызова конструктора с оценкой; и отсоединены / объединены (не связаны нитями выполнения), после вызова join или detach. Насколько я понимаю, std::vector<std::thread> все равно был бы полезен, так как тип был бы EmplaceConstructible.

edit: Неверно! Тип все равно должен быть подвижным (при перераспределении в конце концов). Для меня это достаточно обосновано: типично помещать std::thread в контейнеры, такие как std::vector и std::deque, поэтому функциональность приветствуется для этого типа.