Discussion :

[poukill]

Salut à tous,

On entend dire par monts et par vaux que pour le domaine de l'embarqué, le C est plus adapté que le C++.

1 - Est-ce vrai ?
2 - Si oui, Pourquoi ?

J'ai dans l'idée que les deux langages produisent de l'assembleur, donc pourraient être équivalent.

Je vous écoute !

EDIT : J'aurai bien mis cette discussion dans C et C++ mais je crois pas que ce soit faisable !

[méphistopheles]

Salut à tous,

On entend dire par monts et par vaux que pour le domaine de l'embarqué, le C est plus adapté que le C++.

1 - Est-ce vrai ?
2 - Si oui, Pourquoi ?

J'ai dans l'idée que les deux langages produisent de l'assembleur, donc pourraient être équivalent.

Je vous écoute !

Personnellement, je ne pense vraiment pas que l'un soit plus approprié que l'autre... par contre, la plupart des compilateurs pour l'embarqué (pour microcontroleur s'entend) sont des compilateurs C ... du coups, en général, c'est plus par défaut que par choix qu'on fait du C sur l'embarqué.

Je pense aussi que déjà que certaines fonctions C des bibliothèques standard ne sont pas disponible dans l'embarqué, les fabricants de compilateurs n'ont pas en plus envie de refaire les bibliothèques C++ (encore que je suis pas sûr de savoir ce qu'il y a a refaire).
D'autre part, un programme embarqué doit être de petite taille... ce qui est incompatible avec des mécanismes tel que les exceptions.

Enfin (et surtout) pas mal de chips embarquée... ne supportent pas l'allocation dynamique (puisque pas de système d'exploitation) du coups, la seule feature que peut fournir le C++ est d'ajouter des méthodes au struct: pas de strings, pas de conteneurs, pas de iostream. Eventuellement, on peut avoir des listes (statiques-_-') et des itérateurs (mais sur des tableaux statiques... on perd un peu l'intérêt) et garder les algorithmes qui vont avec.

Je suppose que c'est ça. Ensuite, certains templates m'auraientt quand même facilité la tâche lorsque je codais sur microcontroleurs, mais les cas étaient rares.

EDIT : J'aurai bien mis cette discussion dans C et C++ mais je crois pas que ce soit faisable !

Peut-être un gentil modo pourra-il mettre un lien :p ?


Cordialement.

[3DArchi]

Salut,
En embarqué, j'ai croisé aussi bien des projets C que C++. Si ton projet consiste en quelques milliers de ligne, peut être pourras-tu construire une version C plus performante en terme de taille et de vitesse (je n'ai jamais fait l'essai mais je veux bien être crédule). Mais pour un projet complexe, les 'surcouts' de taille et de vitesse induits par le compilateur/langage seront probablement négligeables au regard de la conception mise en place.
Cependant, en embarqué, on ne prend souvent pas 'tout' le C++ pour de bonnes ou de mauvaises raisons :
-> Les exceptions sont écartées : elles génèrent un surcout de taille de code et performance (raisons valables) mais sont souvent aussi mal comprises et écartées à cause de ça (raison typique : non déterminisme de l'appel, approche programmation défensive récurrente, etc.)
-> Les templates : les 'vieux' compilateurs avaient des comportements très variables avec les templates et donc les projets ont eu tendance à les écarter à cause de ça. Je soupçonne aussi une maîtrise aléatoire. Certains (vieux) compilateurs pouvaient générer le code d'un template instancié avec le même jeux d'arguments autant de fois que d'unité de compilation où il était utilisé => d'où une méfiance de leur tendance à l'inflation de code. Enfin, l'approche générique tend à favoriser le polymorphisme de surcharge au détriment de la coercition ou l'inclusion (il me semble). D'où encore une inflation possible. Tout cela aujourd'hui perd de son sens par l'utilisation de compilateur performant et par une meilleure maîtrise de l'approche générique.
-> L'héritage multiple : j'ai vu des projets dans lesquels l'héritage multiple était désactivé soit disant pour le surcout mémoire que cela engendre. Même s'il y a un léger surcout je soupçonne que cela est dû à une mauvaise maîtrise de ces concepts.
-> RTTI : souvent désactivé pour minimiser l'emprunte mémoire des objets instanciés (adieu downcast de toute façon considéré comme probablement conception problématique).

La question de l'allocation dynamique est indépendante du langage (C ou C++). Et elle est traitée de différentes façons : allocation totalement interdite, allocation gérée par des pools de bloc mémoire de taille fixe, etc. Souvent la méfiance de l'allocation dynamique tient au coût (en temps d'exécution) que peut avoir une allocation ou une libération ainsi qu'au risque d'un échec d'allocation. Ceci est plus un problème de ton système que du langage.

Pour conclure, choisis C ou C++ en fonction de la qualité des compilateurs que tu peux trouver, des compétences de l'équipe de dev (pas la peine de faire du C++ si tu n'as que des cadors en C ou le contraire). Certaines parties pourront être mixes (routines C/asm pour des ITs, approches C++ ailleurs).

[méphistopheles]

La question de l'allocation dynamique est indépendante du langage (C ou C++).

Certes. Cependant dans le cas de l'interdiction totale, cela a un énorme impact sur les possibilités du C++...

Et elle est traitée de différentes façons : allocation totalement interdite, allocation gérée par des pools de bloc mémoire de taille fixe

gestion de Pool souvent laissé à la charge de l'utilisateur

Souvent la méfiance de l'allocation dynamique tient au coût (en temps d'exécution) que peut avoir une allocation ou une libération ainsi qu'au risque d'un échec d'allocation.

Ainsi qu'a l'absence de système d'exploitation non ? car je ne vois pas comment avoir d'allocation dynamique sans système d'exploitation ...

Pour conclure, choisis C ou C++ en fonction de la qualité des compilateurs

Heureusement, de plus en plus de systèmes embarqués intègrent la possibilité d'utiliser des systèmes d'exploitation "standard" comme linux ou autre... et là, on a vraiment le choix

[poukill]

Personnellement, je ne pense vraiment pas que l'un soit plus approprié que l'autre... par contre, la plupart des compilateurs pour l'embarqué (pour microcontroleur s'entend) sont des compilateurs C ... du coups, en général, c'est plus par défaut que par choix qu'on fait du C sur l'embarqué.

