gccを使用しているLinuxでは、いくつかの従来のC++コードをC++ 11にアップグレードする段階にあります。優先度を設定しようとするとき、私は次の質問を思いつきました。 std::this_thread::sleep_forに電話してusleepに電話をかけても何か利点がありますか？コードでは、実行中のスレッドが非常に短い期間待つことになっていると話しています。したがって、私は睡眠を中断するなどの高度な機能は必要ありません。私はsleepleでusleepを交換する必要があります
はい。 std::this_thread::sleep_forはC++ 11標準で指定されているため、C++ 11コンパイラおよび標準ライブラリを持つ任意のシステム上の移植可能なソリューションです。
usleepは、POSIX.1-2001で指定されており、廃止されました。これはPOSIX準拠のシステムでのみ（信頼性高く）使用できることを意味します。
POSIX.1-2008はusleepの指定を削除し、nanosleepを優先します。この理由だけでも、std::this_thread::sleep_forがはるかに良い選択です。
（詳細はhttp://linux.die.net/man/3/usleepを参照）。
私はPOSIX関数よりもstd準拠の関数を好むべきだと私は理解しています。しかし、私は副作用を期待する必要がありますか？ sleep_forは休憩とは異なる動作をしますか？パフォーマンス上の利点やペナルティはありますか？ –
私が見る限りではありません。両方とも指定された期間以上スリープするように指定されています（スケジューリングなどによっては長くなる場合もあります）。 – Andrew
パフォーマンスに関する懸念事項は、2つの解決策を_profile_することです。私は両者の間に大きな違いがあるとは想像もできません。とにかく待っている時間と比較していない。 – Andrew
はい、コードの移植性が向上します。 –
コードを変更するたびにバグが導入される危険性があります。しかし、もしあなたが関数を修正しているのであれば、移植性の高い標準コードに移動しないのはなぜですか？ – Galik