Discussion :

[souviron34]

Juste 2 petits commentaires en relisant les 2 dernières pages :

...
Bon, on sort un peu du débat C/C++. Mais l'avantage d'avoir toujours des exceptions (par exemple les références null), c'est par exemple dans une application serveur (genre application Web en J2EE ou je ne sais quoi). Si le l'application a une erreur (genre référence null), l'exception est normalement tout le temps rattrapé et ça permet d'éviter que toute l'application se casse la gueule. Ok, l'application a quand même un bug, mais si le bug est localisé (juste dans une tâche unitaire), ça permet d'éviter qu'une application qui a été mis en production explose complétement, ce qui peut avoir des conséquences importantes.

Bon, cela dit, il est possible de rattraper le signal SIGSEGV en C

Et faire un

Code :

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

1
2
3
4
if ( denominateur != 0.0 )
     divis = numerateur/denominateur ;
else
     divis = NaN ;

C'est trop compliqué ???

(et en plus c'est logique dans le raisonnement mathématique !!!)

Les pointeurs sont dangereux. Le compilateur ne peut pas vérifier ce que l'on fait avec, ce qui rend potentiellement le code peu sûr. Qui n'a jamais eu une erreur de segmentation en codant en C ? Ce genre d'erreur très courant peut parfois même passer inaperçu longtemps, avant que le programme plante.

Et qui n'a jamais eu un "Fatal Error" avec Windows ? ou un serveur ftp/lien Web restant suspendu.. ou le montage d'un CD ou autre chose restant bloqué ... obligeant à ETEINDRE la machine ? Qui a déjà installé (quoi que ça COMMENCE à aller mieux) un logiciel sos W$ SANS AVOIR à redémarrer la machine ???

Ces programmes ne sont pas en C....

Pour mon navigateur web (vous savez FireMachin là, le navigateur qui doit contenir une boucle while(true){malloc 50; sleep 50} vu la quantité de memleak), pour mon lecteur de news (Knoeud, qui sigfaultait trois fois par jour sans raison apparente. Mais il va mieux), ou encore mon modeleur UML (Paraplo... Lui, il crash tous les 12 cliques), c'est completement absurde. Ce que je demande à ces logiciels, ce n'est pas de réagire dans le pouillemme de seconde qui suit une de mes actions

T'en as bien, de la chance, de ne pas t'attendre à ce que quand tu cliques sur un lien ça réagisse vite....



Et je répète... A part depuis quelques années (avec XP) mais la plupart des logiciels Win étaient basés sur Delphi, VB, et autres joyeusetés "de haut niveau", qui les faisiaent crasher régulièrement (ainsi que la machine...)...

Ce n'est pas le langage qui fait qu'un logiciel ne plante pas, c'est le programmeur....

[alex_pi]

Je ne vois pas en quoi le système de typage ou quoi que ce soit ait à voir avec la qualité ou la sûreté d'un code, à part la qualité et le sérieux du programmeur....

Peut être parce que vous n'avez jamais vraiment essayer ? On montre mathématiquement une certain nombre de propriété sur l'absence d'erreur d'un programme correctement typer par exemple. Donc ça *a* quelque chose à voir avec la qualité et la sûrté d'un code.

Cette attitude est pour moi tout à fait représentative de la "société de consommation"... Vaut mieux acheter une armoire IKEA toute faite qui se casse au bout de 3 ans ou une bonne vieille armoire faite par un menuisier qui est toujours debout 150 ans et 45 déménagements plus tard ???

[/QUOTE]
Mais c'est justement totalement l'inverse ! Quand je fais un programme en C, j'ai bien plus l'impression de monter mon truc à la main, avec le risque de mettre des clous aux mauvais endroit. Alors que quand je le fais en OCaml, je fais confiance à des menuisiers de renoms pour toutes les parties critiques de l'application

[gorgonite]

Quand je fais un programme en C, j'ai bien plus l'impression de monter mon truc à la main, avec le risque de mettre des clous aux mauvais endroit. Alors que quand je le fais en OCaml, je fais confiance à des menuisiers de renoms pour toutes les parties critiques de l'application

peut-être est-ce simplement parce que tu ne connais pas les menuisiers de renom qui vont du C... ou que tu dénigres leur travail

[alex_pi]

T'en as bien, de la chance, de ne pas t'attendre à ce que quand tu cliques sur un lien ça réagisse vite....

Euh ouais, fin en même temps, sachant que derière le clique, il y a une requete DNS, l'ouverture d'une connection avec la machine, potentiellement disante de milliers de kilomètre, etc, je ne suis pas totalement persuadé que la microseconde apporté par l'optimisation de derière les fagots en C avec un ptit pointeur de pointeur casté dans je ne sais quoi apporte grand chose par rapport à ma bonne petite fonction en Caml... Les compilos modernes des langages fonctionnels font des miracles.

A vous lire, j'ai quand même l'impression que la dernière fois que vous avez tenté de faire autre chose que du C, c'était il y a 20 ans, vous êtes tombé sur Basic, et vous avez (à fort juste titre...) abandonné. Le monde des langages de programmation a très légèrement évolué depuis, et peut être que "nous les jeunes" (comme vous vous plaisez à nous appeler) avons justement l'avantage de la curriosité de la jeunesse, qui nous a permis de découvrir ces autres langages, de les tester, et d'en comprendre les avantages.

Je suis un bien piètre programmeur, je l'avoue volontier. Néamoins, je n'ai jamais une seule erreur de ségmentation, ou un seul plantage silencieux dans mes programmes. Pourquoi ? Parce que c'est tout simplement impossible dans le langage que j'utilise (sauf à se servir de l'infame module Obj ou Marshall, je vous l'accorde). Et dans 90% des cas, lorsque le code compile (c'est à dire que l'inférence de type réussi), le code est bon et ne nécessite aucun débugage. De plus, les codes sources sont plus court qu'en C, à mes yeux beaucoup plus élégant et logique, et si on compare à temps passé à programmer, les performances du produit fini sont souvent meilleurs que ceux fait en C par d'autres programmeurs d'un niveau équivalent au mien. Parce que ce que vous oubliez peut être, en tant qu'expert informatique, c'est que tout le monde ne l'est pas.

Après, je suis béat d'admiration devant le noyau linux, qui est évidement en C (sauf les parties en ASM). Je ne dis pas qu'il n'est pas possible de faire un programme sûr en C (prenant l'avion régulièrement, je préfère le croire !! Mais je suis aussi bien content de savoir que le code de l'A380 a été statiquement vérifié. Par un programme écrit en OCaml d'ailleurs ;-)), je dis juste que les gardes fous apportés par certain langages sont un réel plus que beaucoup de gens devraient découvrir et utiliser à bon escient.

