Discussion :

[Matt_Houston]

Le C++ présente l'intérêt de remplacer des heures de déboggages, ou d'écriture de test unitaires pour des babioles, par des baffes données par le compilateur. Il va râler bien avant sur nos bêtises.

Je ne sais pas trop à quoi tu fais référence ici. Je fais à la fois du C et du C++ et je n'ai jamais constaté de différences significatives dans le cycle de développement (enfin si, le C++ demande bien plus d'itérations à la conception, mais je mets ça sur le compte de mes compétences moindres dans ce langage).

[Luc Hermitte]

Je fais référence à l'argument avancé par Dan Saks: il profite du typage renforcé pour éliminer des erreurs d’inattention que le compilateur C ne peut pas trouver pour nous. Regarde la première video du fil de discussion pour plus de détails.

[wolinn]

Juste une petite remarque en passant : j'ai l'impression que tout le monde parait trouver normal de se reposer sur le compilateur pour signaler les erreurs.
Il est vrai qu'une compilation ne coûte plus rien, mais en ce qui me concerne, lorsque le compilateur me signale des erreurs, je considère que j'ai mal travaillé, trop vite, peu rigoureusement, je me demande s'il peut rester des erreurs que le compilateur n'a pas vues (ce qui est parfois le cas, c'est pour ça que je vérifie de temps en temps avec un autre compilateur).
C'est un peu comme si on était incapable d'écrire en français sans correcteur orthographique.

[Roadkiller]

Tu n'as jamais touché a un micro-contrôleur et ça se voit !

Oui bien sûr... J'ai fait tourner un robot à deux roues avec un asservissement en X/Y (angle/distance dessous et vitesse par roue dessus) à 10Hz, avec un A* d'un environnement de 3m*2m avec une granularité de l'ordre du centimètre, une représentation vectorielle de l'environnement et une IA pour décider et réaliser différentes actions (avec plusieurs actionneurs, décision et recherche de chemin sous les 500ms) sur un atmega128 (à 16MHz) et je n'ai jamais touché à un micro-contrôleur. Le tout en C++ avec l'utilisation des GPIO, timers et UART.

Après la dépendance vis à vis du compilo et des options de compilations, c'est déjà le cas en C en embarqué... Je ne nie pas le temps d’apprentissage nécessaire mais il y en a un de la même manière lorsque tu apprends le C pour la première fois.
Note : dans le cas du C++ embarqué, je parle uniquement du langage en tant que tel, je ne prends pas en compte la STL qui faudrait encore, de toute manière, en trouver des implémentations viables pour atmega et autres cortex-m.

Et si tu dois sérieusement te synchroniser à l'instruction près avec le cycle d'horloge d'un FPGA, tu oublies le C aussi... (à moins de compiler en -O0). Le C est déjà une abstraction, tu n'as aucune garantie que le code assembleur généré derrière sera bien ce que tu t'imagines que le compilateur sortira.

Bref, pas plus de temps pour faire une réponse complète, je retourne faire voler des Airbus (en C effectivement, décision imposée et gros historique).

Ps : le bout de code d'exemple de nikko34 est un bon début d'utilisation de template en embarqué mais on peut faire bien plus.

[Luc Hermitte]

Juste une petite remarque en passant : j'ai l'impression que tout le monde parait trouver normal de se reposer sur le compilateur pour signaler les erreurs.
Il est vrai qu'une compilation ne coûte plus rien, mais en ce qui me concerne, lorsque le compilateur me signale des erreurs, je considère que j'ai mal travaillé, trop vite, peu rigoureusement, je me demande s'il peut rester des erreurs que le compilateur n'a pas vues (ce qui est parfois le cas, c'est pour ça que je vérifie de temps en temps avec un autre compilateur).
C'est un peu comme si on était incapable d'écrire en français sans correcteur orthographique.

Intéressant. Ta remarque me parait être exactement dans la continuité de ce que raconte Dan Saks sur les cadres de pensée.

Je sais que je travaille mal et produit quantité d'erreurs d'inattention, et je suis persuadé de ne pas être le seul. Par contre, je ne m'en formalise pas -- peut-être parce que depuis longtemps je sais que j'ai besoin de relire 150 fois ce que j'écris en français et que de fait, aujourd'hui, j'utilise systématiquement le correcteur orthographique histoire de pouvoir me concentrer sur des choses plus intéressantes que des erreurs de typo.

En développement, c'est pareil. Je suis par exemple fâché avec l'appel à return pour renvoyer la dernière variable que j'ai calculée. Depuis, j'ai découvert une option de compilation pour me rappeler à l'ordre, et j'en abuse. On n'est pas toujours concentrés sur les petits détails. On va à la place penser à comment définir un traitement complexe avec trop de cas particuliers, à gagner des cycles ici et là, etc, et pas forcément au pointeur qui pourrait ou pas être légitimement nul en entrée de fonction. Ou encore, on ne sera pas forcément assez concentré pour remplacer tous les x par des y après un copier-coller.

Bref, tout ça pour dire que si je peux remplacer une erreur trouvable en débug, si on a de la chance, par une erreur de compilation, je prends!

[CaptainDangeax]

Juste une petite remarque en passant : j'ai l'impression que tout le monde parait trouver normal de se reposer sur le compilateur pour signaler les erreurs.
Il est vrai qu'une compilation ne coûte plus rien, mais en ce qui me concerne, lorsque le compilateur me signale des erreurs, je considère que j'ai mal travaillé, trop vite, peu rigoureusement, je me demande s'il peut rester des erreurs que le compilateur n'a pas vues (ce qui est parfois le cas, c'est pour ça que je vérifie de temps en temps avec un autre compilateur).
C'est un peu comme si on était incapable d'écrire en français sans correcteur orthographique.

+1, Tout-à-fait d'accord avec ton approche. Que se soit en C ou en ASM, en bash ou en python, si j'ai des erreurs à la compilation, à l'assemblage ou au lancement, c'est que j'ai mal travaillé et je remets mon ouvrage sur le métier.
Autrement, le sujet du memcopy a été abordé. En ASM, il y a des optimisations possibles, comme le faire en décrémentant pour utiliser DJNZ (decrement and jump if not zero) et gagner une comparaison, ou le faire en parallèle ( 2 ou plusieurs copies par bouclage)... Des gourous du C ou du C++ sont-ils allé voir le code ASM généré par leurs compilateurs ?

[Vincent PETIT]

Oui bien sûr... J'ai fait tourner un robot à deux roues avec un asservissement en X/Y (angle/distance dessous et vitesse par roue dessus) à 10Hz, avec un A* d'un environnement de 3m*2m avec une granularité de l'ordre du centimètre, une représentation vectorielle de l'environnement et une IA pour décider et réaliser différentes actions (avec plusieurs actionneurs, décision et recherche de chemin sous les 500ms) sur un atmega128 (à 16MHz) et je n'ai jamais touché à un micro-contrôleur. Le tout en C++ avec l'utilisation des GPIO, timers et UART.

Je peux voir ton programme ?

ps : Je ne cherche pas la petite bête et lorsque je me trompe, je suis le premier à le reconnaître, cependant je demande a voir une preuve indéniable que le C++ est plus performant que le C surtout sur une cible comme un ATMEGA128.

[Matt_Houston]

Je fais référence à l'argument avancé par Dan Saks: il profite du typage renforcé pour éliminer des erreurs d’inattention que le compilateur C ne peut pas trouver pour nous. Regarde la première video du fil de discussion pour plus de détails.

Tu as un timestamp ?

Les erreurs d'inattention que le compilateur C, puis valgrind, ne prennent pas en charge, il y en a tout de même très peu de nos jours. Le reste, j'aurais tendance à penser que c'est effectivement la faute à un manque de rigueur de la part de l'auteur du programme.

[Luc Hermitte]

@CaptainDangeax, @wolinn, ça fait longtemps que vous développez ?

Mon intuition me souffle que c'est un état d'esprit propre à la jeunesse (avec mes 20ans d'expérience et plus -- je redécouvre sans cesse les joies de la compilation), vu que l'on tend à devenir plus pragmatiques et à accepter plus facilement les erreurs pour les avoir expérimentées à un moment ou un autre. Mais, je suis loin d'en être sûr. Est-ce une attitude juste humaine? Ou peut-être une conséquence de vos secteurs d'activité?

(En tout cas, c'est intéressant de voir que l'on peut avoir des visions très différentes -- et qui vont ensuite influencer nos goûts, nos choix, jusqu'à notre façon de travailler.)

Ce qui me fait penser qu'à l'opposé de vous, quand j'ai un truc un peut complexe qui compile du premier coup, je suis très sceptique et tends à me dire: "où s'est cachée l'erreur". (Ca c'est un sondage qui pourrait être intéressant)

Tu as un timestamp ?

Les erreurs d'inattention que le compilateur C, puis valgrind, ne prennent pas en charge, il y en a tout de même très peu de nos jours. Le reste, j'aurais tendance à penser que c'est effectivement la faute à un manque de rigueur de la part de l'auteur du programme.

Si mes souvenirs sont bons, cela redevient plus technique (et moins dans le cognitif) dans les 40-45 minutes. J'ai des exemples du même acabit dans la video de Bartosz (son avant dernier exemple je crois). On retrouve tous les types à la non_null qui fleurissent en C++ suite au CppCoreGuidelines ; types qui au fond ne sont que la transposition des types opaques de l'Ada. Il y a eu de la pub sur reddit pour un article sur ce sujet, bien que je trouve les exemples mal présentés: https://foonathan.github.io/blog/201...ing-types.html.

Typiquement, en C++ on peut écrire sans sur-coût sur les assembleurs générés par rapport au C:

Code :

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
19
20
21
22
23
24
25
26
27
typedef TrucQuiVaBien<double> strictly_positive_number;
double f(double x, strictly_positive_number y) {
   // pas besoin de tester si y est != 0, ou positif
   return x / sqrt(y);
}
 
...
double x = 42, y = entree_utilisateur();
// code qui ne compilera pas
// -> MERCI le compilateur! C'est ce que l'on veut.
f(x,y);
 
// code où le développeur fait exprès d'ignorer l'erreur du compilateur
// mais sans la corriger => il mérite des baffes!
f(x, strictly_positive_number(y));
 
// code où le développeur fait son boulot:
if (y <= 0) erreur....
else {
   f(x, strictly_positive_number(y));
}
 
// Et bien sûr si on a un g qui prend un strictly_positive_number, ou qui sait en fabriquer un,
// => on peut enchainer directement sans tests ; 
// pareil avec des boucles, on ne teste pas dans f(), mais à l'extérieur, donc il y a moyen de virer tous les tests.
auto z = strictly_positive_number{ sqrt(1+abs(sin(y))) }; 
f(x,z);

Et avec ça on est conforme à la règle MISRA-C pour intercepter les divisions par zéros.
Après, je ne dis pas que cela ne soit pas un peu lourd à mettre à place. Des outils de preuve formelle pourraient être plus doués.

Le degré 0 de la technique, c'est l'emploi de références en place des pointeurs.


Après, oui valgrind (et autres sanitizers) peuvent intercepter beaucoup d'erreurs, mais si on peut les attraper avant (à la compilation), c'est encore mieux. On n'est alors pas dépendant d'un test qui pourrait ne pas couvrir des cas buggués qu'un compilateur aurait pu intercepter.

[wolinn]

@CaptainDangeax, @wolinn, ça fait longtemps que vous développez ?

Mon intuition me souffle que c'est un état d'esprit propre à la jeunesse (avec mes 20ans d'expérience et plus -- je redécouvre sans cesse les joies de la compilation), vu que l'on tend à devenir plus pragmatiques et à accepter plus facilement les erreurs pour les avoir expérimentées à un moment ou un autre. Mais, je suis loin d'en être sûr. Est-ce une attitude juste humaine? Ou peut-être une conséquence de vos secteurs d'activité?

(En tout cas, c'est intéressant de voir que l'on peut avoir des visions très différentes -- et qui vont ensuite influencer nos goûts, nos choix, jusqu'à notre façon de travailler.)

Ce qui me fait penser qu'à l'opposé de vous, quand j'ai un truc un peut complexe qui compile du premier coup, je suis très sceptique et tends à me dire: "où s'est cachée l'erreur". (Ca c'est un sondage qui pourrait être intéressant)

Ca fait 25 ans que je développe en C++...
Pour ce qui est de l'orthographe, je trouve horrible d'avoir besoin d'un correcteur orthographique pour écrire dans sa langue maternelle. En ce qui me concerne, j'écris quasiment sans faute du premier jet, sans y penser ni perdre de temps sur les détails justement, avec juste une ou deux relectures pour traquer des fautes résiduelles. Et ça me parait normal quand on s'exprime dans sa langue maternelle.
J'aimerais avoir ce niveau en programmation (en fait le retrouver), et je fais toujours des efforts pour y arriver, c'est à dire écrire naturellement sans erreur.
C'est un peu dur de se forcer à bien relire avant de compiler "juste pour voir", mais ça permet aussi au passage de détecter des vraies erreurs de logique que le compilateur ne peut pas voir.
Je pense que les programmeurs, moi compris, ont bien perdu en rigueur avec les langages de haut niveau et la compilation quasiment instantanée.
En fait, je faisais plus attention à l'époque où les compilations étaient coûteuses et les outils de débuggage plus rudimentaires, et j'essaye maintenant de corriger ces mauvaises habitudes prises au fil du temps.

[Iradrille]

Autrement, le sujet du memcopy a été abordé. En ASM, il y a des optimisations possibles, comme le faire en décrémentant pour utiliser DJNZ (decrement and jump if not zero) et gagner une comparaison, ou le faire en parallèle ( 2 ou plusieurs copies par bouclage)... Des gourous du C ou du C++ sont-ils allé voir le code ASM généré par leurs compilateurs ?

Petit test rapide :

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
#include <iostream>
 
int main(int, char**) {
	unsigned const size = 1000000;
 
	double *a = new double[size]; // yep ça ressemble plus à du C qu'autre chose :)
	double *b = new double[size];
 
	for (unsigned i = 0; i < size; ++i) {
		a[i] = (double)i;
	}
 
	memcpy(b, a, size * sizeof(double));
 
	std::cout << b[42]; // empêcher la suppression du memcpy par optimisation
 
	return 0;
}

Code asm :

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
19
20
21
;	memcpy(b, a, size * sizeof(double));
00007FF6632F1050  lea         rax,[rax+80h]  
00007FF6632F1057  movups      xmm0,xmmword ptr [rbx]  
00007FF6632F105A  lea         rbx,[rbx+80h]  
00007FF6632F1061  movups      xmmword ptr [rax-80h],xmm0  
00007FF6632F1065  movups      xmm1,xmmword ptr [rbx-70h]  
00007FF6632F1069  movups      xmmword ptr [rax-70h],xmm1  
00007FF6632F106D  movups      xmm0,xmmword ptr [rbx-60h]  
00007FF6632F1071  movups      xmmword ptr [rax-60h],xmm0  
00007FF6632F1075  movups      xmm1,xmmword ptr [rbx-50h]  
00007FF6632F1079  movups      xmmword ptr [rax-50h],xmm1  
00007FF6632F107D  movups      xmm0,xmmword ptr [rbx-40h]  
00007FF6632F1081  movups      xmmword ptr [rax-40h],xmm0  
00007FF6632F1085  movups      xmm1,xmmword ptr [rbx-30h]  
00007FF6632F1089  movups      xmmword ptr [rax-30h],xmm1  
00007FF6632F108D  movups      xmm0,xmmword ptr [rbx-20h]  
00007FF6632F1091  movups      xmmword ptr [rax-20h],xmm0  
00007FF6632F1095  movups      xmm1,xmmword ptr [rbx-10h]  
00007FF6632F1099  movups      xmmword ptr [rax-10h],xmm1  
00007FF6632F109D  sub         rcx,1  
00007FF6632F10A1  jne         main+50h (07FF6632F1050h)

L'appel est inline, la boucle de copie à été déroulée / vectorisé correctement (128 octets copiés par itération), il n'y a pas de test inutile pour vérifier que les tableaux aient une taille multiple de 128 octets.
Il y a aussi 2 boucles "mélangées" travaillant sur deux registres différents pour faciliter la parallélisation de ces instructions par le CPU.
Il manque cependant l'optimisation sur la décrémentation / saut conditionnel; mais ya pas grand chose à redire du binaire généré.

De manière général les compilos font un bon boulot, il reste toujours possible d'aller trifouiller le code si besoin (que ce soit en C ou C++).

edit :

C'est un peu dur de se forcer à bien relire avant de compiler "juste pour voir", mais ça permet aussi au passage de détecter des vraies erreurs de logique que le compilateur ne peut pas voir.
Je pense que les programmeurs, moi compris, ont bien perdu en rigueur avec les langages de haut niveau et la compilation quasiment instantanée.
En fait, je faisais plus attention à l'époque où les compilations étaient coûteuses et les outils de débuggage plus rudimentaires, et j'essaye maintenant de corriger ces mauvaises habitudes prises au fil du temps.

Je vois ça un peu comme une perte de temps : si j’oublie un ";", le compilo le verra avant moi. Quand tout est si simple, pourquoi s'embêter ? (Mais effectivement, on perd en rigueur :/)
Pour les fautes de logique, c'est un peu pareil : un débogueur aide tellement que ça me semble être une perte de temps de relire x fois son code pour s'assurer que tout sera parfait lors de la première exécution.

[foetus]

Je vois ça un peu comme une perte de temps : si j’oublie un ";", le compilo le verra avant moi. Quand tout est si simple, pourquoi s'embêter ? (Mais effectivement, on perd en rigueur :/)
Pour les fautes de logique, c'est un peu pareil : un débogueur aide tellement que ça me semble être une perte de temps de relire x fois son code pour s'assurer que tout sera parfait lors de la première exécution.

À vous lire, j'ai l'impression qu'on peut te faire la même réflexion : coder en C++ embarqué c'est un peu comme une perte de temps : parce que si à chaque fois il faut s'assurer que les "templates"/ "exceptions"/ capsules RAII/ ... fonctionnent et ne créent pas d'"overhead", bien il vaut mieux coder en C dont on est presque sûr de ce qu'il fait. Même si rien n'empêche de faire les mêmes vérifications en C.

[Luc Hermitte]

Il n'y a pas grand chose à s'assurer à chaque fois. Juste quelques tests à faire de temps en temps et un certain nombre de choses qui sont déjà connues:

- Si les capsules RAII provoquent des overheads, cela veut dire que le code en comparaison ne réalise aucune libération (je ne parle seulement de mémoire, mais de sockets, fichiers, locks, port, ...). Est-il bon? J'en doute. Et s'il n'y a rien à libérer, ben ... il n'y pas besoin de ces capsules.

- Pour les templates, entre un algo standard et une boucle faite à la main, il n'y a aucune différence si la boucle à la main est bien écrite. Voire, l'algo standard pourra être automatiquement remplacé en une des fonctions mem*(). Pour des conteneurs standards, il y a des techniques pour factoriser le code des fonctions les plus lourdes quand vraiment c'est intolérable.

- Pour les exceptions, il y a un overhead en taille de binaire, et un titanesque lors du déclenchement d'une exception. Ca, c'est connu. Par contre, là où il y a doute, et une absence de mesures sérieuses, c'est dans le cas nominal. J'ai posté une vidéo sur le sujet il y a quelques messages si mes souvenirs sont bons. Le truc est qu'un code correct en C devrait avoir un if toutes les 2 lignes pour remonter les cas de situations anormales. Cela implique branchements (avec prédictions plus ou moins heureuses), et moins de code nominal dans la mémoire cache pour le code. Avec les exceptions, le seul branchement qui reste, c'est celui du test qui va détecter le soucis (p.ex. message sur la socket ou le port série mal formaté). Ce qui veut dire que le cache pour le code ne contient que le code du chemin nominal -- ou pourquoi déclencher une exception coute un bras : il faut charger au dernier moment le code du traitement exceptionnel)

[Riwalenn]

Je trouve la courbe effrayante, je pensais que le C++ se bataillerait avec le C mais quenini . En BTS SIO on apprend le C++, quel intérêt si derrière les entreprises sont encore au C et refuse de passer en C++ ? Dans l'intention de l'imposer ? On impose rien à une entreprise surtout quand on est au bas de l'échelle.

[Traroth2]

(Disclaimer : je n'ai fait quasiment que du C et du C++ pendant mes études, mais ça date d'une époque où C++ ne gérait pas encore les exceptions. Et je n'en ai plus fait depuis ou presque et je n'ai suivi l'évolution des langages que de loin)

Je n'ai pas l'impression qu'on utilise le C et le C++ pour les mêmes choses. Le C reste indétrônable quand il s'agit de développer quelque chose de proche de la machine, pour l'embarqué, par exemple (mais pas que). Le C++, lui, n'est pas indétrônable du tout et les 15 dernières n'ont cessé de voir son champ d'application se réduire, en fait. Jusqu'à nos jours, où Rust et Go entament largement ce qui reste comme domaine de compétence pour C++. Mais le vrai problème de C++, aujourd'hui comme hier, c'est sur la manière exacte d'utiliser C++ que ça pèche. J'ai l'impression que la plupart des gens ont renoncé à utiliser C++ comme un langage objet (Comme disait Bertrand Meyer : "Quand nous avons imaginé les principes objet, nous ne pensions certainement pas à C++"), ce qui en fait une espèce de super-C aux fonctionnalités bizarres, mélange de haut niveau et de bas niveau, c'est à dire du haut niveau sans sécurité, permettant tous les hacks barbares. Ce qui ne fait pas de C++ un mauvais langage (pouvoir TOUJOURS trouver une solution peut être une bonne chose), mais simplement un langage à ne pas forcément mettre entre toutes les mains...

Ca peut paraitre de la provocation de dire ça sur un forum C++, mais l'article était en page principale. En tout cas, l'idée qu'il faille nécessairement migrer vers C++ si on fait du C me parait absurde.

[foetus]

ce qui en fait une espèce de super-C aux fonctionnalités bizarres, mélange de haut niveau et de bas niveau

Justement tu te trompes Depuis le C++11, le C++ n'est plus du C (même si la compatibilité est assurée). Le métaprogrammation a pris le dessus.
Et c'est d'ailleurs pour cela que le C++ peut-être utilisé en embarqué: avec les "traits", SFINAE, et autres, le compilateur fait plein de tests et optimise le code "à ta place"

Regarde le code nikko34: c'est une orgie de "templates"

[rt15]

Je trouve la courbe effrayante, je pensais que le C++ se bataillerait avec le C mais quenini . En BTS SIO on apprend le C++, quel intérêt si derrière les entreprises sont encore au C et refuse de passer en C++ ? Dans l'intention de l'imposer ? On impose rien à une entreprise surtout quand on est au bas de l'échelle.

La courbe est valable pour les systèmes embarqués. D'une manière générale l'écart est beaucoup moindre.


Pour moi le gros problème du C++ est sa complexité (Qui est aussi sa principale force).
Complexité qui provient de sa polyvalence record et de son historique (Et donc entre autre de sa compatibilité avec le C).
D'accord on peut arriver à du code très simple avec le RAII et C++11, du code beaucoup plus court que le code C équivalent.
Mais bien souvent on arrive plutôt à des kilomètres de code et des modélisation peu banales, des erreurs de compilations illisibles et un débogage choquant.
Parmi les langages courants c'est le plus dur à "apprendre".
La création d'un compilateur C++ est monumentale par rapport à la création d'un compilateur C.
Le temps de compilation s'en ressent aussi.
L'ABI en C++ on va même pas en parler pendant que le C++ tout compilo, le .NET, le VB6, le Delphi et j'en passe attaquent des librairies dynamiques avec une interface "C" depuis des lustres.
Une bonne partie du code C++ écrit fin des années 90 début des années 2000 peut souvent aujourd'hui être considéré comme obsolète avec le C++ moderne. Il ne serait pas écrit de la même manière aujourd'hui. Le C n'a pas du tout la même philosophie et me semble beaucoup plus pérenne. Quoique plus vieux il vieillit moins vite. Il me paraît donc beaucoup plus réutilisable.

Bref le C est simple, performant et paradoxalement de mon point de vue mieux préparé pour l'avenir que le C++ pourtant moderne et qui évolue.
Il me semble moins en concurrence avec le C# et le Java que ne l'est le C++.

[Tagashy]

Enorme blague il fait l'ecole des clown le présentateur ^^
Rien que regarder la différence entre un hello world en c et en c++ au niveau asm ca suffit pour se rendre compte de la blague
La derniere fois que j'ai fait du c++ il me crachait des erreurs parcequ'il aime pas les pointeurs de fonction c'est sur que de son coter il y en as pas ... oups j'oubliais la vttable .
pour les systemes enbarquer je suis bien d'accord le c++ n'as rien a y faire et pour les os "moderne" on se demande pourquoi le kernel linux est entièrement en C voyons faudrais moderniser en passer au c++ histoire de rigoler un peu.
Enfin bref le c++ c'est une usine a gaz qui commence a devenir une centrale nucléaire rien que la derniere norme avec les templates... ca peut etre utile pour une appli de compta et encore les languague haut niveau remplisse mieux le taf.
La seul utilite que j'y voie c'est pour les jeux video vu qu'ils on besoin de perf et d'OO a part ca il est utilisé dans quoi???
Le c a l'avantage d'etre proche de la machine on peut meme y integrer de l'asm facilement, le faire en c++ comment dire ...
pour le coter sécurité heum justement cacher les choses ne les rendra pas plus sécurisé ca donnera juste l'impression que ca l'est, par un contre un dev qui va te faire du c (et qui as de l'experience) comprendra ce qu'il se passe et saura ou ca peut planter et comment le corriger.
J'aurais encore plein de raison de choisir le C au C++ mais bon j'ai du taff qui m'attend donc pas le temps d'argumenter plus.

[Ehonn]

@Tagashy, ton message n'est pas vraiment techniquement correct.

La derniere fois que j'ai fait du c++ il me crachait des erreurs parcequ'il aime pas les pointeurs de fonction c'est sur que de son coter il y en as pas ... oups j'oubliais la vttable.

Tu devrais retester

pour les systemes enbarquer je suis bien d'accord le c++ n'as rien a y faire

Pourquoi pas ?
(De plus système embarqué ne signifie pas toujours performances et temps réels (?))

on se demande pourquoi le kernel linux est entièrement en C voyons faudrais moderniser en passer au c++ histoire de rigoler un peu.

GCC et Clang sont en C++.
Linux est en C principalement pour des questions de choix personnels.

Enfin bref le c++ c'est une usine a gaz qui commence a devenir une centrale nucléaire rien que la derniere norme avec les templates...

Les templates ont été introduites avant C++14

ca peut etre utile pour une appli de compta et encore les languague haut niveau remplisse mieux le taf.

C++ est un langage de haut niveau (qui laisse la possibilité de faire du bas niveau) (faut se mettre d'accord sur la définition avant tout débat).

La seul utilite que j'y voie c'est pour les jeux video vu qu'ils on besoin de perf et d'OO a part ca il est utilisé dans quoi???

La programmation générique et la métaprogrammation, ces deux aspects sont peu présents / assez pauvres dans le langage C.

Le c a l'avantage d'etre proche de la machine on peut meme y integrer de l'asm facilement, le faire en c++ comment dire ...

Je ne crois pas que cela soit plus compliqué qu'en C (?)

pour le coter sécurité heum justement cacher les choses ne les rendra pas plus sécurisé ca donnera juste l'impression que ca l'est

Le RAII permet de ne pas oublier de libérer la mémoire (tout objet s'utilise comme un type de base).

par un contre un dev qui va te faire du c (et qui as de l'experience) comprendra ce qu'il se passe et saura ou ca peut planter et comment le corriger.

Dans ce cas, il devra avoir un minimum de notions en C++.
Si un développeur n'a fait que du C, il risque de ne pas comprendre immédiatement le code source en C++ et ses subtilités.

[wolinn]

...
La seul utilite que j'y voie c'est pour les jeux video vu qu'ils on besoin de perf et d'OO a part ca il est utilisé dans quoi???
...

En CAO et simulation physique par exemple, c'est le standard industriel, au moins pour les projets récents, à côté des anciens codes en C et Fortran. Ca fait longtemps qu'on ne développe plus un modeleur géométrique en C, parce que pour ce type d'application, le C++ est vraiment intéressant.