C の行数が少ないほどコードが最適化されると考えるのは、古典的な間違いです。
アセンブラーの出力を実際に調べて、コードのプロファイルを作成し、それが実際のボトルネックかどうかを確認する必要があります。
私がよく行うのは、最初に読みやすさを最適化し、それが問題になった場合にのみパフォーマンスを攻撃することです。したがって、より読みやすい解決策 (私の意見ではありません) は次のようになります。
unsigned int bit_swap (unsigned int num, unsigned int pos1, unsigned int pos2) {
// Swapping identical bit positions is a no-op.
if (pos1 == pos2)
return num;
// Get masks from bit positions.
unsigned int mask1 = 1 << pos1;
unsigned int mask2 = 1 << pos2;
// Get bit truth values.
int bit1_was_set = ((num & mask1) != 0);
int bit2_was_set = ((num & mask2) != 0);
// Clear and set first bit (set only if second bit was originally set).
num = num & ~mask1;
if (bit2_was_set)
num = num | mask1;
// Do the same for other bit.
num = num & ~mask2;
if (bit1_was_set)
num = num | mask2;
// Return the value with swapped bits.
return num;
}
あなたのアプローチよりもはるかに多くの行があるにもかかわらず、最近利用可能な非常に最適化されたコンパイラーがカバーの下で同様のコードを提供することに気付くかもしれません。
あなたがほぼ確実に発見することは、C の第一人者ではない人々 (そしておそらく今から 6 か月後にはあなた自身) が、1 行のマルチビット演算子のバリアントよりもソース コードをよりよく理解できるようになるということです。