Il y aura bientôt un nouveau "défi" sur le forum "langages fonctionnels". Venez y faire un tour pour voir de quoi il retourne et ce qu'apportent ces langages. Ca peut valoir le détour ?

[alex_pi]

peut-être est-ce simplement parce que tu ne connais pas les menuisiers de renom qui vont du C... ou que tu dénigres leur travail

Comme je dis un message plus bas, j'admire le boulot des programmeurs du noyau linux, et je l'utilise une dizaine d'heures par jour (qui a dit "no life" ????). Je parle du moment où *moi* je code.

Et l'expérience prouve qu'en moyenne, les programmes en OCaml sont d'une qualité incomparablement suppérieure à ceux en C. Comment ça c'est parce que les seuls personnes qui utilisent OCaml sont des chercheurs, alors que n'importe qui fait du C ??? Mince, ma mauvaise foi est mise à jour :-p

[gorgonite]

Euh ouais, fin en même temps, sachant que derière le clique, il y a une requete DNS, l'ouverture d'une connection avec la machine, potentiellement disante de milliers de kilomètre, etc, je ne suis pas totalement persuadé que la microseconde apporté par l'optimisation de derière les fagots en C avec un ptit pointeur de pointeur casté dans je ne sais quoi apporte grand chose par rapport à ma bonne petite fonction en Caml...

tous les clics ne déclenchent pas une I/O à travers un réseau... donc ça peut avoir son importance (je pense au programme de modélisation 3D, ou un clic peut modifier la structure de l'objet affiché par exemple, ou les rotations d'objets 3D suivant la souris )

A vous lire, j'ai quand même l'impression que la dernière fois que vous avez tenté de faire autre chose que du C, c'était il y a 20 ans, vous êtes tombé sur Basic, et vous avez (à fort juste titre...) abandonné.

je ne suis pas d'accord... en lisant un peu mieux les messages de souviron34, tu verras qu'il a connu et testé plusieurs langages

Je suis un bien piètre programmeur, je l'avoue volontier. Néamoins, je n'ai jamais une seule erreur de ségmentation, ou un seul plantage silencieux dans mes programmes. Pourquoi ? Parce que c'est tout simplement impossible dans le langage que j'utilise (sauf à se servir de l'infame module Obj ou Marshall, je vous l'accorde).

Marshall est très bien... je n'ai jamais planté un de mes programmes l'utilisant

Et dans 90% des cas, lorsque le code compile (c'est à dire que l'inférence de type réussi), le code est bon et ne nécessite aucun débugage.

enfin, sauf si l'algo est erroné... car le plus important c'est quand d'implanter une solution juste

Mais je suis aussi bien content de savoir que le code de l'A380 a été statiquement vérifié. Par un programme écrit en OCaml d'ailleurs ;-))

Astrée ? effectivement... mais il faut aussi se dire qu'il ne trouve pas toutes les erreurs

sinon, y a aussi Lustre pour les systèmes synchrones, mais là encore, il faut avoir conscience qu'il y a des choses qu'on peut vouloir, et qu'on n'arrive pas à écrire en lustre

Il y aura bientôt un nouveau "défi" sur le forum "langages fonctionnels". Venez y faire un tour pour voir de quoi il retourne et ce qu'apportent ces langages. Ca peut valoir le détour ?

pourquoi bientôt ????
il existe déjà... et on va lancer le second défi. en plus, tu es au courant, je crois bien avoir vu une proposition de ta part pour le premier défi

Et l'expérience prouve qu'en moyenne, les programmes en OCaml sont d'une qualité incomparablement suppérieure à ceux en C. Comment ça c'est parce que les seuls personnes qui utilisent OCaml sont des chercheurs, alors que n'importe qui fait du C ??? Mince, ma mauvaise foi est mise à jour :-p

effectivement certains chercheurs ont un excellent niveau en programmation pratique (même si beaucoup se contentent de la théorie, et de l'algorithmie ), et il faut bien avouer que tout le monde n'a pas le niveau suffisant pour faire quelque chose d'efficace en ocaml ou en haskell... alors que les compilateurs de ses langages sont assez performants (tout est relatif, mais passer d'un langage de très haut niveau a un programme qui n'a pas trop à rougir pas face à C, et qui explose souvent le Java... c'est déjà bien )


bon au passage, ce thread parle de C vs C++, donc ce serait intéressant d'éviter à l'avenir les digressions de ce style... qui seraient en revanche très appréciées dans un sujet approprié

[gorgonite]

les outils de preuve formelles n'ont pas fait leurs preuves Qui les utilisent dans l'industrie (à part l'INRIA) ?

ce ne sera bientôt plus un secret, car le papier devrait être publié, mais il existe désormais des applications industrielles utilisant conjointement un système "à la Coq" conjointement à d'autres techniques d'analyse statiques, et qui obtiennent des résultats assez bons... (indice : ce n'est pas un langage fonctionnel qui utilise cela )

suivre les sorties en R&D durant les deux prochaines années devrait donc contredire ce que tu viens d'avancer (mais pour le savoir déjà, il faut connaître un peu ce milieu )

Et la meilleure manière de ne pas faire de bug est de bien maîtriser son langage et de bien coder...

+1000... il est clair qu'un expert C fera un programme 1000 fois meilleur à tout point de vue si on le compare avec un novice qui tenterait la même chose dans son langage de prédilection. Mais signalons aussi que, si on a le bagage théorique minimum, on deviendra plus facilement expert d'un langage "haut niveau" qu'expert C

[LLB]

j'arrêterais là le débat car ça ne sert pas à grand chose

Jolie prétérition.

Que les pointeurs c'est délicat.. Bref il vous faut quoi ? un truc en platique incassable ??

À choisir entre un château de cartes et du plastique incassable, le plastique me semble mieux, en effet.

Quel intérêt y a-t-il à jouer avec les pointeurs quand des mécanismes moins dangereux et tout aussi efficaces existent ? M'est avis, il vaut mieux limiter le code potentiellement dangereux là où il est indispensable. Prudence est mère de sûreté.

Je ne vois pas en quoi le système de typage ou quoi que ce soit ait à voir avec la qualité ou la sûreté d'un code, à part la qualité et le sérieux du programmeur....

Quand tu fais une erreur dans le code, tu préfères que le compilateur ne dise rien et génère un exécutable qui a une chance sur x de planter, ou tu préfères un message d'erreur, basé sur une analyse statique du programme ? Un système de typage performant est capable de détecter énormément d'erreurs, c'est autant de bugs potentiels en moins. Bien sûr, comme je l'ai dit, ça ne remplacera jamais un bon programmeur. Là dessus, on est d'accord : à la base, il faut un bon programmeur. Mais un programmeur, aussi bon soit-il, peut faire des erreurs. Et on est content dans ce cas que le compilateur soit là pour en détecter certaines.

Ya qu'à voir bêtement avec le français.. T'a beau avoir des correcteurs orthographiques, le nombre (y compris ici-même) de fautes d'orthographes ou de grammaire est insupportable...

Oui, tout le monde en fait, y compris toi dans cette phrase. Je considère que je fais vraiment très peu de fautes quand j'écris. Je sais cependant que je ne suis pas parfait : parfois je tape trop vite, parfois je ne me relis pas, parfois même je doute sur l'orthographe d'un mot. C'est justement parce que je ne suis pas parfait que tous mes messages (y compris sur ce forum) sont vérifiés par un correcteur orthographique. Si j'en avais trouvé, j'utiliserais même un correcteur grammatical. Je ne suis pas parfait et je déteste faire des fautes : un correcteur automatique me semble donc presque indispensable.

Tu as raison, c'est la même chose pour la programmation. Si j'étais un développeur parfait, j'utiliserais peut-être régulièrement le C. Mais ce n'est pas le cas...

En bref, toutes les aides du monde pour faire un code plus sûr ne produiront pas un code plus sûr... Si c'est utilisé par quelqu'un qui s'y fie et ne fait pas attention à ce qu'il fait....

Bien sûr. Comme le correcteur orthographique : ça ne remplace pas la connaissance du français. Mais il faut le reconnaitre : tout le monde peut faire des fautes, et utiliser un correcteur réduit ce nombre de fautes. Parfois, même après de nombreuses relectures, on ne se rend pas compte de la faute. Par exemple, de nombreuses personnes font une faute en écrivant le mot « occurrence ». S'ils utilisaient tous un correcteur orthographique, je suis persuadé que l'on verrait beaucoup moins souvent cette faute.

En C, c'est pareil. Certaines erreurs peuvent passer inaperçues. Par exemple, un buffer overflow.

Ces programmes ne sont pas en C....

On est d'accord :
un programme écrit en C ne plante pas forcément ;
un programme écrit dans un autre langage peut parfois planter.

Tout comme :
on peut écrire un texte sans faute, sans correcteur automatique ;
on peut trouver des fautes dans un texte, malgré une correction automatique.

Toutefois, on ne peut s'empêcher de penser que les proportions s'en trouvent inévitablement modifiées, à compétences égales.

Regarde avec les voitures : on met des GPS, des freins ABS, des aides à la conduite, des détections anti-collisions, etc etc... ça empêche les accidents ?

Si tu penses qu'ajouter des protections entraine directement une augmentation des accidents, je propose de faire l'inverse. Il faut détériorer volontairement les routes, ajouter du gravier, dégrader les voitures, etc. Cela permettrait de réduire le nombre d'accidents. Il faudrait proposer ça à la sécurité routière, tiens.

Je suppose que, précisément pour ces raisons, tu utilises l'option -w (oui, minuscule) de gcc quand tu écris du C. N'est-ce pas ? Il te serait probablement insupportable que le compilateur puisse t'aider, puisque ça t'empêcherait inévitablement de réfléchir par toi-même.


Maintenant quelques questions, puisque tu sembles défendre le C.
Pourquoi n'utilises-tu pas l'assembleur plutôt que le C ? Puisque le débat tourne surtout sur l'aspect bas-niveau contre (plus ou moins) haut-niveau, on pourrait réutiliser tes arguments, pour défendre l'assembleur. Non ?

Ne crois-tu pas que la réduction du nombre de ligne de code, l'augmentation de l'expressivité des langages, de la clarté du code... augmente la productivité tout en simplifiant énormément la maintenance et le débuggage ? C++ n'est pas un langage que j'apprécie énormément (bien que son système de templates soit extrêmement intéressant), mais je le conseillerai toujours par rapport à du C. Il y a un niveau d'abstraction supplémentaire, un système de typage légèrement plus fort (quand on utilise les ajouts de C++).


Tout comme Alex_3.14, je t'invite à participer aux défis qui ont lieu dans le forum fonctionnel. Ces défis sont ouverts à tous les langages et tu n'as même pas besoin de comprendre la notion de programmation fonctionnelle pour participer. Tu pourras te rendre compte directement de la différence entre le C et les langages de plus haut-niveau. Une clarté incomparable, du code 10 (ça dépend des cas, mais la valeur 10 n'est généralement pas exagérée) fois plus court...

[souviron34]

• Euh ouais, fin en même temps, sachant que derière le clique, il y a une requete DNS, l'ouverture d'une connection avec la machine, potentiellement disante de milliers de kilomètre, etc, je ne suis pas totalement persuadé que la microseconde apporté par l'optimisation de derière les fagots en C avec un ptit pointeur de pointeur casté dans je ne sais quoi apporte grand chose par rapport à ma bonne petite fonction en Caml... Les compilos modernes des langages fonctionnels font des miracles.

  Je ne vois vraiment pas en quoi tu penses que l'usage du C est automatiquement "privilégié" afin d'optimiser... mais visiblement c'est ce que tu penses de la raison pour laquelle on utilise le C. On n'a pas parlé d'optimisation jusque-là, en tous cas pas moi, et je ne pense pas que l'on choisisse le C par rapport aux possiblités d'optimisation... Ni en quoi cela a à voir avec "un p'tit pointeur de pointeur casté"... ça c'est du hack ou éventuellement des TAD. Je pense qu'il faut que tu révises tes notions de l'usage du C. Cela n'a rien à voir avec une question d'optimisation..
  
  
  
  

• A vous lire, j'ai quand même l'impression que la dernière fois que vous avez tenté de faire autre chose que du C, c'était il y a 20 ans, vous êtes tombé sur Basic, et vous avez (à fort juste titre...) abandonné. Le monde des langages de programmation a très légèrement évolué depuis, et peut être que "nous les jeunes" (comme vous vous plaisez à nous appeler) avons justement l'avantage de la curriosité de la jeunesse, qui nous a permis de découvrir ces autres langages, de les tester, et d'en comprendre les avantages.

  J'ai dis qu'il n'y avait pas de "racisme anti-jeune" dans mes propos. Juste le fait qu'en ayant 25 ans de recul, j'ai vu des petits et des gros projets, des modes aller et venir, des gens qui disaient "c'est la solution miracle", etc etc.. et si tu regardes la citation dans ma signature, tu comprendras...
  
  Je ne suis ni contre C++, ni contre la curiosité, ni n'importe quoi, je doute, parce que j'ai vu de l'eau couler sous les ponts, et des projets échouer alors qu'ils suivaient "la tendance", et des projets réussir alors qu'ils ont fait le contraire de ce qui était la tendance".. Et par conséquent je suis contre une affirmation du style :
  
  

  S'il s'est largement imposé à la communauté informatique mondiale, ce n'est évidement pas par une suppériorité quelconque sur les autres langages, mais uniquement parce qu'il est d'une exceptionnelle trivialité

  ou
  
  
  

  C'est quand même un langage qui date des années 70. Disons que depuis, la théorie des langages de programmation a fait quelque petit progrès

  ou
  
  

  Donc oui, je conseillerais le C++ qui a quand même l'avantage d'avoir bénéficié de quelques années d'expérience de plus ! Et qui autorise même à programmer proprement (bref, sans pointeur, juste avec des références), et même à faire de l'objet ;-)

  
  
  

• Je ne vois pas en quoi le système de typage ou quoi que ce soit ait à voir avec la qualité ou la sûreté d'un code, à part la qualité et le sérieux du programmeur....

  Peut être parce que vous n'avez jamais vraiment essayer ? On montre mathématiquement une certain nombre de propriété sur l'absence d'erreur d'un programme correctement typer par exemple. Donc ça *a* quelque chose à voir avec la qualité et la sûrté d'un code.

  Il est normal que tu penses cela, mais je parlais de PRATIQUE, comme dit plus haut... Tant mieux si tu penses cela, mais comme je le disais plus haut, une longue pratique m'a amené à VERIFIER que la théorie n'a pas grand chose à voir avec la pratique....
  
  
  
  

• Je suis un bien piètre programmeur, je l'avoue volontier. Néamoins, je n'ai jamais une seule erreur de ségmentation, ou un seul plantage silencieux dans mes programmes. Pourquoi ? Parce que c'est tout simplement impossible dans le langage que j'utilise (sauf à se servir de l'infame module Obj ou Marshall, je vous l'accorde). Et dans 90% des cas, lorsque le code compile (c'est à dire que l'inférence de type réussi), le code est bon et ne nécessite aucun débugage. De plus, les codes sources sont plus court qu'en C, à mes yeux beaucoup plus élégant et logique, et si on compare à temps passé à programmer, les performances du produit fini sont souvent meilleurs que ceux fait en C par d'autres programmeurs d'un niveau équivalent au mien. Parce que ce que vous oubliez peut être, en tant qu'expert informatique, c'est que tout le monde ne l'est pas.

  Donc, avant de donner une opinion sur le choix de tel ou tel langage,on commence par dire "je suis un bien piètre programmeur".... Désolé, mais l'opinion est influée par cela... Quand on cite des statistiques comme "dans 90% des cas", il faut que les lecteurs de ce forum, et de ce thread, sachent 90% de quoi... De 5000 lignes ? de 50 000 ? de 500 000 ? de 5 millions ?
  
  
  
  

• Il y aura bientôt un nouveau "défi" sur le forum "langages fonctionnels". Venez y faire un tour pour voir de quoi il retourne et ce qu'apportent ces langages. Ca peut valoir le détour ?

  Pas de problèmes...
  
  
  
  

• ce ne sera bientôt plus un secret, car le papier devrait être publié, mais il existe désormais des applications industrielles utilisant conjointement un système "à la Coq" conjointement à d'autres techniques d'analyse statiques, et qui obtiennent des résultats assez bons... (indice : ce n'est pas un langage fonctionnel qui utilise cela )
  
  suivre les sorties en R&D durant les deux prochaines années devrait donc contredire ce que tu viens d'avancer (mais pour le savoir déjà, il faut connaître un peu ce milieu )

  C'est bien ce que je disais tu parles de R&D et que c'est "en voie de sortie", pas que c'est "largement utilisé"
  
  D'autre part, cf. le point précédent sur la théorie et la pratique....
  
  
  
  

• Mais signalons aussi que, si on a le bagage théorique minimum, on deviendra plus facilement expert d'un langage "haut niveau" qu'expert C

  Je n'ai jamais eu de formation théorique . 3h d'intro à Fortran ... J'étais chercheur (eh oui moi aussi ) et j'ai appris "sur le tas"... pour faire ce que je voulais...
  
  
  
  

• j'arrêterais là le débat car ça ne sert pas à grand chose

  Jolie prétérition.

  je parlais de ma participation..
  
  
  
  

• Que les pointeurs c'est délicat.. Bref il vous faut quoi ? un truc en platique incassable ??

  À choisir entre un château de cartes et du plastique incassable, le plastique me semble mieux, en effet.
  
  Quel intérêt y a-t-il à jouer avec les pointeurs quand des mécanismes moins dangereux et tout aussi efficaces existent ? M'est avis, il vaut mieux limiter le code potentiellement dangereux là où il est indispensable. Prudence est mère de sûreté.

  
  A ce compte-là, tu es UTILISATEUR, et non pas PROGRAMMEUR....
  
  Dans ce cas, je n'ai aucun problème avec tes affirmations...
  Dans le cas contraire, si...
  
  
  
  

• Maintenant quelques questions, puisque tu sembles défendre le C.
  Pourquoi n'utilises-tu pas l'assembleur plutôt que le C ? Puisque le débat tourne surtout sur l'aspect bas-niveau contre (plus ou moins) haut-niveau, on pourrait réutiliser tes arguments, pour défendre l'assembleur. Non ?

  Comme je le disais, je n'ai JAMAIS appris la théorie... Je ne sais ni compter en binaire, ni en héxa, ni en octal... Donc naturellement je ne vais pas aller vers quelque chose qui nécessite ça. Et pourtant j'ai programmé en assembleur aussi (et là, alex-pi, c'était pour de l'optimisation )..
  
  
  
  

• Ne crois-tu pas que la réduction du nombre de ligne de code, l'augmentation de l'expressivité des langages, de la clarté du code... augmente la productivité tout en simplifiant énormément la maintenance et le débuggage ?

  Sans doute... Mais j'attend la preuve que écrire en C++ améliore la clarté du code et la productivité.... et non une affirmation... Et de ce que j'ai vu en tous cas, pour la lisibilité, tu repasseras...
  
  
  
  

• C++ n'est pas un langage que j'apprécie énormément ....mais je le conseillerai toujours par rapport à du C. Il y a un niveau d'abstraction supplémentaire, un système de typage légèrement plus fort

  Est-ce à dire que tu préfères qu'on enseigne la mécanique quantique en seconde parce que le niveau d'abstraction est plus élévé que celui de la mécanique classique ?
  

En bref, je pense que la question du départ est biaisée... Comme tout débat de ce type, il y a des pour et des contres, il y a des différences suivant l'usage, le domaine, l'expérience, etc etc...

Ce que je conteste est l'affirmation péremptoire d'une supériorité , surtout quand ce qu'on dit "supérieur" se trouve être dans le courant de pensée "actuel"...

[LLB]

je parlais de ma participation..

Oui, c'est ce que je disais. Oh, peu importe ; je trouvais ça amusant, c'est tout.

Je ne suis ni contre C++, ni contre la curiosité, ni n'importe quoi, je doute, parce que j'ai vu de l'eau couler sous les ponts, et des projets échouer alors qu'ils suivaient "la tendance", et des projets réussir alors qu'ils ont fait le contraire de ce qui était la tendance"..

Je suis d'accord. Cependant, il faut reconnaitre que l'on peut réussir même avec de mauvais outils, ou que l'on peut échouer même avec de bons outils.

A ce compte-là, tu es UTILISATEUR, et non pas PROGRAMMEUR....

À vrai dire, je suis les deux. J'utilise un compilateur pour programmer. Et en tant qu'utilisateur, je cherche à utiliser le meilleur outil. Si je dois faire du bas-niveau, manipuler la mémoire, utiliser des pointeurs, voire coder en assembleur (ce que j'ai fait récemment), je n'hésite pas à le faire. Mais quand j'ai le choix des outils et que je n'ai pas de trop de contraintes, j'ai tendance à utiliser les outils qui me permettent la meilleure productivité (en tenant compte bien sûr des performances, de la maintenance, etc.).

Comme je le disais, je n'ai JAMAIS appris la théorie...

D'accord. Ton avis est donc légèrement biaisé : s'il existe un outil meilleur que celui que tu utilises, tu pourrais ne pas l'utiliser par manque de connaissance (ou parce que ce manque de connaissance te rendrait moins performant). Bon, c'est une remarque purement théorique : en l'occurrence, je sais que tu as largement le niveau pour maitriser le C++.

Sans doute... Mais j'attend la preuve que écrire en C++ améliore la clarté du code et la productivité.... et non une affirmation... Et de ce que j'ai vu en tous cas, pour la lisibilité, tu repasseras...

Vraiment ? Tu veux dire que le C est plus lisible que le C++ ? Ou bien qu'ils sont globalement aussi lisibles ?

Dans le premier cas, dis-moi quelle est la fonctionnalité du C que le C++ ne possède pas, et qui améliorerait la lisibilité du code ?
Dans le deuxième cas, n'y a-t-il vraiment aucune fonctionnalité du C++ qui pourrait parfois améliorer cette lisibilité ? Au hasard, dans cette liste : l'objet, les namespaces, les références, les templates (programmation générique et méta-programmation), la surcharge (ok, le C++ en a un peu abusé), STL, Boost et les structures de données (string, list, vector, map...)... N'y a-t-il vraiment rien de bien dans cette liste (s'il y a des fonctionnalités que tu n'aimes pas, rien ne t'oblige à les utiliser) ?

Est-ce à dire que tu préfères qu'on enseigne la mécanique quantique en seconde parce que le niveau d'abstraction est plus élévé que celui de la mécanique classique ?

Non, c'est différent. Le débat ayant un peu dérivé, je réponds surtout à la question « C ou C++ ? » dans le cas général. Pour un débutant, c'est un peu différent et je n'ai pas d'avis arrêté. Ayant appris le C avant le C++, je dirais que ça dépend du débutant, de son niveau, de son âge, de ses motivations et objectifs futurs.

Pour un bon programmeur, je conseille toujours le C++, car il pourra mieux se concentrer sur les tâches métier.

Ce que je conteste est l'affirmation péremptoire d'une supériorité , surtout quand ce qu'on dit "supérieur" se trouve être dans le courant de pensée "actuel"...

OK. Je n'ai pas pour habitude de suivre « le courant de pensée actuel ». J'utilise au quotidien un langage pour lequel je n'ai toujours pas réussi à trouver ne serait-ce que 10 français qui l'utilisent. Je n'ai pas pour habitude d'utiliser des outils en fonction de la mode, mais plus pour leur qualité intrinsèque. Cela dit, quand « le courant de pensée actuel » correspond à mon avis, je ne m'y oppose pas.

[gorgonite]

Dans le deuxième cas, n'y a-t-il vraiment aucune fonctionnalité du C++ qui pourrait parfois améliorer cette lisibilité ? Au hasard, dans cette liste : l'objet, les namespaces, les références, les templates (programmation générique et méta-programmation), la surcharge (ok, le C++ en a un peu abusé), STL, Boost et les structures de données (string, list, vector, map...)... N'y a-t-il vraiment rien de bien dans cette liste (s'il y a des fonctionnalités que tu n'aimes pas, rien ne t'oblige à les utiliser) ?

Je pense qu'en C, avec un peu de discipline de codage, on peut obtenir la même chose, et de façon lisible... par exemple :

• objets -> struct + module gérant cette structure... ce sera plus long à coder, mais ce sera aussi simplement utilisale. en ce qui concerne l'héritage, il suffit de se le faire "à la main"

Code c :

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
typedef struct {
    char* text;
} message;
 
void message_print(message* msg) {
...
}
 
typedef struct {
    char* text;
    unsigned int id;
} message_id;
 
void message_id_print(message_id* msg) {
    message tmp;
    tmp.text = msg.text;
    message_print(&tmp);
}

• namespace -> une bonne séparation des "modules" peut faire l'affaire

• template -> un peu de macro

Code c :

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

1
2
3
4
5
6
#define DECLARE_LIST(ELEMENT)\
typedef struct STRUCT_NODE_ ## ELEMENT {\
    ELEMENT elt;\
    struct STRUCT_NODE_ ## ELEMENT *next;\
} NODE_ ## ELEMENT;\
...

je concède que c'est plus lourd à concevoir... mais une fois les modules créés (ils sont réutilisables dans d'autres projets ), ce n'est pas vraiment plus compliqué à utiliser

