Do czego służą asseracje można znaleźć na wielu stronach np.
- http://pl.wikibooks.org/wiki/C/assert
- http://pornel.net/assert
- http://www.cplusplus.com/reference/cassert/assert/
W zasadzie w pawnie służą one do tego samego co wszędzie czyli do debugowania.
Mamy nawet dwa dostępne typy asseracji
- Pierwszy z nich to dyrektywa preprocesora w postaci
#assert constant expression
Warunek jest sprawdzany podczas kompilacji
Przykład#include <amxmodx></amxmodx> public plugin_init() { #assert 1 == 2 }
i komunikat
fatal error 110: assertion failed: 1 == 2
lub
#include <amxmodx></amxmodx> const constVariable = 2; public plugin_init() { #assert constVariable == 1 }
komunikat
fatal error 110: assertion failed: constVariable == 1
- Drugi typ asseracji to aseracje sprawdzane podczas działania pluginu. Używamy tutaj instrukcji
assert wyrażenie
Należy pamiętać że podczas testowania kodu z asseracjami należy załadować plugin w trybie debug inaczej przy warunku w asseracji który zwróci false nasz serwer zaliczy crasha 😉
Przykład użycia#include <amxmodx> #include <amxmisc> #define PLUGIN "New Plugin" #define AUTHOR "DarkGL" #define VERSION "1.0" public plugin_init() { register_plugin(PLUGIN, VERSION, AUTHOR) new testVariable = 1; assert testVariable < 0 }
i komunikat w logach
[AMXX] Displaying debug trace (plugin "assertTest3.amxx") [AMXX] Run time error 2: assertion failed [AMXX] [0] assertTest3.sma::plugin_init (line 14)
Możemy tu podawać dowolne warunki ale zgodnie z zasadami opisanymi w linkach na początku wpisu.
Asseracji w kodzie który chcemy opublikować ( a raczej w jego skompilowanej wersji ) pozbywamy się poprzez dołaczenie do parametrów kompilacji opcji -d1 lub -d0 ( http://darkgl.pl/index.php/2013/08/19/optymalizacja-dzialania-pluginow-poprzez-parametry-kompilacji/
Nie ma co ukrywać że modyfikacja parametrów kompilacji nie jest najprzyjemniejszym sposobem szczególnie jeśli udostępniamy nasz kod publicznie 😉
Dlatego napisałem mały plik inc który pozwala na wyłączanie mechanizmu asseracji za pomocą definiowania makra preprocesora
Udostępnia on dwa makra
- assert – ten sam efekt co drugi sposób asseracji opisany powyżej
- shouldntReachHere – plugin nie powinien dotrzeć do tego miejsca w kodzie następuje natychmiastowy „wyrzut” błędnej asseracji do logów
Same asseracje wyłączamy dodając taką o to definicję przed include pliku assert.inc
#define NDEBUG
Przykład użycia
#include <amxmodx> #include <amxmisc></amxmisc></amxmodx> #define PLUGIN "New Plugin" #define AUTHOR "DarkGL" #define VERSION "1.0" #include <assert></assert> public plugin_init() { register_plugin(PLUGIN, VERSION, AUTHOR) new n = 1; assert( n < 0 ) }
i przykład gdzie asseracje są wyłączone
#include <amxmodx> #include <amxmisc></amxmisc></amxmodx> #define PLUGIN "New Plugin" #define AUTHOR "DarkGL" #define VERSION "1.0" #define NDEBUG #include <assert></assert> public plugin_init() { register_plugin(PLUGIN, VERSION, AUTHOR) new n = 1; assert( n < 0 ) }
oraz shouldntReachHere
#include <amxmodx> #include <amxmisc></amxmisc></amxmodx> #define PLUGIN "New Plugin" #define AUTHOR "DarkGL" #define VERSION "1.0" #include <assert></assert> public plugin_init() { register_plugin(PLUGIN, VERSION, AUTHOR) shouldntReachHere() }
Hmmmm… Plugin odpalający się w określony dzień lub okres (święta). Genialne.