🚀 go-pugleaf

Emmanuel Delahaye a �crit dans le message
<news:Xns9292C82052CA8hsnoservernet@130.133.1.4> 

>> Pourquoi ne pas utiliser une assertion ? Si une des cha�nes est
>> NULL c'est manifestement un bug. Si en plus � l'utilisation on ne
>> teste pas la valeur de retour, le probl�me - parce que t�t ou
>> tard �a plantera - risque d'�tre bien plus difficle �
>> diagnostiquer. 
> 
> Un assert() est fait pour diagnostiquer une erreur de codage, pas
> une erreur d'utilisation.

Hum que veux-tu dire, quelle est la diff�rence ? Pour moi le fait 
d'appeler une routine de copie de cha�ne avec une cha�ne pointant sur 
rien est une erreur d'utilisation (du � quoi on ne sait pas). C'est � 
l'appelant de s'assurer qu'il remplit bien les (pr�)conditions de la 
fonction, pas � la fonction elle-m�me.

Par exemple, �a n'a aucun sens d'appeler une fonction qui calcule une 
racine carr�e avec un nombre n�gatif.

fonction racine ( un_entier )
    	assert ( un_entier >= 0 )
    	resultat:= .....
fin

> En fait, �a d�pend du statut de la
> fonction. Si elle est priv�e, assert(). Si elle est publique, test
> et code retours.

Je ne vois pas le rapport avec les assertions.

> Ne pas oublier que les macros assert() peuvent �tre d�sactiv�es
> (non compil�es) par NDEBUG en version finale. (VC6 fait �a
> automatiquement en mode release).
 
Oui, c'est le but.

Je sugg�re qu'on poursuive sur fr.comp.developpement. On s'�loigne du C 
et les assertions s'appliquent � d'autres langages.

-- 
Patrick