[LLB]

Déjà, les templates, c'est plus que des macros. Et avoir un système objet complet sera difficile à avoir en C.

je concède que c'est plus lourd à concevoir...

On parlait justement de la lisibilité. Donc pour le coup, l'équivalent C++ est bien plus lisible que ton code C.

Mais surtout, quel est l'avantage à "recoder" le C++ ?

Je pense surtout qu'avec un peu de discipline de codage (notamment, ne pas utiliser les fonctionnalités de C++ juste parce qu'elles existent), C++ est un bien meilleur choix.

[gorgonite]

On parlait justement de la lisibilité. Donc pour le coup, l'équivalent C++ est bien plus lisible que ton code C.

je dis juste qu'une fois les modules et macros adéquates créées, il est presque aussi simple d'utiliser la version C

par ailleurs, en ce qui concerne le recodage d'une fonctionnalité dans un langage de plus bas niveau, saches que cette discipline est très utile dans de nombreux exemples (et aussi d'un point de vue pédagogique). par exemple, il y a d'excellents transparents fait par Xavier Leroy pour son cours du MPRI à ce sujet... on y voit le codage de fonctionnalités de haut niveau (telles que le CPS) dans un "langage" n'en disposant, cela peut être par exemple très intéressant pour traduire un langage complexe sur une machine virtuelle "bas niveau", mais très performante

