Discussion :

[Pragmateek]

L'initialisation doit se faire à la déclaration ou immédiatement après pour éviter tout risque de comportement indéterminé.

[AjJi]

Si on l'utilise par inadvertance il y a risque de comportement indéfini.
C'est une sécurité.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
int a;
printf("%d",a);

oui, ce cas me parait trivial
On oublie l'initialisation surtout dans des cas comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
int s;
int i;
for(i=0;i<5;i++) s+=i;

Donc, si j'ai bien comprit ce que Emdel voulait dire, "Mieux vaut intialiser les variables tout le temps, que de se demander qd faut-il le faire"

[Emmanuel Delahaye]

Toutes les variables du programme doivent être initialisés ?

Je n'ai jamais dit ça.

'utilisation' signifie 'accès en lecture et utilisation de la valeur lue'.

Personnelement, je n'initialise que les compteurs, ou des variables qui vont contenir des sommes, produits, ... mais pas toutes, je peux savoir en quoi ca pourrait être "dangereux" de ne pas tout initialiser ?

[Emmanuel Delahaye]

Donc, si j'ai bien comprit ce que Emdel voulait dire, "Mieux vaut intialiser les variables tout le temps, que de se demander qd faut-il le faire"

Pas du tout, et cette pratique pourrait valoir une Force 2 ou 3 selon mon humeur

[Emmanuel Delahaye]

L'initialisation doit se faire à la déclaration ou immédiatement après pour éviter tout risque de comportement indéterminé.

Pas forcément. Attention à ne pas déformer mes intentions.

[Pragmateek]

Pas forcément

Autant que possible ça évite des soucis, notamment avec les pointeurs:
mieux vaut un pointeur initialisé à NULL qui fait planter qu'un autre non initialisé qui fait insidieusement croire que tout va bien.

[Emmanuel Delahaye]

Autant que possible ça évite des soucis, notamment avec les pointeurs:
mieux vaut un pointeur initialisé à NULL qui fait planter qu'un autre non initialisé qui fait insidieusement croire que tout va bien.

OK. Mais ça dépend comment est organisé le code. En principe on évite de faire 2 écritures consécutives sans une lecture entre les deux..

Mais bon, c'est pas faux, c'est juste redondant...

[Jack_serious]

Ca peut servir quand meme.

Pour une fonction de liberation des ressources par exemple. Comme ca on ne libere que ce qui a deja ete alloue, i.e. les pointeurs non nuls.

Pratique pendant une initialisation, ca evite de faire une serie de free() pour chaque erreur possible. On ne libere que ce que a deja ete alloue.

Dans ce cas on fait deux ecriture consecutives sans lecture, mais ca simplifie le code.

[gnto]

que pensez vous de l'usage abusif de Macros
Bon aller je balance

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#define FLOAT 0x0001
#define SHORT 0x0002
#define CHAR 0x0003
#define STRING 0x0004
.
.
.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
int type;
...
switch (type)
{
#define BELLE_MACRO(TYP,VAR1,VAR2,MACRO)  \
    case TYP:  \
        {  \
            ... \
        }  \
        break;
    case CHAR:
    case STRING:
        break;
        BELLE_MACRO(SHORT,  var1,  var2,  SHORTMACRO)
        BELLE_MACRO(FLOAT,  var1,  var2,  FLOATMACRO)
        .
        .
        .
    default:
        fprintf(stderr,"error invalid type\n");
#undef BELLE_MACRO
}

voila je l'ai simplifié en espérant que ca puisse compiler bien que je n'ai pas définie SHORTMACRO et FLOATMACRO mais le plus important n'est-il pas d'admirer ?

[Gruik]

On peut utiliser #define en plein milieu de fonction??

Sinon j'ai deja vu des mega macros (une 20aine de lignes, peut être plus) dans le code source de PHP
Dans ces cas là, c'est mieux une fonction inline

[Emmanuel Delahaye]

On peut utiliser #define en plein milieu de fonction??

Pourquoi pas ? Le préprocesseur n'a pas de contrainte particulière à part une organisation par ligne plutôt que par token...

Je remarque qu'ici, c'est bien fait, car la définition est 'temporaire' (#undef).

Sinon j'ai deja vu des mega macros (une 20aine de lignes, peut être plus) dans le code source de PHP
Dans ces cas là, c'est mieux une fonction inline

En C99, c'est sûr. Sinon, on fait comme on peu...

[Médinoc]

Enfin, il y a des choses qu'une fonction inline ne peut pas faire:
Par exemple, des déclarations.

Ou bien, à des fins d'affichage, débogage ou journalisation:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
#define CASENAME(x) case x: sczRet= #x ; break;
 
char const * SomeConstantToString(int someConstant)
{
char const *sczRet = "(inconnu)";
 
switch(someConstant)
	{
	CASENAME(UNE_CONSTANTE)
	CASENAME(UNE_AUTRE_CONSTANTE)
	}
return sczRet;
}

Evidemment, en C++, on peut utiliser un tableau associatif, mais des macros peuvent là encore être utiles pour l'initialiser...

[gege2061]

Enfin, il y a des choses qu'une fonction inline ne peut pas faire:
Par exemple, des déclarations.

Mais de toutes façon le mot clés inline n'est qu'une indication pour le compilateur, il n'est pas obligé d'en tenir compte.

[gnto]

perso des macros qui generent des cas je trouve ca moche.
C'est pas bon pour fluidifié la lisibilté. Pour 4 cases c'est pas la peine.
C'est pas comme si y'en avais 256

[Emmanuel Delahaye]

perso des macros qui generent des cas je trouve ca moche.
C'est pas bon pour fluidifié la lisibilté. Pour 4 cases c'est pas la peine.
C'est pas comme si y'en avais 256

Dans ce cas, je travaille par liste externe... (.itm)

http://emmanuel-delahaye.developpez.com/clib.htm

[Médinoc]

perso des macros qui generent des cas je trouve ca moche.
C'est pas bon pour fluidifié la lisibilté. Pour 4 cases c'est pas la peine.
C'est pas comme si y'en avais 256

Je pensais justement à des trucs bien nombreux, comme les Window Messages (pour du débuggage) ou les constantes d'erreur (en complément de FormatMessage())

Emmanuel : Tiens, c'est une idée... Une bonne idée, même...

[Emmanuel Delahaye]

Emmanuel : Tiens, c'est une idée... Une bonne idée, même...

Tu parles des .itm ? Oui, il y a des moments où il faut laisser le préprocesseur travailler. Il écrit le code répétitif sans se tromper, lui...

[berg]

je viens de lire lechelle de Goret et je pense que c'est l'une des premieres chose a apprendre a tous programmeur. Quand je vois des fonction qui font plus de 300 lignes avec comme commentaire ce que fait la fonction et que l on doit les étudier .... on a presque envie de tuer celui qui a fait le code ^^.
Le pire c est que tout le monde (aussi bien les novices que les experts font ce genre d erreurs).

[Jack_serious]

je viens de lire lechelle de Goret et je pense que c'est l'une des premieres chose a apprendre a tous programmeur. Quand je vois des fonction qui font plus de 300 lignes avec comme commentaire ce que fait la fonction et que l on doit les étudier .... on a presque envie de tuer celui qui a fait le code ^^.
Le pire c est que tout le monde (aussi bien les novices que les experts font ce genre d erreurs).

Les fonctions de 300 lignes ? Ah non surement pas...

Parce que c'est pas seulement chiant pour le mec qui va relire le code, ca l'est surtout pour toi quand tu developpe et que tu dois debugguer.

Faire du code bien structure est la premiere chose a apprendre.

[gnto]

Les fonctions de 300 lignes ? Ah non surement pas...

Parce que c'est pas seulement chiant pour le mec qui va relire le code, ca l'est surtout pour toi quand tu developpe et que tu dois debugguer.

Faire du code bien structure est la premiere chose a apprendre.

Et l'inverse c'est chiant plein de petite focntion moins de 15 lignes. argg...