Вы бы использовали num% 2 или num & 1, чтобы проверить, четное ли число?

Неоднократно упоминалось, что любой современный компилятор создаст одну и ту же сборку для обоих вариантов. Это напомнило мне демонстрационную страницу LLVM, которую я где-то видел на днях, поэтому решил, что дам ее тому назад. Я знаю, что это не более чем анекдотический случай, но он подтверждает то, что мы ожидали: x%2 и x&1 реализованы одинаково.

Я также попытался скомпилировать оба из них с помощью gcc-4.2.1 (gcc -S foo.c), и полученная сборка идентична (и вставлена ​​внизу этого ответа).

Запрограммируйте первое:

int main(int argc, char **argv) {
  return (argc%2==0) ? 0 : 1;
}

Результат:

; ModuleID = '/tmp/webcompile/_27244_0.bc'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"

define i32 @main(i32 %argc, i8** nocapture %argv) nounwind readnone {
entry:
    %0 = and i32 %argc, 1       ; <i32> [#uses=1]
    ret i32 %0
}

Запрограммируйте второе:

int main(int argc, char **argv) {
  return ((argc&1)==0) ? 0 : 1;
}

Результат:

; ModuleID = '/tmp/webcompile/_27375_0.bc'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"

define i32 @main(i32 %argc, i8** nocapture %argv) nounwind readnone {
entry:
    %0 = and i32 %argc, 1       ; <i32> [#uses=1]
    ret i32 %0
}

Вывод GCC:

.text
.globl _main
_main:
LFB2:
  pushq %rbp
LCFI0:
  movq  %rsp, %rbp
LCFI1:
  movl  %edi, -4(%rbp)
  movq  %rsi, -16(%rbp)
  movl  -4(%rbp), %eax
  andl  $1, %eax
  testl %eax, %eax
  setne %al
  movzbl  %al, %eax
  leave
  ret
LFE2:
  .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
  .set L$set$0,LECIE1-LSCIE1
  .long L$set$0
LSCIE1:
  .long 0x0
  .byte 0x1
  .ascii "zR\0"
  .byte 0x1
  .byte 0x78
  .byte 0x10
  .byte 0x1
  .byte 0x10
  .byte 0xc
  .byte 0x7
  .byte 0x8
  .byte 0x90
  .byte 0x1
  .align 3
LECIE1:
.globl _main.eh
_main.eh:
LSFDE1:
  .set L$set$1,LEFDE1-LASFDE1
  .long L$set$1
ASFDE1:
  .long LASFDE1-EH_frame1
  .quad LFB2-.
  .set L$set$2,LFE2-LFB2
  .quad L$set$2
  .byte 0x0
  .byte 0x4
  .set L$set$3,LCFI0-LFB2
  .long L$set$3
  .byte 0xe
  .byte 0x10
  .byte 0x86
  .byte 0x2
  .byte 0x4
  .set L$set$4,LCFI1-LCFI0
  .long L$set$4
  .byte 0xd
  .byte 0x6
  .align 3
LEFDE1:
  .subsections_via_symbols

Все зависит от контекста. Я на самом деле предпочитаю подход & 1, если это низкоуровневый системный контекст. Во многих из этих контекстов «даже» в основном означает, что для меня имеет младший бит ноль, а не делится на два.

ОДНАКО: у вашего лайнера есть ошибка.

Вы должны идти

if( (x&1) == 0 )

нет

if( x&1 == 0 )

Последний выполняет операцию AND x с 1 == 0, т. Е. Он выполняет операцию AND x с 0, получая 0, что, конечно, всегда считается ложным.

Итак, если вы сделали именно так, как вы предлагаете, все числа нечетные!

Любой современный компилятор оптимизирует операцию по модулю, поэтому скорость не имеет значения.

Я бы сказал, что использование модуля по модулю упростит понимание, но создание функции is_even, использующей метод x & 1, дает вам лучшее из обоих миров.

Они оба довольно интуитивны.

Я бы дал небольшое преимущество num % 2 == 0, но на самом деле у меня нет предпочтений. Конечно, что касается производительности, это, вероятно, микрооптимизация, поэтому я бы не стал об этом беспокоиться.

Я потратил годы, настаивая на том, что любой разумный компилятор, стоящий занимаемого им места на диске, оптимизирует num % 2 == 0 до num & 1 == 0. Затем, проанализировав разборку по другой причине, у меня была возможность действительно проверить свое предположение.

Оказывается, я ошибался. Microsoft Visual Studio, вплоть до версии 2013, генерирует следующий объектный код для num % 2 == 0:

    and ecx, -2147483647        ; the parameter was passed in ECX
    jns SHORT $IsEven
    dec ecx
    or  ecx, -2
    inc ecx
$IsEven:
    neg ecx
    sbb ecx, ecx
    lea eax, DWORD PTR [ecx+1]

Да, в самом деле. Это в режиме выпуска со всеми включенными оптимизациями. Вы получаете практически одинаковые результаты при сборке для x86 или x64. Вы, наверное, не поверите мне; Я сам с трудом верил в это.

По сути, он делает то, что вы ожидаете от num & 1 == 0:

not  eax                        ; the parameter was passed in EAX
and  eax, 1

Для сравнения: GCC (начиная с версии 4.4) и Clang (начиная с версии 3.2) делают то, что можно было бы ожидать, создавая идентичный объектный код. для обоих вариантов. Однако согласно Интерактивный компилятор Мэтта Годболта, ICC 13.0.1 также не оправдывает моих ожиданий.

Конечно, эти компиляторы не ошибочны. Это не ошибка. Существует множество технических причин (как правильно указано в других ответах), почему эти два фрагмента кода не идентичны. И, безусловно, здесь следует привести аргумент «преждевременная оптимизация - зло». Конечно, есть причина, по которой мне потребовались годы, чтобы заметить это, и даже тогда я случайно наткнулся на это.

Но, как сказал Дуг Т., вероятно, лучше всего определить в вашей библиотеке функцию IsEven, которая получит все эти исправьте мелкие детали, чтобы вам больше не приходилось думать о них, и сохраняйте читабельность кода. Если вы регулярно нацеливаетесь на MSVC, возможно, вы определите эту функцию, как я:

bool IsEven(int value)
{
    const bool result = (num & 1) == 0;
    assert(result == ((num % 2) == 0));
    return result;   
}

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

Во всяком случае, я считаю, что 2) намного быстрее, так как не требует деления.

Я не думаю, что модуль делает вещи более читабельными. И то, и другое имеет смысл, и обе версии верны. А компьютеры хранят числа в двоичном формате, поэтому вы можете просто использовать двоичную версию.

if( ( num & 1 ) == 0 ) { /* even */ }
if( ( 00010111b & 1 ) == 0 ) { /* even */ }
if( ( 00010110b & 1 ) == 0 ) { /* odd */ }

Только приоритет оператора может быть ловушкой с бинарными операторами. Но это не должно быть поводом избегать их (когда-нибудь они все равно понадобятся даже новым программистам).

На этом этапе я, возможно, просто добавляю шума, но с точки зрения удобочитаемости вариант по модулю имеет больше смысла. Если ваш код не читается, он практически бесполезен.

Кроме того, если этот код не запускается в системе, которая действительно ограничена ресурсами (я думаю, микроконтроллер), не пытайтесь оптимизировать для оптимизатора компилятора.