[LLB]

Oui, je suis d'accord. Ce genre de code peut être intéressant.

Mais j'ai bien précisé « quand on a le choix ». Je sais très bien qu'on est parfois obligé (pour des raisons de portabilité, de performances, etc.) d'utiliser un langage bas-niveau.

[souviron34]

Bon disons qu'on commence enfin à parler un peu du fond

Vraiment ? Tu veux dire que le C est plus lisible que le C++ ? Ou bien qu'ils sont globalement aussi lisibles ?

Dans le premier cas, dis-moi quelle est la fonctionnalité du C que le C++ ne possède pas, et qui améliorerait la lisibilité du code ?
Dans le deuxième cas, n'y a-t-il vraiment aucune fonctionnalité du C++ qui pourrait parfois améliorer cette lisibilité ? Au hasard, dans cette liste : l'objet, les namespaces, les références, les templates (programmation générique et méta-programmation), la surcharge (ok, le C++ en a un peu abusé), STL, Boost et les structures de données (string, list, vector, map...)... N'y a-t-il vraiment rien de bien dans cette liste (s'il y a des fonctionnalités que tu n'aimes pas, rien ne t'oblige à les utiliser) ?

Je suis d'accord avec gorgonite... Une bonne discipline de programmation rend les choses limpides la plupart du temps, qe ce soit en remplacement des namespaces, des références, des objets, des structures de données... En ce qui concerne STL et Boost, je ne connais pas, mais dès qu'il faut de nouveau ajouter des connaissances à une base déjà établie à priori pour faire quelque chose, j'ai tendance à trouver ça trop compliqué .

