C et C++ mythe et realité

**millie** · 06/09/2007, 22h55

Je parlais pour le C en fait.

**Luc Hermitte** · 07/09/2007, 00h39

Envoyé par Mongaulois

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

C'est dans les premières pages, il y a un lien vers les différences. Mais il est vrai que je me souviens de différences que l'on avait tapées nous-même. Ah ah. C'était là, je savais que je n'avais pas révé (page 2), mais il y en a bien plus dans le lien de l'autre fil.

Pour ce qui est de la date, ce n'est pas comme si les normes avaient profondément changé depuis 2002/2003 sur les différences C vs C++.

Pour le nul pas nul, c'est juste une histoire d'habitude. Il n'y aura aucune différence en terme d'opscodes finaux. Après il y a ceux qui pensent en pointeurs nuls ou pas, et ceux qui pensent en données valides ou pas.
Idiomatiquement parlant, le C++ nous pousse à être des gorets de force 2 quand on gère nos flux. Franchement, il n'y a pas de quoi se prendre le choux avec tout cela. J'avais même croisé des interprétations de specs qualité comme quoi il fallait toujours mettre des ==true ou ==false dans les tests. Le genrede trucs qui ferait écrire

Code :

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

if ((((p == 0) == true )== true)==true ....)

si on poussait cette étrange logique jusqu'au bout.

doccpu · 07/09/2007, 00h53

Envoyé par Mongaulois

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

ok c exact j'avais pas lu l'avertissement sur le forum de :
Forum des développeurs > Général Développement > Débats sur le développement - Le Best Of

D'ou mon comportement cavalier.

mais la y a un truc qui m'echape on est bien dans :
Forum des développeurs > C et C++ > C++ > C et C++ mythe et realité

donc on est pas dans le forum :
Forum des développeurs > Général Développement > Débats sur le développement - Le Best Of

alors pourquoi vous êtes la ?

ensuite je ne vois pas ce qu'il y a de constructif a trouver tous les cas d'ambiguïté de la norme tout le monde sait qu'il y en a une infinité alors a quoi bon les recenser ?

Si vous trouvez que la norme n'est pas au top pourquoi ne pas la refaire à ce moment la ? Ce qui serais encore mieux ce serais de proposer des outils permettant de passer de la norme actuelle a votre nouvelle norme. Non ?

Je ne trouve vraiement pas constructif de faire ce genre de brainstorming sur ce qui pourais ne pas marcher dans telle ou telle implémentation de compilateur. J'ai même cru un moment que j'avais atterris dans la quatrième dimension ou l'informatique ne correspondais plus a ce que je connaissait d'elle. Sans vouloir vexer personne une norme est un document rédigé par des hommes et comme l'erreur est humaine il ne sert a rien de chercher les défauts . Tout le bénéfice serais plutôt d'en chercher tous les avantages et de les périniser en faisant en sorte de garder les bon cotés et d'eliminer les coté plus douteux. ok la norme ne définis pas les incrémentations doubles (++i*--i) et ya plus qu'a les définir.

