Discussion :

[yan]

en récrivant correctement le code (dsl j'ai ecrit un peu vite)

Code C++ :

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

1
2
3
4
int tab[] = {1,2,3,4,5,6,7,8,9};
int id =0;
 
int somme = (*tab) + 4*(*(++tab)) + 10*(*(++tab)) + 5*(*(++tab)) + (*(++tab));

Cela compilerai ou y as un truc qui m'échappe?
Par contre,merci pour le comportement indéfini, j'ai compris le truc

là tu fait compliqué pour faire simple :

Code C++ :

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

1
2
3
4
5
6
7
8
 
int tab[] = {1,2,3,4,5,6,7,8,9};
int somme = 0;
 
for(int i = 0; i < 9, i++)
{
    somme += tab[i];
}

ou si tu veux faitre plus complexe puisque apparement tu aime ça:

Code C++ :

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

1
2
3
4
5
6
7
8
 
int tab[] = {1,2,3,4,5,6,7,8,9};
int somme = 0;
int i = 0;
while(i < 9)
{
    somme += tab[i++];
}

Le but est uniquement de montrer le problème pas de faire compliquer.
Ce que j'ai écrit est indéterminé, par ce que tu as réécrit

[progfou]

Eh bien, j'ai pas suivi ce topic depuis un moment, et ya du monde dessus maintenant !
Mais effectivement, quand j'ai lu le messagde de mongaulois, j'avais bien compris le principe du comportement indéterminé (méconnu par la plupart des développeurs). Et ton message, doccpu m'a fait marrer... Et tous les autres aussi, car tu survoles souvent les messages, et du coup, tu réponds... à côté .

Du coup, ça pollue ce topic, AMHA, depuis au moins une page.
C'est une remarque en passant.

Sinon, j'ai bien aimé le fait que le code :

Code :

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

1
2
3
4
5
6
7
8
9
10
void TestArray2(void)
{
	int tab[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
	size_t i = 0;
	int res1 = tab[++i] + tab[++i] + tab[++i] + tab[++i] + tab[++i];
 
	i = 0;
	int res2 = tab[i++] + tab[i++] + tab[i++] + tab[i++] + tab[i++];
	printf("resultat 1: %d - resultat 2: %d\n", res1, res2);
}

Le fait que Visual et GCC ne donnent pas le même résultat est symptomatique des problèmes que l'expérience seule ne peut résoudre.

[koala01]

dans ton cas il attaque la memoire pour savoir si il est egal a la constante non nomé 0 dans l'autre il ne le fait pas.

Attention, ce n'est pas parce que tu n'écrit pas quelque chose qu'il ne le fait pas...

Crées un simple code du genre de

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
class maclass
{
    public: 
        maclass(int a=0):a(a){}
        void add1(){a++;}
        bool ok(){return a==0;}
    private:
        int a;
};
 
int main()
{
    maclass *obj=new maclass()
    if( obj && obj->ok())
        obj->add1();
    return 0;
}

Demande au compilateur de te sortir le code assembleur (typiquement
gcc test.cpp -S)

Modifie le test en if(obj!=0 && obj->ok()) et compare le code assembleur fournis.

Tu remarquera que, selon les options d'optimisations fournies, mais en fournissant les même options d'optimisation à chaque fois, tu obtiendra un code assembleur identique à la virgule près.

Et c'est normal:

Même si tu ne précise pas le !=0, il doit quand même vérifier si obj (dans le cas du code fournis ici) existe ou non... Mais tu ne le dis pas

mais comme tu l'a dit ca peux aider les débutant et comme ca change rien au shmilblic faites ce que vous prefferez

Même pour les "non débutants"...

Tous les fichiers, entre leurs modifications sont "write once, read ever" (écrit une fois, lu souvent), et un code source ne fait pas exception.

Si tu maîtrise parfaitement l'état dans lequel tu es lors de l'écriture du code ou de sa modification, tu ne peux absolument pas préjuger de l'état dans lequel sera n'importe qui susceptible de le lire lorsqu'il le lira:

C'est peut etre quelqu'un de peu habitué au raccourcis C ou C++, il/elle est peut être creuvé(e) parce que son gosse a eu de la fièvre toute la nuit, il pense peut être à sa femme qui a eu un accident de voiture ou...

Ecrire !=0 (ou !=NULL) va prendre, à tout casser, 2,5 secondes... et le temps gagné par le fait de l'avoir explicité pour la personne qui le lit sera bien souvent largement supérieur à cela ...

Moralité, perdons un peu de temps à l'écriture et assurons nous que la lecture et la compréhension seront rapide

[screetch]

moi j'ai une approche differente sur le (if p && p->test()) :

je prefere ne pas mettre le test.

en effet pour moi cela alourdit en

Code :

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

1
2
 
if( p != NULL && p->test() )

qui est plus dur a lire du fait que je dois mettre moi meme les operateurs dans le bon sens.

J'ai pris la gymnastique if(p) et if (p && p->test()) et desormais je passe plus de temps sur les expressions avec != 0.

[millie]

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

Goret Force 2, ça va

[koala01]

Je dirais que, tant que ton code n'est destiné à être lu que par toi, tu est tout à fait libre de faire strictement comme bon te semble.

Le problème se pose quand... ton code est destiné à être lu par une personne qui n'a pas forcément écrit le code

Et les occasions sont nombreuses: le travail collaboratif se décline en plusieurs mise en oeuvres réelles

Et dans ce cas, il faut au minimum que tout le monde soit d'accord pour adapter des conventions de codages identiques... Sinon, cela devient la foire aux chapeaux

[NiamorH]

Pour mettre mon grain de sel, je ne suis pas sûr que NULL soit du C++

[yan]

moi j'ai une approche differente sur le (if p && p->test()) :

je prefere ne pas mettre le test.

en effet pour moi cela alourdit en

Code :

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

1
2
 
if( p != NULL && p->test() )

qui est plus dur a lire du fait que je dois mettre moi meme les operateurs dans le bon sens.

J'ai pris la gymnastique if(p) et if (p && p->test()) et desormais je passe plus de temps sur les expressions avec != 0.

an faite pour un if oui mais pour un for...

je préfère cette écriture

Code C++ :

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

for (...;p!=0 && p->test();...) {...}

j'utilise pas NULL car ce n'est pas du C++

[koala01]

NULL n'est jamais qu'un #define qui prend différentes versions selon le compilateur (allant de #define NULL 0 à #define NULL (void*)0 )

Il est apparut dans le C, mais il reste tout à fait correct de l'utiliser en C++, d'autant plus que, l'inclusion en cascade aidant, on le retrouve en incluant la grande majorité des en-têtes standards

[yan]

NULL n'est jamais qu'un #define qui prend différentes versions selon le compilateur (allant de #define NULL 0 à #define NULL (void*)0 )

Il est apparut dans le C, mais il reste tout à fait correct de l'utiliser en C++, d'autant plus que, l'inclusion en cascade aidant, on le retrouve en incluant la grande majorité des en-têtes standards

sa vrai définition est
#define NULL (void*)0
mais en C++ tout ne peut pas etre casté en void *
donc c'est du C et non du C++.
D'ailleur dans C++0x il y aura nullPtr normalement

[NiamorH]

à moins d'ajouter l'include de windows.h dans VC, il ne veut pas de mon NULL. Je doute au contraire que ce soit bien de l'utiliser dans du code portable à moins de le définir soi-même...

[yan]

L'initialisation s'effectue dans l'ordre de déclaration des variables dans la classe.

C'est dans la norme, ou c'est par expérience??

[yan]

Cf le threads C vs C++, quantité de cas y ont été déjà énumérés.

j'ai regardé le thread C++ vs C. Si c'est bien celui la que tu parle.
Je dirai juste :
1- les réponses commence a être vielle
2- pas trouvé beaucoup de vrai exemple

[Matthieu Brucher]

C'est dans la norme, ou c'est par expérience??

Dans la norme.

[millie]

à moins d'ajouter l'include de windows.h dans VC, il ne veut pas de mon NULL. Je doute au contraire que ce soit bien de l'utiliser dans du code portable à moins de le définir soi-même...

Code :

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

1
2
3
4
5
6
7
8
#include <iostream>
 
int main()
{
	int * i = NULL;
 
	return 0;
}

Compile sans problème avec gcc (mingw ou unix)

[Sylvain Togni]

sa vrai définition est
#define NULL (void*)0
mais en C++ tout ne peut pas etre casté en void *
donc c'est du C et non du C++.

Non, la norme C++ spécifie que NULL doit être une constante entière de valeur zéro. Donc NULL est bien du C++ et ne peut pas être definie par

Code :

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

#define NULL ((void*)0)

mais par exemple par

Code :

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

#define NULL 0

ou

Code :

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

#define NULL __null_ptr

[gl]

Code :

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

1
2
3
4
5
6
7
8
9
10
int const size = 10;
int const val = size*2;
int f();
int const val2 = f();
 
int f()
{
    int tab[size];
    return 42;
}

Est du code valide en C++, contient 3 erreurs en C (val, val2, tab).

Sauf erreur de ma part, en C99 tab devrait etre valide (VLA), non ?

[millie]

Non, la norme C++ spécifie que NULL doit être une constante entière de valeur zéro.

Il me semblait d'ailleurs que la norme ne disait pas ça (j'ai souvent entendu dire par Emmanuel qu'il fallait juste que NULL soit une adresse non valide (typiquement, qui produit une erreur de segmentation)).

[NiamorH]

Code :

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

1
2
3
4
5
6
7
8
#include <iostream>
 
int main()
{
	int * i = NULL;
 
	return 0;
}

Compile sans problème avec gcc (mingw ou unix)

Ah, bien vu.

En faisant "aller à" je vois qu'il est déclaré dans afx.h sous VC. Je pensais que c'était du MFC.

[nikko34]

Il me semblait d'ailleurs que la norme ne disait pas ça (j'ai souvent entendu dire par Emmanuel qu'il fallait juste que NULL soit une adresse non valide (typiquement, qui produit une erreur de segmentation)).

en C++ il n'y a pas de NULL, c'est dans la partie C du C++ que la macro est définie.

pour Bjarne Soustrup, c'est très clair, il utilise juste "0".