Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
+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èteEnvoyé par Jean-Marc.Bourguet
(j'ai bien dit tous les services de la machine...)
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.
La qualité du programmeur joue. Mais à qualité égale, le programmeur s'aidant d'outils correct sera plus productif.à part la qualité et le sérieux du programmeur....
Je ne vois pas le rapport.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 ???
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.
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.Je ré-itère que une bonne programmation passe par un bon programmeur...
Là nous sommes d'accord. There is no silver bullet...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....
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 ?
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.
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...
Ca c'est les 10% restant.
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)..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 ?
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.
Personnellement je voudrais savoir si, en termes de performances, il y a une différence notable entre le C et le C++ ?
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ï
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++".
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ï
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é).
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.
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).
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.
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.
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 ».
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.
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.Mais de nos jours, il est plus proche d'un assembleur que d'un langage de haut niveau comme Python ou Ruby.
Sur quoi precisement?Je rejoins donc AlexPi et Jedai.
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).Par contre, le C n'est pas facile à apprendre car justement il est très proche de la machine
Une des choses qui me font me demander avec quoi tu es d'accord.Maintenant... entre C++ et C, je choisi quand même le C sans hésitation.
Perso, je choisi le C++ sans hesitation et je crois bien connaitre les deux.
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)?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 ».
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager