Проверка из dc_kickfix

[Paradox]

Доброго времени суток, в общем в inc dc_kickfix заметил такую вот проверку..


if(0 == IsPlayerConnected(playerid))
return 0;


И почему не написать так:


if(!IsPlayerConnected(playerid))
return 0;


в общем в чем разница и почему ровняется именно нулю?

[20th century]

Разницы никакой нет, проверка в обоих случаях одинакова. Скорее у автора свой стиль написания кода.

[Paradox]

Разницы никакой нет, проверка в обоих случаях одинакова. Скорее у автора свой стиль написания кода.

Понял, спасибо большое

[tnc]

есть небольшая разница, если вызывать отрицания, то генерируется на одну инструкцию больше:



// отрицание
load.s.pri fffffffc
not
jzer 0

// простое сравнение с нулем
load.s.pri fffffffc
jnz 0


а, равняется нулю, потому что проверка идет на не подключенного игрока

[Paradox]

есть небольшая разница, если вызывать отрицания, то генерируется на одну инструкцию больше:



// отрицание
load.s.pri fffffffc
not
jzer 0

// простое сравнение с нулем
load.s.pri fffffffc
jnz 0


а, равняется нулю, потому что проверка идет на не подключенного игрока

Спасибо за ответ, а как можно проверять подобный код, есть мануал?

[20th century]

В pawn.cfg добавить ключ -a и скомпилировать .pwn. В папке появится файл с расширением .asm.

[Daniel_Cortez]

Спасибо за ответ, а как можно проверять подобный код, есть мануал?
Если об этом и есть какие-то материалы на форумах, то разве что самые минимальные, и это не просто так.


В pawn.cfg добавить ключ -a и скомпилировать .pwn. В папке появится файл с расширением .asm.
Вот только нельзя судить о производительности кода по одному лишь количеству инструкций, есть и другие факторы (например, наличие лишних переходов, которых можно избежать, даже если ценой большего числа инструкций).

Это микрооптимизации, которые, во-первых, требуют специфических знаний, и, во-вторых, обычно идут в ущерб читаемости кода. Для их применения нужно иметь базовые представления о внутреннем устройстве интерпретатора (или об архитектуре ЭВМ, ибо интерпретатор AMX - по сути тот же "виртуальный" процессор, максимально приближенный к реальной архитектуре).
То есть, если, к примеру, есть большое желание сделать что-нибудь необычное, чего нельзя реализовать на простом Pawn (например, как в switchrand() (https://pro-pawn.ru/showthread.php?16996-random_switch-inc)) и до этого вы проходили архитектуру ЭВМ в вузе или технаре - возможно, есть смысл изучить встроенный ассемблер Pawn. Если же нужно просто сэкономить пару инструкций там и тут - это пустая трата времени, на практике разница будет заметна только если код выполняется в цикле на несколько сотен или даже тысяч итераций. Собственно, я использую микрооптимизации в своих инклудах только потому, что делаю эти инклуды не только для себя, но и для других, а потому хочу чтобы мой код добавлял как можно меньше накладных расходов к пользовательскому коду. Естественно, в коде, не предназначенном для паблика, я не стану тратить время на что-то подобное.