C ou C++ ? Lequel choisir ?

[kromartien]

Oui si l'envie vous prenait d'être développeur sur le kernel linux, il faut être très bon avec le langage C.

[leternel]

Perso, j'ai appris le C en premier, pour la seule raison que j'ai eu un livre dessus avant le C++.

C'est ainsi que j'ai appris successivement: html et javascript, basic (pour calculatrice TI), "algoritmique", C, "assembleur" (beurk), php et mysql, actionscript (pour flash), c++, java, et quelques bricoles.

A mon avis, si le langage à apprendre dépend de ton besoin.
Est-ce manipuler des données compliquées, mais liées entre elles? POO avec C++, java ou d'autres.
Au contraire, il s'agit de développer des "raisonnements"? langage du type C, basic ou javascript.

Enfin, si apprendre un peu l'HTML ne te gène pas, alors commence par le JavaScript, qui apporte un plaisir de programmation (pas d'environnement de développement ou autres débuggeurs ou compileurs...).

[randriano]

Bonjour à tous !

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++.
Une fois, le C appris, il faut apprendre le C++ car le C reste plus ou moins obsolète, seul les bibliothèques comme GTK et SDL le font vivre ainsi que l'EDI TurboC qui est très facile de prise en main.

Un autre conseil, je vous conseille de commencer par les EDI comme Visual C++ et Code::Blocks pour programmer en C++ avant d'entamer les RAD comme C++ Builder !

Bonne continuation à tous dans C++ ! (évidemment en C aussi)
__________________________________________________________________
Si vous maîtrisez les bases du C++, attaquez l'utilisation de bibliothèques de classes comme Qt: http://randriano.developpez.com/article/trolltech

[Woufeil]

Envoyé par randriano

Une fois, le C appris, il faut apprendre le C++ car le C reste plus ou moins obsolète, seul les bibliothèques comme GTK et SDL le font vivre ainsi que l'EDI TurboC qui est très facile de prise en main.

Mais qu'est ce que vous avez tous à penser que le C est obsolète / va disparaitre ? Il reste l'un des langages de programmation les plus utilisés et il a vraiment de beaux jours devant lui : tous les OS les plus utilisés sont codés avec : les Windows et les Unixoides (donc UNIX, Linux, BSD et MacOS) ! Ne serais-ce que pour les applications mathématiques, il reste le langage roi avec le Fortran...

[kromartien]

Je crois qu'il faut distinguer les facilités de chacun de ces langages. Le C++ est pratique pour concevoir des architectures logicielles de façon simple et efficace, le C est plus performant pour des applications spécifiques, car plus bas niveau. Le C est répandu, comme c'est le langage de programmation des OS, il est réellement portable, qui plus est utilisé sur beaucoup de systèmes embarqués, langage de programmation des kernels. Il est également très intéressant à étudier, car il permet de faire le lien direct avec la machine, contrairement au C++ qui rajoute déjà pas mal d'abstractions supplémentaires.

En définitive, le C pour moi est rapide, mais lourd à programmer. Pour résumer, la problématique finale est toujours la même : facilité d'utilisation, spécificité VS performances.

À mon avis le C est _le_ langage universel, le compromis parfait entre expressivité algorithmique et langage bas niveau. Du fait de la relative simplicité de son fonctionnement, les compilateurs sont performants et donc permettent d'accroître la portabilité du code. Voilà mon avis sur le C.

Pour le C++ , j'ai commencé à l'étudier, mais il est vrai qu'il rajoute beaucoup d'abstractions, dont l'intérêt et l'utilité ne sont pas forcément évidents si on n'a pas déjà rencontré les problématiques habituelles du C.

Je crois donc que randriano a raison à propos de l'intérêt pédagogique du C est incommensurable, notamment par le vaste champ d'application de ce langage. Cependant l'intérêt pédagogique du C++, avec l'implémentation orientée objet qu'il comporte, est indéniable. De toutes les manières se limiter à un seul langage de programmation pour un développeur n'est certainement pas une bonne façon de l'aborder. Néanmoins, il faut faire les choses pas à pas, et pour cela, je crois, on a tout intérêt à commencer par travailler un peu avec le C.

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à :-)