Par exemple : GCC (je sait pas si c'est dans la norme officielle ou pas) crée un bug avec la fonction read qui est censé lire un fichier jusque a la fin. le problème c'est que si le fichier comporte un -1 il arrete de lire et retourne une fin de fichier mais en fait le curseur n'a pas atteint la fin de fichier. ayant identifié le problème je me suis réécrit le morceau de code en utilisant des couches de plus bas niveau affin de ne plus avoir a vérifier que le curseur soit a la fin du fichier ou pas. je ne comprend pas que des types comme vous (les droso-philes) n'ai pas pensé a le faire plus tot ? je veux dire que le c++ n'est pas tout jeune (25 ou 30 ans) et je ne le connais bien que depuis quelque années ce qui m'a stupéfais c'est que avec tout le monde qui a travaillé dessus personne n'ai pensé a l'améliorer ou a corriger ses bugs. par contre à coté de ça on vois des ingé qui se masturbe le cervo pour faire en sorte que l'on garde la norme au bug près. cela me parais totalement aberrent !

je comprend que le c++ de microsoft ait été si fortement publicité a chaque nouvelle version ils créent des outils de moins en moins buggés et de plus en plus efficaces en termes de vitesse de développement. Si l'on est pas capable de faire evoluer un programme il finit par péricliter parce que le marché, lui, évolue constamment. on a besoins de solutions de plus en plus efficaces et de plus en plus robustes. alors arrêtez de craner a faire valoir vos connaissances de la norme et faites ce qu'il faut pour qu'elle soit la plus simple possible et la plus robuste possible. Enfin je ne comprend pas que la norme n'ai pas suivis les règles de priorités des opérateurs en matière de sens de lecture du code comme on la trouve en mathématique car je pense que les droso-philes ne me contrarieront pas sur ce point l'informatique est un sous ensemble des mathématiques et donc elle devrais se plier aux même règles en matière de lecture.

une calculette scientifique qui en effectuant le calcul 2 + 3 * 5 - 1 me sort 24, je sait pas vous mais moi je la jette. Donc puisque la norme est incomplète voir inexacte dans certains cas (read(FILE*);) pourquoi ne pas la compléter et/ou la corriger ?

cordiallement

ps : je n'aime pas M$ mais forcé de constater qu'ils ont la meilleure stratégie.

**Luc Hermitte** · 07/09/2007, 01h30

Souvent, des questions innocentes sont posées (comme ce fut probablement le cas il y a quelques pages de cela), et puis chacun y donne de son avis basé sur ses expériences. Dans ce cas particulier la seule bonne réponse est "unspecified behaviour". Affirmation qui aurait dû être terminale, mais non, plusieurs n'ont pas voulu en démordre, certains que leur compilo avait plus raison que les autres. Bref.

Je crois que tu es passé à côté d'un point: comment fonctionne le commité de normalisation du C++. Et ce qu'est la norme du C++.
Pour la norme, un certain nombre de choses sont précisément définies. Et d'autres sont "unspecified behaviour", tandis que d'autres sont "undefined". C'est dit en clair dans la norme (enfin, quand on sait la lire -- "décrypter" est parfois plus juste).

Pourquoi ces zones de "flou" ? Pour que les fournisseurs de compilo puissent exploiter au mieux les architectures sur lesquelles nous allons compiler. Et parfois, je soupçonne que leur existant fait qu'ils ne veulent pas introduire des regressions juste pour être comme les autres sur des trucs complexes/inutiles/...

La norme évolue. Lentement. Et sur ce point précis le C++09 (09 si tout va bien) ne changera rien. Un draft est dispo en ligne.

Et ce n'est pas nous qui allons changer quoique ce soit (du moins comme ça en discutant ici). La norme du C++ est un document ANSI/ISO que respectent les compilos (avec des écarts). Cen'est pas parce que je vais dire demain que "++n*--n" doit valoir 42 au lieu de 25 que mon compilo va m'écouter. La seule chose qui me soit autorisée, c'est d'éviter d'écrire des choses dont je sais pertinemment que le compilo interprétera comme LUI en a envie. C'est un fait, c'est comme ça, il n'y a pas à pinailler sur ce que cela devrait être. Accessoirement, les "pinailleurs" qui se sont exprimés ici acceptent parfaitement cet état de fait -- état de fait qui suit la maxime it's not a bug, it's a feature

Pourquoi on est là ? Parce que l'on parle de C++ et pas de C++ sur PC?

EDIT: pour l'histoire du read(), je n'ai rien capté. Si tu as trouvé un bug, contacte les mainteneurs de GCC. Sinon, attention aux idiomes de lecture de fichiers en C et C++ -> pas de 'while feof', mais 'while read', attention au mode d'ouverture.

**koala01** · 07/09/2007, 02h38

Je crois, justement, que ce qui est le plus important dans la norme, c'est presque... ce qu'elle ne définit pas.

Selon moi, savoir ce qui n'est pas défini dans la norme est bien plus utile que de savoir ce qui l'est, pour une raison toute simple:

Je sais, par exemple, que la norme ne spécifie pas le nombre de bits utilisés par les types primitifs (char, int, long...)

De ce fait, j'évite de partir du postulat (pourtant vérifiable chez moi) que

un char fait 8 bits, un short 16, un int 32, etc.

De cette manière, si pour une raison quelconque le code que je crée n'est pas compilé dans les mêmes circonstances que celle dans lesquelles je l'ai écrit (compilateur, système et architecture identique), l'application continuera à fonctionner de manière cohérente.

Si tu écris un code au départ du postulat que, sur ton ordinateur, avec ton compilateur et sous ton système

int i=5; total=++i*--i; donne 25

et si, pour une raison quelconque, ton code est compilé dans d'autres circonstance, tu obtiendra, au mieux, des résultats aberrants.

Il ne s'agit nullement de vouloir "refaire la norme", il s'agit simplement d'indiquer le danger du

attention, c'est valable pour toi, mais pas forcément pour un autre parce que la norme a été suffisamment intelligente pour laisser cette implémentation à l'appréciation du codeur.

**Jean-Marc.Bourguet** · 07/09/2007, 09h30

Envoyé par gl

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

Oui. Mais en C++ il n'y a pas de VLA.

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

Pour le C comme pour le C++, NULL doit etre une constante entiere nulle. De plus, le C autorise le cast vers void* (mais ne l'impose pas).

Envoyé par nikko34

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

Si tu enleves tout ce qui est comment avec le C, il ne reste pas grand chose d'utilisable.

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

Les avis sur ce point sont tres partages, avec de bons arguments des deux cotes. Personnellement, je rale parce que ma preference oscille, ce qui est encore le pire

**progfou** · 07/09/2007, 09h35

Pourquoi insulter les gens doccpu ? C'est interdit (même en écrivant drosophile, moyen détourner d'insulter)...

Donc, si ce topic te paraît inutile, pas à sa place, etc. rien ne t'empêche de ne pas le suivre !
A bon entendeur...

**yan** · 07/09/2007, 10h04

Envoyé par progfou

Pourquoi insulter les gens doccpu ? C'est interdit (même en écrivant drosophile, moyen détourner d'insulter)...

