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 &lt; 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 &lt; 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 &lt; 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()
}

assert.inc Download