[arnaud036]

Moi je pense que connaitre le C est plus important que le C++, car si tu ve toucher a ton OS (Linux), tu devras connaitre le C.

[souviron34]

Envoyé par alex_pi

....
En effet, le C n'est pas un langage de programmation, c'est un assembleur multiprocesseur.

Et c'est quoi ?

Envoyé par alex_pi

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é

Alors là je meurs de rire....

Si il était d'une exceptionnelle trivialité, vous tous vous l'utiliseriez dès votre enfance, et à l'école, et à la fac... C'est justement parce qu'il ne l'est pas que vous utilisez des trucs qui font tout pour vous , qui vous empêche de faire des erreurs, qui gère la mémoire à votre place, etc etc... C'est justement parce que vous ne voulez pas vous fatiguer que vous utilisez des trucs plus simples...

Envoyé par alex_pi

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.

Ben voyons...

Et tu es sacrément meilleur que le mec qui a fabriqué ton téléphone portable, c'est bien évident...

[Woufeil]

Alors, tout d'abord, un énorme +1 sur tout ce qu'a dit souviron.

Envoyé par alex_pi

En effet, le C n'est pas un langage de programmation, c'est un assembleur multiprocesseur.

Là j'avoue que je suis comme souviron : comprend pas... Qu'est ce qu'il manquerait selon toi pour que le C soit un langage de programmation ? J'avoue que ça m'échappe : variables nommées et typées, structures de contrôles plus évoluées qu'un bon vieux label/goto, une bonne partie de la mémoire gérée automatiquement (tant que l'allocation n'est pas dynamique, c'est quand même le compilo qui prend tout en charge...)...
J'en viens à me demander si tu sais vraiment ce que c'est que l'assembleur au final.

Envoyé par alex_pi

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

C'est quoi cette légende urbaine ? Allez, petite révision des notions de base. En C++ comme en C :

Code C++ :

1
2
tab[i] <=> *(tab + i)
tab <=> &tab[0]

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

Ensuite; en quoi les pointeurs sont sales ? Je comprend pas cette hantise de ne jamais vouloir avoir à faire avec la mémoire.

Envoyé par alex_pi

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.

Je serais curieux de comprendre ce que le Java a apporté comme progrès. Sincérement, je vois pas. La notion du tout objet (encore que les types de bases ne sont pas des objets en Java), celle de garbage collector et celle de bytecode existaient avant Java.
Attention hein, Java reste pour moi un très bon langage (avec notamment une bibliothèque de classe impressionnante) mais il n'a rien inventé.

[gorgonite]

Envoyé par Woufeil

Je serais curieux de comprendre ce que le Java a apporté comme progrès. Sincérement, je vois pas. La notion du tout objet (encore que les types de bases ne sont pas des objets en Java), celle de garbage collector et celle de bytecode existaient avant Java.
Attention hein, Java reste pour moi un très bon langage (avec notamment une bibliothèque de classe impressionnante) mais il n'a rien inventé.

techniquement aucun :
+ POO... simula l'avait dans les années 70

+ garbage collector... Lisp

Envoyé par wikipedia

Le ramassage des miettes a été inventé par John McCarthy comme faisant partie du premier système Lisp.

+ chargement paresseux... Miranda et Haskell l'avaient avant, et vont même plus loin dans la paresse

+ introspection... SmallTalk faisait déjà plus de ce côté là

+ héritage simple vs héritage multiple... SmallTalk l'avait

+ interfaces multiples + héritage simple... peut-être, mais n'est-ce pas un moyen détourné de faire de l'héritage multiple


enfin, j'oublie peut-être quelques "grandes innovations" de Java

[LLB]

Envoyé par souviron34

Si il était d'une exceptionnelle trivialité, vous tous vous l'utiliseriez dès votre enfance, et à l'école, et à la fac...

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 un langage de bas-niveau, qui n'est pas tellement de plus haut niveau que l'assembleur. Le C est un langage simple parce qu'il n'y a presqu'aucun concept derrière (à part les pointeurs... mais ça vient de l'assembleur).

