Discussion :

[3DArchi]

[EDIT] Cette discussion fait suite à ce message[/EDIT]

Auquel cas, le C++ n'est peut être pas la solution à utiliser, offrant moins de contrôle sur certains opérations.

shame on you

On fait du RT embarqué en C++[*] et ça se passe bien (bon je concède des interruptions en C[**] et l'ordonnanceur C+ASM [***])

[*] entre 128 et 512ko de code pour des acquisitions à 2kHz (bon, ok on est à 500µs)
[**] : rien n'empêche de les faire en C++ mais avec une fonction libre ou de classe car aucun objet n'est associé à une IT. Ensuite, il est vrai qu'on évite () des choses comme les exceptions ou du rtti dans les IT principalement pour des pbs de coût temps (une IT ça doit quand même rester assez rapide).

[***] : COTS donc C. Mais rien n'empêcherait d'avoir une bonne partie en C++. D'ailleurs, l'OS (l'ordonnanceur) est wrappé en classes C++.

[Emmanuel Deloget]

shame on you

On fait du RT embarqué en C++[*] et ça se passe bien (bon je concède des interruptions en C[**] et l'ordonnanceur C+ASM [***])

[*] entre 128 et 512ko de code pour des acquisitions à 2kHz (bon, ok on est à 500µs)
[**] : rien n'empêche de les faire en C++ mais avec une fonction libre ou de classe car aucun objet n'est associé à une IT. Ensuite, il est vrai qu'on évite () des choses comme les exceptions ou du rtti dans les IT principalement pour des pbs de coût temps (une IT ça doit quand même rester assez rapide).

[***] : COTS donc C. Mais rien n'empêcherait d'avoir une bonne partie en C++. D'ailleurs, l'OS (l'ordonnanceur) est wrappé en classes C++.

Enfin, voui, mais avoue quand même que :

1/ C++ sans RTTI, ni exception, en limitant au max le polymorphisme d'héritage, et de manière générale en limitant tout ce qui fait sa puissance, c'est pas vraiment du C++ - c'est du C with Classes

2/ la librairie standard n'a pas vraiment été conçue pour être utilisée dans le domaine de l'embarqué. Un exemple typique : les vector. Très simples à utiliser, robustes et tout ce que tu veux. Sauf que dans certains tu es incapable de prévoir quand est-ce qu'un simple ajout d'une valeur dans le vecteur va le redimensionner. Et en TR, ne pas pouvoir prévoir ce genre de choses, ça pose un sacré problème ! (tu va me dire : fait un allocateur ; ben non, parce que l'allocateur n'est pas responsable de la stratégie d'allocation, mais de l'allocation elle même ; quel que soit le sens dans lequel je tourne le problème, je ne vois pas de solution immédiate).

3/ sous linux, la libstdc++ fait environ 2Mo (strippée). C'est un peu énorme, quand même Certes, l'exe sera de taille correcte, mais la lib est quand même nécessaire. Si tu compiles ton programme en statique, il va faire un sale tête (à moins que tu n'utilises vraiment rien de la lib standard, y compris new/delete).

M'enfin, j'ai dit "peut-être", et "moins", ce qui atténue ma phrase et la rends globalement cohérente avec ces quelques explications

[3DArchi]

Non, non. A part des points bien particulier (comme les ITs), tu peux faire du full C++[*]. Les compilos sont suffisamment performants pour démontrer qu'une utilisation d'exception est beaucoup plus économe en temps et taille qu'avoir toutes les fonctions retournant un code OK/KO qui est systématiquement testé par l'appelant. Idem pour les fonctions virtuelles, l'héritage multiple et virtuel,etc. Et les template, ah les template ! Une fois goûtées difficile de s'en passer (et toujours moins de code bloat qu'avec du copier/coller). Tu as de plus en plus de monde convaincu que faire du full C++ en embarqué ne nuit pas au perf. En réalité, la première cause de code bloat et perfs détériorées se trouve entre la chaise et le clavier (ie : la qualité du code ET l'architecture du soft), pas dans le langage.

[*] : Ok la STL,c'est dur. Mais les compilateurs proposent des versions embarquées plus ou moins réduites mais qui restent pertinentes (Green Hills propose une STL de 118ko (sans exceptions, doit manquer les locales et quelques features liés aux flux)

[Emmanuel Deloget]

Non, non. A part des points bien particulier (comme les ITs), tu peux faire du full C++[*]. Les compilos sont suffisamment performants pour démontrer qu'une utilisation d'exception est beaucoup plus économe en temps et taille qu'avoir toutes les fonctions retournant un code OK/KO qui est systématiquement testé par l'appelant. Idem pour les fonctions virtuelles, l'héritage multiple et virtuel,etc. Et les template, ah les template ! Une fois goûtées difficile de s'en passer (et toujours moins de code bloat qu'avec du copier/coller). Tu as de plus en plus de monde convaincu que faire du full C++ en embarqué ne nuit pas au perf. En réalité, la première cause de code bloat et perfs détériorées se trouve entre la chaise et le clavier (ie : la qualité du code ET l'architecture du soft), pas dans le langage.
[*] : Ok la STL,c'est dur. Mais les compilateurs proposent des versions embarquées plus ou moins réduites mais qui restent pertinentes (Green Hills propose une STL de 118ko (sans exceptions, doit manquer les locales et quelques features liés aux flux)

Ce n'est pas uniquement une question de perf, c'est aussi une question de contrôle du temps perdu. Tous les langages perdent du temps, mais en C++, il est parfois difficile de contrôler ce qui va se passer lorsque tu fais quelque chose (exemple avec new() qui va - ou pas - renvoyer une exception pour une raison ou une autre, ce qui rends les allocations très risquées dans certaines parties du code, sauf à faire du malloc()[*]; et si tu commences à mixer malloc() et new() dans ton code... pas besoin de dessin, hein ? ).

Que ce soit en pur C++ ou avec Embedded C++, il y a une tonne de détails de ce genre à prendre en compte. Un expert va s'en sortir, mais quelqu'un qui est un peu moins expert a de bonnes chances de se prendre les pieds dans le tapis.

Mais je suis quand même d'accord avec tout ça. Encore une fois, je ne dis pas que tu ne peux pas ; simplement que je penses que c'est une solution qui doit être vérifiée doublement avant d'être utilisée. Tu me connais, et tu sais que je ne vais pas renier sa versatilité au C++ - pas moi
[*] un new nothrow ne suffit pas, puisque le constructeur appelé peut générer une exception.

[3DArchi]

Ce qui me fait soucis, c'est qu'en lisant cela, on puisse conclure : C++, c'est pas pour l'embarqué/TR. Ce qui est faux.

Les contraintes temporelles sont dans beaucoup de projets limitées à une partie restreinte de l'application, la grande majorité du reste du code n'ayant pas à subir cette contrainte . Ces parties risquées ont déjà des règles de codage C plus dures. Ben, idem en C++. Pour reprendre ton exemple, là où le new va te poser problème, en général, le malloc était déjà interdit (pour des raisons comparables).

Je n'ai que rarement rencontrer des problèmes à cause du langage/compilateur/OS/HW. Dans 99% des cas, le bug (détection+analyse+correction<3hj) était une 'étourderie' du développeur (même junior, c'est rarement un aspect du langage mal utilisé/compris). Dans 99%s des cas, le bug coriace (détection+analyse+correction>5hj), le bug est un problème d'architecture logiciel.

Bref, le C++ c'est bon, mangez-en

[Emmanuel Deloget]

Alors je mets en gros :

Il n'existe pas de contre-indication notable à l'utilisation du C++ sur une plateforme embarquée

Et je rajoute en petit

mais il y a quand même quelques subtilités

[screetch]

je pense que les mêmes pièges qui touchent l'embarqué touchent aussi les applis plus standards.
Coder de l'embarqué en C c'est déjà dur, comparer a coder du C pour linux, et la difficulté augmente d'un même ordre de magnitude entre le C++ "normal" et embarqué.

[ac_wingless]

De loin le plus problème du C++ en embarqué, c'est la qualité des compilateurs, et par conséquent l'impossibilité de compter sur l'énorme infrastructure basée sur l'excellente qualité des compilateurs gcc et VC++ (Boost bien sûr, mais aussi d'autres). Le sujet a déjà été abordé, et j'avais participé à la discussion en particulier sur le point des exceptions, mais j'y mentionnais quelques sujets autres que les exceptions et le respect des standards.

Le résultat est bien résumé par les posts ci-dessus: le C++ en embarqué, ça fait pas comme le C++ sur PC (mais de toute façon, l'embarqué, ça fait pas du tout du tout comme si on était sur PC, l'exemple des vectors m'a fait sourire).

Mais j'irais plus loin que la simple non contre-indication: le C++ apporte toujours quelque chose dans une équipe travaillant dans l'embarqué. Un programmeur embarqué expérimenté ne sera pas du tout dérouté par les petits problèmes cités ci-dessus, il en mange bien d'autres au ptidéj'.