Reprise du message précédent :
Un grand merci, je pars en vacances avec ma disquette de sources et je vais potasser tout ca la bas ! Encore merci de m'avoir accordé de votre temps.

Merci d'avoir corrigé Toxin ... Moi avoir pas vu kil mankai une star devant T (Mr.)

...
if (!tete) //je ne comprends pas à quel moment on rentre ds le if ca dire quoi !tete ? different de tete ? mais quoi ?
...  
if (!object)
...
 
En tout cas, merci.

Rappel en C

• FAUX = 0
• VRAI != 0

Pour que !tete (non tete) soit vrai il faut que tete soit faux. Or quelle est la valeur de tete pour que tete soit faux : c'est NULL.
 
Autrement dit (!tete) <=> (tete != NULL)

--Message édité par Toxin--

wouatouwouatou a écrit a écrit : Merci d'avoir corrigé Toxin ... Moi avoir pas vu kil mankai une star devant T (Mr.)

 
De rien moi aussi je me suis fait avoir par le passé

Je te remercie. Je ne vais pas me justifier ( enfin si =) ), c'est ma premiere année de C, on a commencé il y a 3 mois. Le prof est loin d'etre mauvais, mais son cours ne me semble pas tres efficace. Je veux dire qu'il oriente la chose vers des choses qu'il aime bien. Il n'a surement pas passer assez de temps sur les bases : le rappel que tu viens de me faire je n'en ai jamais entendu parler.
 
Enfin, c comme ca qu'on apprend. @+ all.

JE te plain...
 
Mais, c le truc utilisé surtout dans les boucles infinie du genre
 
while(1); <=> while ( 1 == 1 )
 
Je le laisse deviner ce ke donne : while(0);

Tu sais qu'à part les représentations de flottant, tout est entier en C ?

Non je savais pas. Ca a quoi comme consequences ?

bah.. tu peux traiter des chaines de caracteres par exemple comme si c t des nombres

Désolé de jouer les rabat-joies, mais pour des raisons de lisibilité de votre code, je me permets de vous déconseiller très fortement les tests du genre :
    if (!tete) ...
    if (!n) ...
    if (!object) ...
 
Préférez toujours :
    if (object != NULL) ...
    if (n != 0) ...
qui est mille fois plus clair à relire (au moins), et qui n'enlève absolument rien à l'efficacité du code généré par le compilateur.
 
La recommendation ci-dessus accepte une seule exception : quand l'expression que l'on teste est déjà de type booléen. Parce que justement, dans une condition, on doit trouver une expression booléenne (donc c'est inutile de comparer ce booléen avec un autre booléen pour obtenir... un booléen). Vous allez me dire, pour C, un booléen, c'est un int, mais ce n'est pas parce que C est un langage sémantiquement très pauvre qu'il faut rester à son niveau. On y gagne toujours en ajoutant de la sémantique. D'ailleurs, je vous conseille aussi de définir un type booléen si vous n'en avez aucun à votre disposition. En fait, un simple :
    typedef int BOOL;
    #define TRUE  1
    #define FALSE 0
suffit très largement, et encore une fois, cela n'enlève rien à l'efficacité du code généré par le compilateur.

Je prends note ! Et à propos des pointeurs, si par exemple toto est un pointeur sur une structure avec un champ nom.
 
La " bonne " habitude serait d'écrire (*toto).nom ou toto->suivant ?
 
Sinon, si qqun à une url donnant de bonnes habitudes de prog, ca m'interesse )
 
@+

Tu veux dire pour accéder au champ ? "toto->nom" paraît moins lourd, non ?

c simplement une kestion de lisibilité je crois... Il me semble ke les 2 ecritures sont semblable pour la machine... enfin, a confirmer...
Moi je prefere (*nom) simplement a cause des declaration de pointeur ki rappelle cette ecriture... "char *nom;"
Mais d'autres, prefere la fleche ...