Envoyé par souviron34

C'est justement parce que vous ne voulez pas vous fatiguer que vous utilisez des trucs plus simples...

Au niveau du compilateur, c'est plus complexe. Dans un langage de haut-niveau, le compilateur a beaucoup plus de travail à faire, du coup.

Je pense que tout le monde est d'accord, c'est juste une question de mots.

Envoyé par Woufeil

C'est quoi cette légende urbaine ? Allez, petite révision des notions de base. En C++ comme en C :

Bien sûr, le C++ repose sur les mêmes bases que le C. Mais les ajouts de C++ font que l'on peut la plupart du temps se passer de l'utilisation *explicite* de pointeurs. On peut utiliser un tableau sans même savoir comment fonctionnent les pointeurs.

Envoyé par Woufeil

Ensuite; en quoi les pointeurs sont sales ? Je comprend pas cette hantise de ne jamais vouloir avoir à faire avec la mémoire.

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. Quand on utilise un langage de plus haut niveau, ces erreurs sont souvent détectées à la compilation (voire, le langage interdit l'utilisation de ces constructions). En Java, dans .NET et dans beaucoup d'autres langages, on peut être amené à manipuler une valeur null, mais ça reste moins dangereux. Dans les langages fonctionnels, la valeur null n'existe bien souvent pas. Et il n'est pas nécessaire d'être un génie pour se rendre compte que du code Caml, Haskell, etc. est en moyenne beaucoup plus fiable que du code C.

Dans beaucoup de cas, C++ permet d'éviter l'utilisation de pointeurs, ce qui est une très bonne chose.

Envoyé par Woufeil

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

Par rapport à C++ ? Il y en a plus d'un. Par rapport aux langages, en général ? Il n'y en (quasiment ?) pas.

Envoyé par Woufeil

Mais qu'est ce que vous avez tous à penser que le C est obsolète / va disparaitre ?

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

LLB a déjà répondu à quasiment toutes les questions, et d'une façon correspondant parfaitement à mon point de vu, et je l'en remercie :-) J'ajouterai une ou deux choses

Envoyé par Woufeil

Là j'avoue que je suis comme souviron : comprend pas... Qu'est ce qu'il manquerait selon toi pour que le C soit un langage de programmation ?

Bon ok, j'aurais du dire "un assembleur multiplateformes", ça aurait été plus clair. Si langage de programmation signifie "grammaire permettant de faire faire à un ordinateur tout ce qu'est capable de faire une maching de Turring", alors le C est un langage de programmation au même titre que l'assembleur. En revanche, si l'on rajoute dans les exigences que l'on a vis à vis d'un langage de programmation d'apporter une bonne abstraction vis à vis de la machine, et, surtout, d'imposer certaines rstrictions, donnant au programmeur une certaine assurance que le programme fera ce que l'on pense qu'il fera, et plus important encore, une sécurité à l'execution, désolé, mais le C est completement à la ramasse.

En C, le programmeur peut faire ce qu'il veut ! Il fait mumuse avec sa mémoire, cast des types les un dans les autres, s'éclate avec des pointeurs de pointeurs... Effectivement, quand on écrit un système d'exploitation, c'est indispensable. 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. C'est d'y réagir *bien*, et de ne pas crasher sans raison. Mais non, les gens sont habitués à ça... Quand on compare deux logiciels, ont se demande lequel va vachement plus vite que l'autre. Moi j'aimerai qu'on me dise lequel ne plante jamais et ne mem-leak pas. Bref, lequel est écrit dans un langage de haut niveau.

Envoyé par Woufeil

C'est quoi cette légende urbaine ? Allez, petite révision des notions de base. En C++ comme en C :

Code C++ :

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

Je me recite, pour répondre à ça :

Envoyé par alex_pi

Et qui autorise même à programmer proprement (bref, sans pointeur, juste avec des références), et même à faire de l'objet ;-)

