C et C++ mythe et realité

Citation:

---

Envoyé par doccpu

Citation:

---

Envoyé par mongaulois

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

Code:

---

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:

---

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:

---

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

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é :lol:.

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:

---

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.

Citation:

---

Envoyé par doccpu

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:

---

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

Citation:

---

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 :D

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:

---

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.

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

Goret Force 2, ça va :mouarf:

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 :P

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 ;):P

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

Citation:

---

Envoyé par 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:

---

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:

---

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

---

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

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

Citation:

---

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

---

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

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

Citation:

---

Envoyé par Miles

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?? ;)

Citation:

---

Envoyé par Luc Hermitte

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 :?

Citation:

---

Envoyé par Mongaulois

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

---

Dans la norme.

Citation:

---

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

---

Code:

---

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)

Citation:

---

Envoyé par Mongaulois

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:

---

#define NULL ((void*)0)

---

mais par exemple par

Code:

---

#define NULL 0

---

ou

Code:

---

#define NULL __null_ptr

---

Citation:

---

Envoyé par Jean-Marc.Bourguet

Code:

---

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 ?

Citation:

---

Envoyé par Sylvain Togni

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

Citation:

---

Envoyé par millie

Code:

---

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.

Citation:

---

Envoyé par millie

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