Par essence je suis flemmard... Et donc je cherche (comme l'éclair ) la voie d'effort minimum... C'est sans doute ma prédisposition à l'ergonomie

Et je trouve (mais c'est vraisemblement dû à mon expérience) qu'apprendre un nouveau truc pour pouvoir me servir de quelque chose qui à priori était défini est un peu.. lourdingue...

Je suis pour la simplicité.... de codage, d'algorithme, de concepts... Je l'ai dit dans le forum algo, bien qu'ayant fait 23 ans de programmation scientifique, je n'ai jamais dépassé les dérivées secondes et les équations du second degré dans mes progs... Et ça marche...

Or doncques je trouve qu'on ajoute ce que tu appelles "des abstractions", qui en fait sont des concepts (pas intuitifs) qui (à part l'objet) sont à apprendre en plus, et qui me semblent inutiles... En C je dirais qu'il n'y a que 2 notions délicates à apprendre : void et les pointeurs.

Et en ce qui concerne les codes, je vois passer (ici-même) des codes C++ illisibles, et je peux te montrer du code C parfaitement lisible... même faisant des choses compliquées... Et de plus la superposition de C++ avec des interfaces graphiques "par événements" rend les choses encore plus complexes (voir certains débats sur le forum conception par exemple), pour des "débutants" ou pas si débutants que ça, en faisant se mélanger des notions, et justement des concepts non intuitifs....

Donc pour moi la simplicité est dans le C, la complexité dans le C++. Et c'est pareil pour le code... Je reviens à ma maxime favorite : "ce qui se conçoit bien s'énonce clairement"... Et plus je code, plus je veux de la simplicité...

Non, c'est différent. Le débat ayant un peu dérivé, je réponds surtout à la question « C ou C++ ? » dans le cas général. Pour un débutant, c'est un peu différent et je n'ai pas d'avis arrêté. Ayant appris le C avant le C++, je dirais que ça dépend du débutant, de son niveau, de son âge, de ses motivations et objectifs futurs.

Pour un bon programmeur, je conseille toujours le C++, car il pourra mieux se concentrer sur les tâches métier.

c'est bizarre j''aurais eu tendance à dire le contraire

Un débutant qui est perdu dans l'ensemble des tâches à faire, il est plus simple pour lui d'utiliser un langage (voire un IDE ou un RAD) lui simplifiant la tâche, quitte à ne pas disposer de subtilités qui de toutes façons sont inexploitables pour lui, et ne peuvent que générer chez lui confusion et bug... afin de pouvoir se concentrer sur ce qu'il a à coder, c'est à dire les tâches métier...

Au contraire, chez un bon programmeur, à priori il a l'expérience de savoir ce qu'il fait, et d'autre part a souvent besoin de choses subtiles (car étant bon, il optimise et connait des astuces)... Et pour lui l'analyse des tâches métier est beaucoup plus simple, ainsi que la "conception préliminaire", quasi en automatique....

[LLB]

mais dès qu'il faut de nouveau ajouter des connaissances à une base déjà établie à priori pour faire quelque chose, j'ai tendance à trouver ça trop compliqué.

OK. Le problème vient donc de ta base de connaissance. Si les notions de C++ étaient dans ta base de connaissance, tu utiliserais probablement le C++.

Par essence je suis flemmard... Et donc je cherche (comme l'éclair ) la voie d'effort minimum...

Moi aussi ! Et c'est précisément pour cette raison que je n'utilise pas le C.

Mais il y a une différence de taille. J'adore apprendre : de nouveaux concepts, de nouveaux langages, de nouveaux paradigmes... C'est en ayant une meilleure connaissance des possibilités que je peux choisir la solution la plus simple. Dans le défi du forum fonctionnel, on trouve par exemple cette fonction :

Code Haskell :

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

1
2
3
4
sums n = csums n n
    where
      csums 0 _ = [[]]
      csums n m = [x:xs | x <- [1..min n m], xs <- csums (n-x) x ]

Si tu veux faire une version équivalente en C, il te faudra probablement plus de 20 lignes. C'est pour ça que, moi, en tant que flemmard, je préfère Haskell au C. Alors bien sûr, pour écrire ce code, il y a un certain nombre de pré-requis, des choses à connaitre. J'aurais tendance à dire que c'est un investissement. Je suis prêt à apprendre plein de choses si ça me permettra plus tard d'être plus productif.

Et je trouve (mais c'est vraisemblement dû à mon expérience) qu'apprendre un nouveau truc pour pouvoir me servir de quelque chose qui à priori était défini est un peu.. lourdingue...

D'accord. Je comprends beaucoup mieux ton point de vue maintenant.

Je suis pour la simplicité.... de codage, d'algorithme, de concepts...

Simplicité dans le langage, ok. Mais simplicité pour l'algorithmie, je ne suis pas d'accord. Il faut beaucoup plus de lignes de code (et donc de temps) pour écrire un algo en C par rapport à un autre langage. Pire, j'ai souvent vu des gens utiliser un tableau en C, alors qu'utiliser un arbre binaire améliorerait significativement la complexité... ils utilisent le tableau, juste parce que c'est plus simple en C. Je considère qu'un bon langage devrait permettre d'utiliser simplement n'importe quelle structure de données. Le C++ propose pas mal de types de données par l'intermédiaire de la STL.

Or doncques je trouve qu'on ajoute ce que tu appelles "des abstractions", qui en fait sont des concepts (pas intuitifs) qui (à part l'objet) sont à apprendre en plus, et qui me semblent inutiles...

Ça apporte beaucoup en termes d'expressivité. Quand j'utilise un langage de haut-niveau, je peux m'exprimer simplement. Je peux m'exprimer comme en maths : soit l, la liste des couples (x, y), pour tout x compris entre 1 et 10 et tout y compris entre 1 et x. Cette phrase là se traduit très simplement en Haskell, Python ou F#, ça fait une petite ligne. En C.... hé bien, c'est long à écrire.

En C++, c'est un peu mieux : les notions de listes et de couples sont dans la STL.

Et en ce qui concerne les codes, je vois passer (ici-même) des codes C++ illisibles, et je peux te montrer du code C parfaitement lisible... même faisant des choses compliquées...

Bien sûr, comme on l'a dit plusieurs fois.

Donc pour moi la simplicité est dans le C, la complexité dans le C++. Et c'est pareil pour le code...

La simplicité est dans le C. Oui, d'accord. Mais pour moi, le code C devient alors plus long et complexe. Dès lors qu'un concept n'existe pas nativement en C, tu dois l'écrire par toi-même. Regarde ce que devient l'objet en C. Regarde ce que devient un template en C. Donc oui, le C est plus simple et possède moins de concepts, mais non, le code C n'est pas plus simple que son équivalent dans d'autres langages.

Un débutant qui est perdu dans l'ensemble des tâches à faire, il est plus simple pour lui d'utiliser un langage (voire un IDE ou un RAD) lui simplifiant la tâche, quitte à ne pas disposer de subtilités qui de toutes façons sont inexploitables pour lui, et ne peuvent que générer chez lui confusion et bug... afin de pouvoir se concentrer sur ce qu'il a à coder, c'est à dire les tâches métier...

Certes. Pour le débutant, je n'ai pas d'avis arrêté : ça dépend s'il souhaite faire rapidement quelque chose (-> haut-niveau), ou s'il souhaite apprendre d'abord en profondeur le fonctionnement (-> haut-niveau). Pour moi, on ne peut pas être un bon programmeur C++ si on ne maitrise pas le C. Et il me semble important aussi de bien connaitre le C, même si code en Java, C#, etc. car on comprend alors mieux ce qui se passe.

Au contraire, chez un bon programmeur, à priori il a l'expérience de savoir ce qu'il fait, et d'autre part a souvent besoin de choses subtiles (car étant bon, il optimise et connait des astuces)... Et pour lui l'analyse des tâches métier est beaucoup plus simple, ainsi que la "conception préliminaire", quasi en automatique....

Pour l'optimisation, ok, si on n'a pas confiance en son compilateur (ou si vraiment les performances sont vitales). Mais le gain en productivité est énorme lorsque l'on maitrise un langage de haut-niveau : on tape 5 fois moins de lignes de code, c'est plus simple à relire (à condition de maitriser les concepts utilisés).

Demande à un développeur C++ s'il souhaite faire du C. Il est probable qu'il refuse, puisqu'il aura surtout l'impression de perdre des choses. Le contraire me semble faux : à passer du C au C++, on ne perd (quasiment) rien.

Oui, le C++ est plus compliqué que le C. Mais quand on le maitrise, on gagne vraiment quelque chose.

[alex_pi]

Peut être parce que vous n'avez jamais vraiment essayer ? On montre mathématiquement une certain nombre de propriété sur l'absence d'erreur d'un programme correctement typer par exemple. Donc ça *a* quelque chose à voir avec la qualité et la sûrté d'un code.

Il est normal que tu penses cela, mais je parlais de PRATIQUE, comme dit plus haut... Tant mieux si tu penses cela, mais comme je le disais plus haut, une longue pratique m'a amené à VERIFIER que la théorie n'a pas grand chose à voir avec la pratique....

Quand la théorie ressemble à "on passe 40 fois de temps à débugger dans ce langage que dans un autre", je vous crois fort volontier </petite-pique-gratuite> En revanche, quand la théorie dit (et prouve) "une fois un programme bien type, on supprime définitivement telle et telle catégories d'erreurs à l'execution", je suis beaucoup moins d'accord. Et c'est ce que je voulais montrer en disant "je suis un bien piètre programmeur" (ce qui n'est pas à 100% exact). Je n'ai *jamais* fait "planter" (au sens de erreur de segmentation ou ce genre de joyeuseté) un programme OCaml. Pourquoi ? Parce que c'est impossible, tout simplement...

Je n'ai jamais eu de formation théorique . 3h d'intro à Fortran ... J'étais chercheur (eh oui moi aussi ) et j'ai appris "sur le tas"... pour faire ce que je voulais...

Par essence je suis flemmard... Et donc je cherche (comme l'éclair ) la voie d'effort minimum... C'est sans doute ma prédisposition à l'ergonomie

Peut-être est ce là que ce situe votre erreur ;-) Etre flemmard est une très bonne chose, je ne peux que vous soutenir et vous suivre dans cette voie ! En revanche, un algorithme glouton est loin d'être optimal pour la flemme. (Pour ceux qui ne sauraient pas, un algorithme glouton consiste, à chaque instant, à faire un choix localement optimal, espérant obtenir une solution optimale à la fin.) Apprendre un nouveau langage, de nouveaux concepts, etc, est localement fatigant et prend du temps. Mais le gain qui en ressort vaut (à mes yeux) largement cet effort. La programmation ne se fait que plus simple, plus efficace, les programmes sont plus élégant, plus sûr, plus réutilisable. Prenons l'example de la programmaiton orientée objet. Comprendre la notion de "design patern", en apprendre un certain nombre, en connaitre d'autre (quitte à se référer à l'ouvrage le moment venu), cela prend localement du temps. Mais le gain est considérable ! Au lieu de tenter de réinventer la roue carrée, on profite de l'expérience d'autres programmeurs pour progresser bien plus vite. (Vous avez vu ?? Mon exemple n'était pas "apprendre la programmation fonctionnelle. Je me soigne :-))

A ce compte-là, tu es UTILISATEUR, et non pas PROGRAMMEUR....

Là, je pense qu'un petit lien vaut mieux qu'un long discours :-)

Est-ce à dire que tu préfères qu'on enseigne la mécanique quantique en seconde parce que le niveau d'abstraction est plus élévé que celui de la mécanique classique ?

Je pense qu'il parlait d'abstraction du langage par rapport à la machine. Hors la mécanique quantique est bien plus proche de la "machine" que la mécanique newtonniène :-) En revanche, ne poussons pas plus loin la comparaison, car ces deux mécanique ne sont pas équivalentes, alors que deux langages le sont (du moins au sens de turing)

[Jean-Marc.Bourguet]

Pédagogiquement, je penses qu'on doit commencer par C et apprendre tous ses rudiments même si on dit souvent qu'on peut débuter directement par C++.

Je n'ai jamais vu un pédagogue conseiller cela. Si l'objectif est d'apprendre le C++, il vaut mieux commencer par le C++. Si l'objectif est d'apprendre le C, il vaut mieux commencer par le C. Pour les argumentaires, voir les nombreuses discussions sur ce sujet dans le forum C++.

[J_Lennon]

Je n'ai jamais vu un pédagogue conseiller cela. Si l'objectif est d'apprendre le C++, il vaut mieux commencer par le C++. Si l'objectif est d'apprendre le C, il vaut mieux commencer par le C. Pour les argumentaires, voir les nombreuses discussions sur ce sujet dans le forum C++.

J'ajouterais même que si tu cherches à programmer en C++, débuter par le C, t'aménerait de mauvaises habitudes.

Maintenant C ou C++? c'est une question de philosophie. Mais si le C++ est là aujourd'hui, c'est parce qu'il était nécessaire de mettre à jour le C pour différentes raisons...

Jean-Marc.Bourguet, beaucoup de personne conseil de débuter par le C (à tord), nottament dans certain livre. Dailleur en cours d'informatique, on m'a fait débuter par le C pour apprendre le C++.

Juste un exemple bien célébre qui conseille de débute par le cours de C pour finir par le C++..

[Jean-Marc.Bourguet]

Alors, oui en utilisant bien la STL, on doit pouvoir se passer de tableaux... Mais franchement, je doute qu'en réalité il n'y ai pas de tableaux dans un code C++...

Ca se fait sans problème... c'est même une des raisons qui font que commencer par le C pour apprendre le C++ est une mauvaise idée.

Je serais curieux de comprendre ce que le Java a apporté comme progrès.

Il a popularisé le GC et l'idée d'une vaste bibliothèque. Et populariser est au moins aussi important que d'inventer.

C'est quand même difficile de faire un langage plus simple que le C. Je ne parle pas de simplicité d'utilisation, mais il est simple en terme de fonctionnalités.

C'est facile de définir un langage plus simple que le C. Même de bas niveau.

Parce que, quand on a le choix (i.e. on n'est pas contraint pour des raisons de performances, de portabilité ou de bas-niveau), on utilisera presque systématiquement un autre langage. Au moins C++, au mieux ***** (non, pas de troll ).

D'après mon expérience, le choix d'un langage est rarement fait sur des bases techniques. Au mieux, les raisons techniques sont utilisées pour faire le choix dans une liste déjà bien restreinte sur d'autres critères.

Je me demandais. Y avait il un autre langage avant qui permettait la gestion de programme multithread aussi simplement (je parle notamment du mot clef synchronized) ?

Algol-68, Ada-83, OCCAM -- sans parler des langages de simulation (dont Simula déjà cité) et de ceux que je ne connais pas.

j'arrêterais là le débat car ça ne sert pas à grand chose, mais je n'ai jamais vu planter un système unixoide

Moi si. Et pas uniquement Linux mais aussi Solaris (et pas que les version < 2.5) et AIX.