C ou C++ ? Lequel choisir ?

[gorgonite]

Envoyé par Jean-Marc.Bourguet

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

+1... il est assez facile de construire un programme qui, lancé avec un utilisateur sans privilèges root (sans fork & cie) en mode débug, peut faire planter la machine complète
(j'ai bien dit tous les services de la machine... )

[Jean-Marc.Bourguet]

Envoyé par souviron34

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,

Le système de typage permet de s'assurer de l'absence de certaines classes d'erreurs. D'expérience, je passe du temps en C ou en C++ a débugger des problèmes qu'en Ada le compilateur me signale et je passe du temps en Lisp a débugger des problèmes qu'en C ou en C++ le compilateur me signale.

à part la qualité et le sérieux du programmeur....

La qualité du programmeur joue. Mais à qualité égale, le programmeur s'aidant d'outils correct sera plus productif.

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

Je ne vois pas le rapport.

[Jean-Marc.Bourguet]

Envoyé par souviron34

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

La meilleure manière de ne pas faire de bug est de pouvoir se concentrer sur le problème plutôt que sur les particularités du langage. Et le C est un langage où on est forcé de porter attention à un tas de détails qui distraient du problème. En C++ aussi, mais dans une moindre mesure car on peut se bâtir plus facilement ce qu'il faut pour y échapper.

Je ré-itère que une bonne programmation passe par un bon programmeur...

L'alternative n'est pas entre un bon programmeur et un mauvais, c'est entre le même programmeur et deux langages. Un bon programmeur va normalement être bon programmeur dans n'importe quel langage une fois qu'il le maîtrise, et un mauvais de même.

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

Là nous sommes d'accord. There is no silver bullet...

[Jean-Marc.Bourguet]

Envoyé par alex_pi

Néamoins, je n'ai jamais une seule erreur de ségmentation, ou un seul plantage silencieux dans mes programmes.

Et à la place tu t'es payé des comportements silentieusement incorrects... D'après mon expérience, 90% du temps, les problèmes d'accès incorrect à de la mémoire, ce n'est pas parce que la mémoire a été libérée au mauvais moment, c'est parce que le pointeur n'a pas été modifié au moment de la libération comme il l'aurait fallu. Donc dans un GC ou un langage sûr, ça se serait traduit par la non libération de la mémoire et l'accès un objet toujours "valide", mais pas le bon... Le bug est toujours là, les symptomes ont changé. Et un SEGV est un symptome beaucoup plus facile à détecter qu'un résultat incorrect...

Envoyé par Jean-Marc.Bourguet

Et à la place tu t'es payé des comportements silentieusement incorrects... D'après mon expérience, 90% du temps, les problèmes d'accès incorrect à de la mémoire, ce n'est pas parce que la mémoire a été libérée au mauvais moment, c'est parce que le pointeur n'a pas été modifié au moment de la libération comme il l'aurait fallu. Donc dans un GC ou un langage sûr, ça se serait traduit par la non libération de la mémoire et l'accès un objet toujours "valide", mais pas le bon... Le bug est toujours là, les symptomes ont changé. Et un SEGV est un symptome beaucoup plus facile à détecter qu'un résultat incorrect...

Euh, là je ne vous suis pas. Une erreur de segmentation me sembre régulièrement du à un accès hors tableau. Dans ce cas, l'erreur est tout sauf silencieuse puisqu'une exception est lancée, alors qu'elle peut l'être dans le cas du C, si je n'accede pas "suffisement en dehors" de mon tableau. Par exemple que j'ai deux tableau, et que je vais subtilement modifier le suivant. Ca c'est une vraie erreur silencieuse.
Ensuite, je ne comprends vraiment plus. Comment je peux acceder à "un objet toujours valide mais pas le bon" ? Si j'ai toujours une référence sur un objet, il ne sera pas touché par le garbage collector, ce sera donc toujours le bon. Et si je n'ai plus de référence, et bien... Je n'ai plus de référence ! Je ne peux donc pas acceder à un objet, que ce soit "le bon" ou pas. Pourriez vous réexpliquer cette partie ?

[Jean-Marc.Bourguet]

Envoyé par gorgonite

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

Remplace par un peu par beaucoup et nous sommes l'accord. D'ailleurs je fais la même chose en assembleur... L'intérêt d'un langage de programmation est autant dans ce qu'il permet et rend aisé que dans ce qu'il rend difficile ou impossible.

[Jean-Marc.Bourguet]

Envoyé par LLB

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

Ca mérite d'être redis. Idem pour des limitations arbitraires pour éviter d'avoir à gérer dynamiquement de la mémoire. Cet argument a d'ailleurs été un de ceux qui ont fait passer des langages d'assemblage aux langages plus évolués...

[Jean-Marc.Bourguet]

Envoyé par alex_pi

Euh, là je ne vous suis pas. Une erreur de segmentation me sembre régulièrement du à un accès hors tableau.

Ca c'est les 10% restant.

Ensuite, je ne comprends vraiment plus. Comment je peux acceder à "un objet toujours valide mais pas le bon" ? Si j'ai toujours une référence sur un objet, il ne sera pas touché par le garbage collector, ce sera donc toujours le bon. Et si je n'ai plus de référence, et bien... Je n'ai plus de référence ! Je ne peux donc pas acceder à un objet, que ce soit "le bon" ou pas. Pourriez vous réexpliquer cette partie ?

Exemple typique des cas que je rencontre: j'ai une structure de donnée complexe (un graphe par exemple) qui référence un autre (disons un autre graphe). Suite à une action de l'utilisateur, le second graphe est modifié, et un noeud est effacé. A cause d'une erreur de programmation, le premier graphe continue à référencer le noeud -- donc ce pointeur est invalide. Un accès à travers a de forte chance de causer un crash tôt ou tard. Même si ce n'est pas le cas, un outil comme purify a de bonne chance de trouver la cause du comportement bizare détecté (il va me dire que l'accès est invalide et quand la mémoire a été libérée et dans quel contexte)..

Avec un GC, le noeud va continuer à vivre et je ne connais pas d'outil capable de m'indiquer la cause des comportements bizarres que je rencontre.

[muad'dib]

Personnellement je voudrais savoir si, en termes de performances, il y a une différence notable entre le C et le C++ ?

[Luc Hermitte]

non

[Jedai]

Envoyé par Luc Hermitte

non

Je tempèrerais tout de même cela en disant que "pas de différence notable" n'est pas la même chose que "pas de différence du tout" et que bien qu'aujourd'hui la différence soit vraiment négligeable, il n'en a pas toujours été ainsi (autrement dit, préférez un compilateur récent pour faire du C++, encore plus que pour du C).

--
Jedaï

[Jean-Marc.Bourguet]

Envoyé par muad'dib

Personnellement je voudrais savoir si, en termes de performances, il y a une différence notable entre le C et le C++ ?

Si on prend quelque chose écrit dans le sous-ensemble commun du C et du C++, les différences vont être minimes et résultent plus du bug que d'autre chose. Le seul facteur systématique potentiel est les exceptions. Potentiel par ce qu'il va dépendre des ABI choisies et qu'il me semble qu'il y a moyen de choisir celle du C++ pour que la possibilité des exceptions se traduisent uniquement en tables non chargées tant qu'il n'y a pas d'exceptions. Si dans du code C++, les exceptions peuvent aussi empécher des optimisations, je ne pense pas que ce soit le cas dans le sous-ensemble commun du C et du C++.

Si on sort du sous-ensemble commun, il faut savoir ce qu'on compare. On va parfois avoir un désavantage de la manière idiomatique en C++ par rapport à la manière idiomatique en C (fonctions plus courtes, introduction de fonctions quand en C on accéderait simplement à un membre,... et même si en théorie le compilateur devrait être capable de générer le même code, la pratique est souvent différente), parfois la balance penche dans l'autre sens (le C++ va utiliser des templates et permettre de ce fait des optimisations qu'en C on n'aura pas parce que simuler des templates avec des macros...).

En résumé, la réponse à ta question est "généralement non, mais il y a moyen de trouver des cas particuliers où c'est le cas, en faveur comme en défaveur du C++".

[publicStaticVoidMain]

Envoyé par alex_pi

Si vraiment tu es face à un choix totalement binaire C/C++, je conseillerais le C++. En effet, le C n'est pas un langage de programmation, c'est un assembleur multiprocesseur. 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é, et qu'il est donc très facile d'écrire un compilo pour chaque nouvelle architecture. Vu que tout est à la charge du programmeur du logiciel, celui qui écrit le compilo n'a pas particulièrement à réfléchir, et écrire un compilo C sans trop d'optimisation se fait très rapidement. 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.

Beaucoup de gens me répondront "au moins avec le C, tu sais ce que tu fais, tu es proche de la machine, tu gères toi même ta mémoire, etc." Et 95% d'entre eux ne sauront en fait pas dutout ce qu'ils font, ne sauront absolument pas gérer leur mémoire, et produiront donc des programmes sans aucune sureté à l'execution, bourrés de memleak, et finalement pas plus rapide qu'un programme Java, mais qu'ils auront mis 5 fois plus de temps à développer, et 20 fois plus à débugger. L'immense majorité des applications informatiques n'ont absolument pas besoin de ce prétendu gain en performance apporté par le C, surtout que ce gain n'est effectif qu'avec de très bon programmeurs, ce qui est en fait franchement rare. Bref, pour le coeur d'un système d'exploitation, ok, le C, c'est bien (c'est même raisonnablement indispensable). Pour un client mail, franchement, c'est débile.

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

Après, pour rester dans la même catégorie de langage, si tu as plus de choix, je préfère quand même Java. Encore un peu plus de progrès par rapport à l'époque où le C++ a été conçu, une meilleure "intégration globale" je trouve. Et qu'on ne vienne pas me chercher les poux avec les histoires stupides de performance ! Grmbl...

Et pour quitter le domaine des langages impératifs, moi z'aime bien les langages fonctionnels :-D Ou formulé autrement, je suis un afficionados d'OCaml.

Voilà voilà :-)

D'où tu sors ces infos?

[Jedai]

Envoyé par publicStaticVoidMain

D'où tu sors ces infos?

D'une connaissance minimale de l'histoire de l'informatique et des langages cités, d'où veux tu qu'il les sorte sinon !?

Ce que dit alex_pi est entièrement vrai, pas pour dire que C est un mauvais langage (pour sa niche il est excellent), simplement que l'appeler langage de "haut niveau" est une vue de l'esprit et que 95% des gens qui programment en C feraient mieux de se tourner vers un autre langage.

Après, ça n'aide pas tellement à faire son choix entre C et C++, tout dépend de ce qu'on veut faire avec... (de toute façon C++ tel qu'enseigné dans la majorité des cas partage la plupart des défauts du C pour le débutant).

--
Jedaï

[publicStaticVoidMain]

Envoyé par Jedai

D'une connaissance minimale de l'histoire de l'informatique et des langages cités, d'où veux tu qu'il les sorte sinon !?

Ce que dit alex_pi est entièrement vrai, pas pour dire que C est un mauvais langage (pour sa niche il est excellent), simplement que l'appeler langage de "haut niveau" est une vue de l'esprit et que 95% des gens qui programment en C feraient mieux de se tourner vers un autre langage.

Moi je dirais plutot que le C est un assembleur de haut niveau.
Moi j'utilise le C quand je veux faire de la prog systeme ou quand je veux ecrire de petits algos (meme si Caml est le plus adapté).

Envoyé par Jedai

Après, ça n'aide pas tellement à faire son choix entre C et C++, tout dépend de ce qu'on veut faire avec... (de toute façon C++ tel qu'enseigné dans la majorité des cas partage la plupart des défauts du C pour le débutant).

--
Jedaï

La on n'est d'accord !!

Petite expérience perso (si ca peut aider) : Moi j'ai commencé à programmer en faisant du fonctionnel avec Scheme et Caml. Ensuite, j'ai fait du C et j'avoue que le C m'a donné de tres bonnes bases pour comprendre la POO et particulièrment en Java. Ayant gangé de l'xp, j'ai appris d'autres langages par mes propres moyens (C++, Ruby, etc).

Vu mon expérience, moi je conseillerais le C parce que deja c facil à apprendre et la majorité des concepts retrouvés en C se répètent dans d'autres langages.

[LLB]

Envoyé par publicStaticVoidMain

Moi j'utilise le C quand je veux faire de la prog systeme ou quand je veux ecrire de petits algos (meme si Caml est le plus adapté).

Pas pour de l'algo : tous les langages sont mieux que le C pour ça. Pour la prog système, ça se justifie (même si je préfère C++ pour ça, dans la majorité des cas).

Envoyé par publicStaticVoidMain

Ensuite, j'ai fait du C et j'avoue que le C m'a donné de tres bonnes bases pour comprendre la POO et particulièrment en Java.

Pas la POO. Ou alors tu confonds. Le C a pu te donner quelques bases pour apprendre Java, mais ce sont juste les détails syntaxiques, je pense, ainsi que le raisonnement impératif.

Envoyé par publicStaticVoidMain

D'où tu sors ces infos?

Y a-t-il quelque chose dans ce que je raconte qui te semble faux ou mensonger ?

[Jean-Marc.Bourguet]

Envoyé par alex_pi

Y a-t-il quelque chose dans ce que je raconte qui te semble faux ou mensonger ?

Dire que le C n'est pas un langage de programmation mais un assembleur est faux.
Dire que l'unique raison du succes du C est sa facilite d'implementation est aussi faux.

[Garulfo]

Envoyé par Jean-Marc.Bourguet

Dire que le C n'est pas un langage de programmation mais un assembleur est faux.
Dire que l'unique raison du succes du C est sa facilite d'implementation est aussi faux.

Ce n'est certes pas un assembleur a proprement parlé. Mais de nos jours, il est plus proche d'un assembleur que d'un langage de haut niveau comme Python ou Ruby. Le but du C avait pour but de remplacer le B dans le développement de UNIX, ce qu'il a très bien réussi, mais on est toujours extrêmement proche de l'implantation machine.

Ce n'est pas pour dénigrer le C qui est un excellent langage plein de qualité. Bien plus que le C++ a mon goût.

Je rejoins donc AlexPi et Jedai.

Par contre, le C n'est pas facile à apprendre car justement il est très proche de la machine et ce n'est pas culturellement facile de passer du modèle qu'on nous a appris toutes nos vies pour calculer (les maths qui suivent un paradigme fonctionnelle) au C qui mêle des concepts de paradigme fortement distinct (comme l'impératif) mais en plus fait de la gestion de très bas niveau (comme les maudits tableaux qui sont une plaie à enseigner!!!).

Maintenant... entre C++ et C, je choisi quand même le C sans hésitation.

Note sémantique au passage: c'est implantation qu'il faut utiliser ici, et non implémentation qui signifie « passer des concepts à la réalisation ».

[Jean-Marc.Bourguet]

Envoyé par Garulfo

Ce n'est certes pas un assembleur a proprement parlé.

C'est un langage permettant suffisemment de controle pour eviter l'utilisation de l'assembleur dans un certain nombre de cas ou on l'utilisait traditionnellement avant, mais ca ne va pas plus loin.

Mais de nos jours, il est plus proche d'un assembleur que d'un langage de haut niveau comme Python ou Ruby.

C'est quoi un langage de haut niveau? J'arrive plus ou moins a comparer deux langages quant a leur niveau d'abstraction, mais j'ai toujours du mal avec des absolus comme ca.

Je rejoins donc AlexPi et Jedai.

Sur quoi precisement?

Par contre, le C n'est pas facile à apprendre car justement il est très proche de la machine

Mais non. C n'est pas facile a apprendre principalement parce qu'il faut au contraire connaitre tres bien ce qui est specifie et ce qui ne l'est pas; et une bonne partie de ce qui ne l'est pas reste volontairement non specifie pour permettre une portabilite a travers une grande variete d'architectures sans compromettre la performance. Ca plus un certain nombre d'idiosyncraties qui n'ont guere qu'une explication historique. Et les tableaux est clairement pour moi dans cette derniere classe (on y voit clairement une forme intermediaire entre BCPL et un langage type statiquement -- pas mal d'erreurs communements acceptees en ce qui concerne les tableaux du C sont vraies en BCPL).

Maintenant... entre C++ et C, je choisi quand même le C sans hésitation.

Une des choses qui me font me demander avec quoi tu es d'accord.

Perso, je choisi le C++ sans hesitation et je crois bien connaitre les deux.

Note sémantique au passage: c'est implantation qu'il faut utiliser ici, et non implémentation qui signifie « passer des concepts à la réalisation ».

Tu peux m'expliquer la difference (j'avais tendance a considerer ces termes comme synonymes dans un contexte informatique, avec une tendance puriste semblant preferer implanter sans raisons autre que vouloir s'eloigner de l'anglais) -- et me donner des references (les deux usages ressortant du jargon informaticien pour moi; la derniere fois que j'ai chercher dans un dictionnaire generaliste -- juste maintenant et le dictionnaire est le TLF -- implémenter etait inexistant et aucune acception d'implanter n'avait que des acceptions eloignee du domaine)?