Envoyé par Woufeil

Ensuite; en quoi les pointeurs sont sales ? Je comprend pas cette hantise de ne jamais vouloir avoir à faire avec la mémoire.

Parce qu'un pointeur permet de faire tout et n'importe quoi. Il permet de faire des optimisations de derière les fagots (dans 5% des cas), de tout faire crasher (quand on a de la chance), ou juste de faire faire n'importe quoi (quand on en a moins, qu'on dépasse de la fin d'un tabeau et qu'on va modifier la structure du voisin sans s'en rendre compte). Et par rapport à une référence, le gain? Euh...

Envoyé par souviron34

Alors là je meurs de rire....

Si il était d'une exceptionnelle trivialité, vous tous vous l'utiliseriez dès votre enfance, et à l'école, et à la fac... C'est justement parce qu'il ne l'est pas que vous utilisez des trucs qui font tout pour vous , qui vous empêche de faire des erreurs, qui gère la mémoire à votre place, etc etc... C'est justement parce que vous ne voulez pas vous fatiguer que vous utilisez des trucs plus simples...

Je suis heureux d'apporter joie et bonheur autour de moi, mais je ne voudrais quand même pas que tu en meurt :-)
Plus sérieusement, comme l'a là aussi souligné LLB, je parle du langage, pas de son utilisation. Et c'est justement la grande simplicité du langage, le fait qu'il soit très bas niveau, si proche de l'assembleur, qui fait qu'il est complexe a utiliser, très peu pédagogique pour débuter en programmation (le débutant en C prend très rapidement d'extremement mauvaise habitude. Et puisqu'il est obligé de gérer sa mémoire tout seul, et autre joyeuseté, il perd un temps fou vis à vis de ce qu'il veut réellement faire). De même que le langage d'un machine du turin est d'une extreme simplicité ;-) (aller à gauche, aller à droite, rester en place, écrire un caractère, changer d'état, le tout pour chaque symbole lu et chaque état de la machine... On fait difficilement plus simple), et est pourtant notoirement inutilisable.

Et ce n'est pas "parce que je ne veux pas me fatiguer" que j'utiliser OCaml. C'est parce qu'il me permet de faire beaucoup plus vite, beaucoup mieux, beaucoup plus proprement, avec beaucoup moins de débugage beaucoup plus de chose. (Oui, je sais, les deux sont turing complet, donc aucun ne permet de faire plus de chose que l'autre. Mais je me comprends !) Et si plus de gens utilisaient des langages de haut niveau, je perdrais encore moins de temps à récupérer les crashs à droite à gauche.

Envoyé par souviron34

Et tu es sacrément meilleur que le mec qui a fabriqué ton téléphone portable, c'est bien évident...

C'est quoi le rapport avec le fait que la théorie des langages de programmation a fait des progrès depuis 1972 ?

[Mat.M]

Envoyé par LLB

En Java, dans .NET et dans beaucoup d'autres langages, on peut être amené à manipuler une valeur null, mais ça reste moins dangereux. pas de troll ).

Oui tout à fait d'accord mais un objet mal initalisé en VB6,Java ou NET et c'est une belle MessageBox : erreur d'exécution ou Exception machin chose ce qui revient un peu au même.
La seule différence c'est que cela entraine éventuellement moins d'instabilité au niveau de l'OS que une boite du genre "Ce programme va être arrêté..","Unhandled Exception.." ou "Core Dumped"

Envoyé par Alex_pi

Ce que je demande à ces logiciels, ce n'est pas de réagire dans le pouillemme de seconde qui suit une de mes actions. C'est d'y réagir *bien*, et de ne pas crasher sans raison. Mais non, les gens sont habitués à ça...

Ok d'accord mais faut programmer en Java ou en .NET à ce moment-là
Seulement si tu ne fais pas une bonne gestion des exceptions en Java ou en .NET cela n'empêchera pas les boites de messages d'exceptions comme j'en parle dans ma remarque précédente donc c'est un crash tout de même..donc c'est un faux problême
Que ce soit en VB6 , en Java ou en C++ tu auras toujours des plantages..

[LLB]

Envoyé par Mat.M

Oui tout à fait d'accord mais un objet mal initalisé en VB6,Java ou NET et c'est une belle MessageBox : erreur d'exécution ou Exception machin chose ce qui revient un peu au même.

Oui, c'est pour ça que j'ai mis un bémol pour les valeurs null. Certains langages ne l'ont pas et forcent (par la syntaxe) l'initialisation de tous les identifiants. Dans beaucoup de langages fonctionnels, il est impossible d'avoir une valeur mal initialisée.

90% des erreurs à l'exécution que tu as en C, tu ne les aurais pas eues en Caml.

Et une exception, c'est très différent d'une erreur de segmentation. Une exception arrive parce que dans le code, on lui a demandé de le faire. C'est donc quelque chose de plus ou moins prévu (ça dépend des cas). De plus, une exception, ça se rattrape.

Envoyé par Mat.M

Que ce soit en VB6 , en Java ou en C++ tu auras toujours des plantages..

D'une part, les proportions n'ont rien à voir. Et d'autre part, niveau sûreté, on a vu bien mieux que Java et C++. Typiquement, quand je code en Caml ou F#, quand le code compile, je suis la plupart du temps convaincu qu'il va marcher. En C, malgré mes années d'expériences, j'ai toujours un doute et je teste systématiquement. Et comme chacun sait, une batterie de tests ne remplacera jamais un bon système de typage (le contraire non plus, d'ailleurs).


Pour revenir un peu plus sur le sujet, le C++ apporte plus d'abstraction et plus de sûreté par rapport au C. Le C++ se rapproche un peu plus des langages de haut-niveau, les ajouts de C++ rendent son système de typage plus fort. Le nombre d'erreurs à l'exécution sont donc moins nombreuses.

[millie]

Envoyé par gorgonite

techniquement aucun :
+ POO... simula l'avait dans les années 70

+ garbage collector... Lisp


+ chargement paresseux... Miranda et Haskell l'avaient avant, et vont même plus loin dans la paresse

+ introspection... SmallTalk faisait déjà plus de ce côté là

+ héritage simple vs héritage multiple... SmallTalk l'avait

+ interfaces multiples + héritage simple... peut-être, mais n'est-ce pas un moyen détourné de faire de l'héritage multiple


enfin, j'oublie peut-être quelques "grandes innovations" de Java

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

Oui tout à fait d'accord mais un objet mal initalisé en VB6,Java ou NET et c'est une belle MessageBox : erreur d'exécution ou Exception machin chose ce qui revient un peu au même.
La seule différence c'est que cela entraine éventuellement moins d'instabilité au niveau de l'OS que une boite du genre "Ce programme va être arrêté..","Unhandled Exception.." ou "Core Dumped"

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

[souviron34]

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, alors que W$ ça n'arrête pas. En ce qui concerne les applis, c'est du pareil au même, et pour le Web n'en parlons pas (là je ne te suis pas Millie ) : combien de fois n'avez-vous pas re-cliqué sur un lien parce que ça ne marchait pas la première fois où vous avez cliqué ? pareil pour les lancements de progs ou n'importe quoi... Et pourtant d'après ce que je comprend des posts précédents vous dites que c'est plus sûr...

Et j'arrêterais là enfin parce que la gestion de la mémoire, c'est pas "sale", c'est comme la gestion de sa poubelle dans laquelle on met ses pages froissées... Si vous ne vous sentez pas capable de bien gérer ça, je m'étonne, c'est tout...

Et enfin je m'étonne que les arguments soient que "c'est plus sûr".. Que les pointeurs c'est délicat.. Bref il vous faut quoi ? un truc en platique incassable ?? qu'on peut balancer partout sans réfléchir ?

J'ai fait 8 ou 10 grosses applications critiques (vies humaines en jeu) en C, et elles sont opérationnelles, pour certaines depuis plus de 12 ans... Programmer c''est sérieux... Mais pas insurmontable...

[millie]

Envoyé par souviron34

J'ai fait 8 ou 10 grosses applications critiques (vies humaines en jeu) en C, et elles sont opérationnelles, pour certaines depuis plus de 12 ans... Programmer c''est sérieux... Mais pas insurmontable...

J'ai également écrit des applications en C très sécurisé (notamment des applications réseaux). J'ai clairement moins d'expérience que toi dans le domaine.

Moi même, en C++ du moins, il m'arrive rarement d'avoir des problèmes avec les pointeurs ou des problèmes d'erreur de segmentation. Ok, j'écris en général pas trop trop mal (j'espère ).
Mais il peut arriver que l'on retouche de grosse application difficilement testable avec des tests unitaires. Ce serait vraiment con que toute l'application (du genre une application serveur) fasse une erreur de segmentation si il y a une succession de combinaison qui fasse ça.

Je dis juste que si une fonctionnalité bug, l'erreur peut facilement être localisé dans cette fonctionnalité et les personnes l'utilisant peuvent toujours utiliser les autres fonctionnalités. Car si le serveur plante, ça peut vite faire perdre beaucoup d'argent (impossibilité de travailler pour les personnes se servant de l'application...)

[souviron34]

Envoyé par millie

Je dis juste que si une fonctionnalité bug, l'erreur peut facilement être localisé dans cette fonctionnalité et les personnes l'utilisant peuvent toujours utiliser les autres fonctionnalités. Car si le serveur plante, ça peut vite faire perdre beaucoup d'argent (impossibilité de travailler pour les personnes se servant de l'application...)

je suis entièrement d'accord avec toi... Mais ça n'a rien à voir avec le langage utilisé.

Et je réitère : ça m'énerve profondément que chez les "jeunes" (désolé, c'est pas du "racisme anti-jeune", c'est juste d'après l'age des posteurs ) on pose comme argument que c'est mieux par exemple C++ parce qu'on fait moins d'erreurs.......

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

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

[gorgonite]

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, à part la qualité et le sérieux du programmeur....

D'habitude, je suis plutôt d'accord avec toi, mais là permets-moi de te contredire... ou du moins de nuancer ce propos

Un système de typage fort et "vraiment contraignant" est un moyen de détecter des bugs dès la compilation... pour s'en convaincre, on peut observer que ce mécanisme est utilisé dans des outils de preuve formels genre Coq
Mais il faut aussi garder à l'esprit que tous ces gardes-fous ne réussissent pas encore (et y arriveront-ils un jour ? je ne parlerais pas de l'indécidabilité ici...) à prévenir tous les bugs, surtout des idioties comme les divisions par zéro, les dépassements de bornes dans un tableau, etc.

Donc je dirais :
+ oui le compilateur C++ peut découvrir plus de bugs à la compilation
+ mais il ne faut pas oublier que des mécanismes "sales" (d'un point de vue purement théorie des langages, car d'un point de vue pratique, ça évite les fonctions de conversion à tout va...) comme le cast, des tests sur autre choses que des booléens mal utilisés, et l'absence de tests dans des parties critiques (division par zéro, etc) sont souvent l'origine de bien plus de bugs encore...

[souviron34]

enfin une vraie opinion

Envoyé par gorgonite

..Un système de typage fort et "vraiment contraignant" est un moyen de détecter des bugs dès la compilation... pour s'en convaincre, on peut observer que ce mécanisme est utilisé dans des outils de preuve formels genre Coq
..

Ben 2 remarques :

• les outils de preuve formelles n'ont pas fait leurs preuves Qui les utilisent dans l'industrie (à part l'INRIA) ?
  
  
• Et la meilleure manière de ne pas faire de bug est de bien maîtriser son langage et de bien coder...

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

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

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 ? non ça empire (voir la catastrophe du car polonais : on fait confiance aux outils en oubliant que le but est de conduire.. Et que ça repose sur l'humain et sa capacité de décision, de pensée, de voir, d'imaginer, de réagir...)...

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