C'est une raison !

Je pense aussi que déjà que certaines fonctions C des bibliothèques standard ne sont pas disponible dans l'embarqué, les fabricants de compilateurs n'ont pas en plus envie de refaire les bibliothèques C++ (encore que je suis pas sûr de savoir ce qu'il y a a refaire).

J'aurai pensé qu'il existerait un compilateur pour embarqué, possédant un paquet de cibles différentes pour s'adapter au projet. Un compilateur respectant un minimum le standard pour que quelques bibliothèques tierces vraiment adaptées puissent être intégrées.

D'autre part, un programme embarqué doit être de petite taille... ce qui est incompatible avec des mécanismes tel que les exceptions.

Effectivement.

Salut,
En embarqué, j'ai croisé aussi bien des projets C que C++. Si ton projet consiste en quelques milliers de ligne, peut être pourras-tu construire une version C plus performante en terme de taille et de vitesse (je n'ai jamais fait l'essai mais je veux bien être crédule). Mais pour un projet complexe, les 'surcouts' de taille et de vitesse induits par le compilateur/langage seront probablement négligeables au regard de la conception mise en place.

C'est pour ça que je pose la question. Le C ne me posera pas plus de problèmes des ça, mais la conception est plus "souple" en C++...

-> Les exceptions sont écartées : elles génèrent un surcout de taille de code et performance (raisons valables) mais sont souvent aussi mal comprises et écartées à cause de ça (raison typique : non déterminisme de l'appel, approche programmation défensive récurrente, etc.)

OK, Mephistopheles et toi êtes d'accord la dessus. C'est pas spécialement génant, à partir du moment où l'on sait que l'on doit faire sans.

-> Les templates : les 'vieux' compilateurs avaient des comportements très variables avec les templates et donc les projets ont eu tendance à les écarter à cause de ça. Je soupçonne aussi une maîtrise aléatoire. Certains (vieux) compilateurs pouvaient générer le code d'un template instancié avec le même jeux d'arguments autant de fois que d'unité de compilation où il était utilisé => d'où une méfiance de leur tendance à l'inflation de code. Enfin, l'approche générique tend à favoriser le polymorphisme de surcharge au détriment de la coercition ou l'inclusion (il me semble). D'où encore une inflation possible. Tout cela aujourd'hui perd de son sens par l'utilisation de compilateur performant et par une meilleur maîtrise de l'approche générique.

Je note l'apparition multiple du mot "vieux compilo". Je sais que le C++ évolue plus vite que le C, m'enfin quand même il y a un comitee alors c'est pas si rapide que ça.

-> L'héritage multiple : j'ai vu des projets dans lesquels l'héritage multiple était désactivé soit disant pour le surcout mémoire que cela engendre. Même s'il y a un léger surcout je soupçonne que cela est dû à une mauvaise maîtrise de ces concepts.

L'héritage multiple est pratique dans certaines conceptions mais en général on peut s'en passer.

-> RTTI : souvent désactivé pour minimiser l'emprunte mémoire des objets instanciés (adieu downcast de toute façon considérée comme probablement conception problématique).

Effectivement, le pattern visitor est plus adapté de toute façon.

La question de l'allocation dynamique est indépendante du langage (C ou C++). Et elle est traitée de différentes façons : allocation totalement interdite, allocation gérée par des pools de bloc mémoire de taille fixe, etc. Souvent la méfiance de l'allocation dynamique tient au coût (en temps d'exécution) que peut avoir une allocation ou une libération ainsi qu'au risque d'un échec d'allocation. Ceci est plus un problème de ton système que du langage.

OK je comprends.

Pour conclure, choisis C ou C++ en fonction de la qualité des compilateurs que tu peux trouver, des compétences de l'équipe de dev (pas la peine de faire du C++ si tu n'as que des cadors en C ou le contraire). Certaines parties pourront être mixes (routines C/asm pour des ITs, approches C++ ailleurs).

Tu as parfaitement raison pour les compétences. Personnellement, c'est vraiment cette histoire de compilateur qui m'interroge. Chaque marque de carte a son propre compilateur qu'ils n'arrivent pas à mettre à jour ?

[3DArchi]

J'aurai pensé qu'il existerait un compilateur pour embarqué possédant un paquet de cibles différentes pour s'adapter au projet.

Il existe DES compilos pouvant cibler un ou des micro différents.

Un compilateur respectant un minimum le standard pour que quelques bibliothèques tierces vraiment adaptées puissent être intégrées.

Ces compilos respectent plus ou moins le standard (comme les compilos windows ou linux d'ailleurs, cela n'a rien à voir avec l'embarqué) selon leur ancienneté et donc tu peux utiliser des bibliothèques tierces. Mais tu as probablement une étape de qualification avant.

Je note l'apparition multiple du mot "vieux compilo". Je sais que le C++ évolue plus vite que le C, m'enfin quand même il y a un comitee alors c'est pas si rapide que ça.

En entreprise, il est courant de rester sur un compilo 'ancien' comprendre fin des années 90 début 2000. A cette époque, le C++ n'était pas encore normalisé ou la peinture était encore fraîche. Et les templates sont la feature du langage ayant probablement la plus grande volatilité sur ces compilateurs. Note qu'aujourd'hui, la plupart des vendeurs proposent des versions plus récentes et plus respectueuses de la norme (en revanche, je ne saurais pas te dire s'il existe déjà des compilo ciblant l'embarqué avec du C++0x).

Chaque marque de carte a son propre compilateur qu'ils n'arrivent pas à mettre à jour ?

Les compilateurs ciblent en général un ou des micro et les éditeurs ont des versions récentes. A toi d'identifier ceux candidats pour ta plateforme hard cible et voir si le compilo C++ a le bon niveau par rapport à ce que tu attends. Si tu as le temps, probablement qu'il faut conduire une phase de qualification des outils en cohérence avec la définition hardware de ton système.

@méphistopheles : l'utilisation de l'allocation dynamique n'a rien à voir avec un OS 'lourd' (type Linux ou Windows Mobile). Certains projets embarqués utilisent de l'allocation dynamique gérée par un gestionnaire de mémoire sans avoir d'OS lourd de ce type. Les systèmes embarqués ne disposent pas forcément de mode noyau, d'adressage virtuel, de notion de processus etc. Ce qui fait que la notion d'OS comme définie pour un PC se trouve diluée. D'ailleurs souvent, le code regroupé sous OS est juste le gestionnaire de tâches (au sens thread) avec un ordonnanceur, de quoi sauvegarder un contexte (pile, registres...). La gestion de la mémoire, les 'drivers' (flash, RTC, watchdog, carte réseaux, LCD, etc..) sont des tâches comme les tâches applicatives... ou parfois tout est pris en charge par l'OS. Tout dépend Bref, la gestion dynamique mémoire peut être indépendante de ton OS.
Et pour répondre à une autre de tes remarques, on peut très bien faire de bonnes applis C++ sans allocation dynamique (en embarqué). On n'a pas toujours ce besoin.

[koala01]

Salut,

Pour ce que je crois en savoir, C a longtemps été considéré comme... un assembleur plus facile à relire.

En tout cas, on croise encore souvent des gens pour le prétendre

Ceci dit, je me demande si la raison n'est pas, tout simplement, à un problème d'offre et de demande.

Si je me mettais à la place des fondeurs de chips embarqué, je suivrais sans doute un raisonnement proche de

Lorsque tu crées un nouveau chip embarqué, il est déjà "suffisamment difficile" de fournir un compilateur C, dont on sait qu'il sera utilisé par... la grosse majorité des développeurs pour l'embarqué, et l'on peut donc se demander s'il est vraiment utile de... mouiller sa chemise pour ajouter un compilateur C++ qui ne sera sans doute utilisé que par une minorité

Je ne dis absolument pas qu'un tel raisonnement soit juste ni même qu'il soit, simplement, judicieux, mais, comme il est tellement encré dans les mentalités que seul C est réellement adapté aux exigences de l'embarqué, on peut réellement se demander si ce n'est pas le raisonnement suivi

J'aurai pensé qu'il existerait un compilateur pour embarqué possédant un paquet de cibles différentes pour s'adapter au projet. Un compilateur respectant un minimum le standard pour que quelques bibliothèques tierces vraiment adaptées puissent être intégrées.

Si tu peux estimer qu'un compilateur puisse être prévu pour être capable de fournir des exécutables pour différentes cibles (comme, par exemple Gcc, qui peut être compilé de manière à en supporter un grand nombre), il faut cependant considérer le fait que tu dois déterminer les (groupes de) cibles prévues au moment où tu... compile ton compilateur:

Un compilateur compilé pour fournir des exécutables utilisables sous linux ne pourra pas... fournir d'exécutables utilisables sous windows ou sous spark, et inversément, même si tu peux compiler un compilateur croisé (capable de fournir des exécutables utilisables sous des cibles différentes que celle sur laquelle le compilateur est utilisé).

Or, quand tu rentres dans le domaine de l'embarqué, tu dois d'office travailler sur un compilateur croisé, car il est peu probable que tu sois capable de... faire tourner le compilateur sur ton composant embarqué

Le problème des bibliothèques tierces est similaire: Si l'on peut envisager de leur permettre de s'adapter au chipset sur lequel elles seront utilisées, il faudra toujours... la fournir dans une version utilisable par le système cible, avec tout ce que cela peut comporter de besoin de compilation conditionnelle

[méphistopheles]

@méphistopheles : l'utilisation de l'allocation dynamique n'a rien à voir avec un OS 'lourd' (type Linux ou Windows Mobile). Certains projets embarqués utilisent de l'allocation dynamique gérée par un gestionnaire de mémoire sans avoir d'OS lourd de ce type. Les systèmes embarqués ne disposent pas forcément de mode noyau, d'adressage virtuel, de notion de processus etc. Ce qui fait que la notion d'OS comme définie pour un PC se trouve diluée. D'ailleurs souvent, le code regroupé sous OS est juste le gestionnaire de tâches (au sens thread) avec un ordonnanceur, de quoi sauvegarder un contexte (pile, registres...). La gestion de la mémoire, les 'drivers' (flash, RTC, watchdog, carte réseaux, LCD, etc..) sont des tâches comme les tâches applicatives... ou parfois tout est pris en charge par l'OS. Tout dépend Bref, la gestion dynamique mémoire peut être indépendante de ton OS.

Je ne parlais pas forcément d'un os lourd, mais à partir du moment ou il y a gestion de la mémoire et scedueler, c'est pour moi déjà un os.

Et pour répondre à une autre de tes remarques, on peut très bien faire de bonnes applis C++ sans allocation dynamique (en embarqué). On n'a pas toujours ce besoin.

Certes, les templates permettraient justement de définir des static-array ou autres objets permettant de gérer plus facilement nos objets non allouable. De même l'héritage reste valable et utilisable, même si l'utilisation de fonction virtuelles perd beaucoup de son intérêt (tous les objets sont connus dès le départ). Par contre,la majeure partie de la stl saute et la notion de RAII et de RFID aussi avec les constructeurs et destructeurs... Bref, ça reste limité.

Pour ce que je crois en savoir, C a longtemps été considéré comme... un assembleur plus facile à relire.

En tout cas, on croise encore souvent des gens pour le prétendre

Je confirme des "compilateurs Assembleurs" (oui, oui, pas seulement des traducteurs) fournissant tout un panel de "super-macros" sont aussi souvent fournies avec... il faut dire que ces fondeurs travaillent justement en assembleur sur leur puce et il parait logique qu'ils se dotent d'un outil convenable pour ça.

Ceci dit, je me demande si la raison n'est pas, tout simplement, à un problème d'offre et de demande.

Parfaitement. D'autant que la plupart des demandes exigent un langage plus évolué tournent sur des puces plus puissantes... et souvent à même de pouvoir faire tourner un os du genre µclinux ou autre. Il est certain que quand on a une mémoire de 8ko, le programme qui ira dedans à peu de chance d'être extrêmement complexe.

Un compilateur compilé pour fournir des exécutables utilisables sous linux ne pourra pas... fournir d'exécutables utilisables sous windows ou sous spark, et inversément, même si tu peux compiler un compilateur croisé (capable de fournir des exécutables utilisables sous des cibles différentes que celle sur laquelle le compilateur est utilisé).

Encore que de ce coté, on commence justement à voir apparaitre pas mal de puces basées sur (ou intégrant un) ARM qui peuvent être cross compilées à partir de gcc... donc de beaucoup plus de systèmes d'exploitations

Or, quand tu rentres dans le domaine de l'embarqué, tu dois d'office travailler sur un compilateur croisé, car il est peu probable que tu sois capable de... faire tourner le compilateur sur ton composant embarqué

encore une fois, ça dépend de la cible. Comme dit plus haut, de plus en plus de chips peuvent faire tourner un µclinux ou autre.

Le problème des bibliothèques tierces est similaire: Si l'on peut envisager de leur permettre de s'adapter au chipset sur lequel elles seront utilisées, il faudra toujours... la fournir dans une version utilisable par le système cible, avec tout ce que cela peut comporter de besoin de compilation conditionnelle

pas forcément, on peut se contenter de générer le code machine en cross-compilation... ce qui ne dépend pas du type du système source mais seulement du composant cible.