Проверка из 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()) и до этого вы проходили архитектуру ЭВМ в вузе или технаре - возможно, есть смысл изучить встроенный ассемблер Pawn. Если же нужно просто сэкономить пару инструкций там и тут - это пустая трата времени, на практике разница будет заметна только если код выполняется в цикле на несколько сотен или даже тысяч итераций. Собственно, я использую микрооптимизации в своих инклудах только потому, что делаю эти инклуды не только для себя, но и для других, а потому хочу чтобы мой код добавлял как можно меньше накладных расходов к пользовательскому коду. Естественно, в коде, не предназначенном для паблика, я не стану тратить время на что-то подобное.