Echelle de Goret

Version imprimable

Voir 40 message(s) de cette discussion en une page

02/06/2006, 21h44
Pragmateek

L'initialisation doit se faire à la déclaration ou immédiatement après pour éviter tout risque de comportement indéterminé.
02/06/2006, 22h06
AjJi
Citation:
Envoyé par seriousme

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

Code:

1 2 int a; printf("%d",a);
oui, ce cas me parait trivial :)
On oublie l'initialisation surtout dans des cas comme ça :
Code:

1 2 3 4 int s; int i; for(i=0;i<5;i++) s+=i;
:mrgreen:
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" :aie:
02/06/2006, 22h21
Emmanuel Delahaye

Citation:

Envoyé par AjJi

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'.

Citation:

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 ? :)
02/06/2006, 22h24
Emmanuel Delahaye

Citation:

Envoyé par AjJi

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" :aie:

Pas du tout, et cette pratique pourrait valoir une Force 2 ou 3 selon mon humeur
02/06/2006, 22h25
Emmanuel Delahaye

Citation:

Envoyé par seriousme

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.
02/06/2006, 22h34
Pragmateek

Citation:

Envoyé par Emmanuel Delahaye

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.
02/06/2006, 23h16
Emmanuel Delahaye

Citation:

Envoyé par seriousme

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...
02/06/2006, 23h45
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.

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

Code:

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

Code:

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 ?

03/06/2006, 12h10
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
03/06/2006, 12h47
Emmanuel Delahaye

Citation:

Envoyé par Gruik

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).

Citation:

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...

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:

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...

03/06/2006, 15h04
gege2061

Citation:

Envoyé par Médinoc

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

8O

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.
03/06/2006, 16h40
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 ;)
03/06/2006, 16h50
Emmanuel Delahaye

Citation:

Envoyé par 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 ;)

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

http://emmanuel-delahaye.developpez.com/clib.htm
03/06/2006, 19h00
Médinoc

Citation:

Envoyé par 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 ;)

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...
03/06/2006, 21h11
Emmanuel Delahaye

Citation:

Envoyé par Médinoc

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...
04/06/2006, 16h08
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).
04/06/2006, 16h28
Jack_serious

Citation:

Envoyé par 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).

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.
04/06/2006, 16h38
gnto

Citation:

Envoyé par Jack_serious

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...

Voir 40 message(s) de cette discussion en une page