Donc, si ce topic te paraît inutile, pas à sa place, etc. rien ne t'empêche de ne pas le suivre !
A bon entendeur...

Je pense que c'est parcequ'il ne veut pas accepter qu'il as dit des conneries.

Pour revenir sur le principe de ce topic, je pense que koala01 explique le gros problème.
Enfaite y en a plusieurs pour moi :
1 - Aider les gens (dont moi) à comprendre la différence entre le C et C++
2 - De répertorier les différences, pour ne pas se trouvais complètement larguer (m'est déjà arrivé) et perdre plusieurs jours parce qu'un projet mélange du C et C++
3 - Eviter d'écrire des choses qui marche un jour mais pas demain (ex : i =++n * --n;; ou ce thread )
4 - Echanger les experiences

Ce qui est drôle c'est que doccpu montre bien que l'expérience (si il en as, ce que je pense, il ne dit pas que des conneries non plus) ne fait pas tous. Quelqu'un qui développe sur VC 6 pendant 5 ans et pense être un master en programmation, risque de pleuré le jours où l'on va lui demander de développer avec un autre compilot car il aura oublié plein de const, ou autre boulette qui ne marche que sur VC 6.
Faut savoir se remettre en cause de temps en temps, cela ne fait pas de mal, et ça permet de s'améliorer.
En tout cas j'ai appris et compris plein de chose depuis le début de ce thread, qui as ma grande joie n'est pas encore devenue un gros troll, merci d'essayer (en particulier doccpu en arrêtant de prendre les gens pour des con) à ce que cela n'en devienne pas un

merci

**NiamorH** · 07/09/2007, 10h09

C'est surtout qu'il est seul a défendre une idée saugrenue (et je ne veux pas entendre "oui mais lorsqu'on disait que la terre était ronde ça paraissait absurde aussi"...).
Ne pas tenir compte de la norme actuelle, c'est jouer à la roulette russe.

Je ne trouve vraiement pas constructif de faire ce genre de brainstorming sur ce qui pourais ne pas marcher dans telle ou telle implémentation de compilateur.

Du jour au lendemain, celà pourrait ne plus marcher sur une simple MAJ du tien. Et puis, faire du code non portable est un choix, mais ne nous l'impose pas en étant aggressif avec ceux qui cite la norme s'il te plaît.

J'ai même cru un moment que j'avais atterris dans la quatrième dimension ou l'informatique ne correspondais plus a ce que je connaissait d'elle. Sans vouloir vexer personne une norme est un document rédigé par des hommes et comme l'erreur est humaine il ne sert a rien de chercher les défauts .

Tu ne fais d'erreurs toi par contre ?

Par exemple : GCC (je sait pas si c'est dans la norme officielle ou pas) crée un bug avec la fonction read qui est censé lire un fichier jusque a la fin.

Rien à voir, GCC n'est qu'un compilateur qui tente de suivre la norme, s'il est buggé change de compilateur...

je ne le connais bien que depuis quelque années ce qui m'a stupéfais c'est que avec tout le monde qui a travaillé dessus personne n'ai pensé a l'améliorer ou a corriger ses bugs.

Il n'y pas de bugs dans la norme, seulement dans les compilateurs.

par contre à coté de ça on vois des ingé qui se masturbe le cervo pour faire en sorte que l'on garde la norme au bug près. cela me parais totalement aberrent !

Tu n'a évidement pas compris ce qu'était la norme.

Enfin je ne comprend pas que la norme n'ai pas suivis les règles de priorités des opérateurs en matière de sens de lecture du code comme on la trouve en mathématique car je pense que les droso-philes ne me contrarieront pas sur ce point l'informatique est un sous ensemble des mathématiques et donc elle devrais se plier aux même règles en matière de lecture.

Je ne suis pas un expert des mathématiques, mais je ne suis pas sûr qu'on puisse écrire ++i en maths. Or c'est l'un des seul opérateur qui pose problème dans notre cas C++. Je te rappelle qu'en maths, tu peux calculer (1 + 5) - (9 + 8) en commençant par la parenthèse de droite, donc de quoi parles tu pour le sens de lecture ?...

**Luc Hermitte** · 07/09/2007, 10h24

En maths, nous manipulons effectivement des valeurs, du moins non des entités pouvant être altérées dans des fonctions. De x, on passe à x'. x ne change jamais dans x |--> f(x). En cela, les opérateurs d'incrémentration (/dec) ne m'ont pas l'air d'avoir grand chose de mathématique.

**yan** · 07/09/2007, 10h51