Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

C ou C++ ? Quel langage choisir pour un projet sur une cible embarquée ?

Le , par poukill

0PARTAGES

0  0 
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 !

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de ac_wingless
Membre confirmé https://www.developpez.com
Le 09/08/2010 à 12:22
Beaucoup de choses ont été listées, presque toutes vraies (compilateurs vieux ou non standard ou inexistants, grande variabilité des processeurs utilisés, problème majeur des allocations de mémoire et des exceptions, etc.). Il y a encore certaines idées reçues qui trainent... (les exceptions C++ "mal comprises" par les programmeurs embarqués... pardon ? S'il y a vraiment un truc que les programmeurs embarqués comprennent fondamentalement avec leurs tripes, c'est bien le traitement robuste de tout type de situation exceptionnelle, qu'elle soit C++, matérielle, asynchrone, velue, ou verte à pois rouges...).
Je voulais rajouter deux ou trois idées en vrac:

Capabilité du processeur

Certains processeurs ne proposent que le C car ils n'ont tout simplement pas les instructions nécessaires pour implémenter certains concepts fondamentaux du C++. Certains se souviennent du fait qu'il fallait utiliser un 68020 au lieu d'un 68000 pour pouvoir accéder à certaines instructions atomiques nécessaires à l'implémentation d'un OS multiprocesseur, eh bien c'est pareil aujourd'hui pour certaines choses, comme par exemple les vtables pour la POO (il fut un temps pas si ancien où on n'avait carrément aucune possibilité d'indirection en GPU, ni même les moyens d'itérer sur une table d'adresses.).

Exception et conception.
Dans certains cas d'embarqué (comme l'ont souligné beaucoup, c'est un terme peu précis, je parle donc de la frange des instruments autonomes), le besoin d'exception dans le code indique un problème de conception dans le matériel. Ça peut paraître curieux aux programmeurs OS/web/client riche, mais c'est dû au fait que le programmeur embarqué travaille de concert avec le concepteur du système complet, et qu'il n'existe parfois tout simplement pas d'environnement extérieur à qui reporter une exception. Dans certains cas on peut se contenter d'une solution à la watchdog, mais quand on ne peut pas se le permettre, on se focalise sur l'élimination dans le matériel de la raison pour laquelle le logiciel a besoin d'une exception.

Décoration du C++
On peut aussi mentionner les cas où on contrôle le firmware. Pour ceux qui ne sont pas familiers avec ce genre de projet, on peut se placer dans le cas d'un modèle de programmation ultra moderne (microprocesseur dit "softcore", avec ciblage possible par gcc, tout en permettant certaines fonctions intrinsèques câblées qui sont totalement spécifiques à l'application. A coté, le C ou même l'assembleur x86 parait de très haut niveau. Exemple typique en traitement de signal: classe de nombres sur 19 bits normalisés entre -0.93 et +0.6 à étagement exponentiel, sans division mais avec convolution câblée. Ou à l'inverse monter en abstraction et câbler un double dispatch, apparaissant comme du C++ natif moyennant un peu de magie par préprocesseur. Cela n'est pas si frivole que ça en a l'air, surtout en traitement numérique ou l'on peut, par une écriture très naturelle, enchainer les opérations sans se préoccuper du type réel à l'exécution des opérandes. C'est très léger à l'exécution (câblé), mais peut demander un pré-traitement lourd si on veut être général... ce qui est très rare en embarqué . Nous avons ainsi une "petite" librairie sympa VHDL où on manipule des signaux de type variable comme s'ils étaient des flottants à multiplication spéciale, tout en ne dégradant jamais le type résultat.

Edit: ce n'est pas clair dans la rédaction originale: même si on génère le code par gcc, un microprocesseur softcore est souvent limité à l'"embedded C++", qui est un sous ensemble finalement très limité du C++. Par exemple on a des constructeurs, mais pas de polymorphisme. Des gestions d'interruptions matérielles, mais pas d'exceptions logicielles (!). Etc.
4  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 05/08/2010 à 9:39
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).
2  0 
Avatar de ptyxs
Membre averti https://www.developpez.com
Le 13/08/2010 à 14:53
Je découvre ce fil et je voudrais signaler juste ceci.

Le dernier ouvrage de Stroustrup Programming : Principles and Practise Using C++, décembre 2008, contient un chapitre entier consacré à l'embarqué : chapitre 25 Embedded Systems Programming. Très intéressant.

D'autre part dans Masterminds of Programming : Conversations with the Creators of Major Programming Languages (par Biancuzzi et Warden), le premier chapitre est une interviouve de Stroustrup. Il évoque le rôle du C++ dans l'embarqué.
On y lit ceci notamment :


I helped write the coding guidelines for the mission-critical software for Lockheed Martin's Joint Strike Fighter. That's an "all C++ plane". You may not be particularly keen on military planes, but there is nothing particularly military about the way C++ is used and well over 100,000 copies of the JSF++ coding rules have been downloaded from my home pages in less than a year, mostly by nonmilitary embedded systems developpers, as far as I can tell.

C++ has been used for embedded systems since 1984, many useful gadgets have been programmed in C++, and its use appears to be rapidly increasing. Examples are mobile phones using Symbian or Motorola, the iPods, and GPS systems. I particularly like the use of C++ on the Mars rovers: the scene analysis and autonomous driving subsystems, much of the earth-bases communication systems, and the image processing.

Par parenthèses, ceci contredit donc frontalement ce qui a été dit plus haut :

Citation Envoyé par Blackknight Voir le message
Il y a un domaine où le C++ n'a pas sa place en embarqué, c'est dans le cas des applications aéronautiques régies par le standard DO-178B.
En fait, ce sont même l'ensemble de la programmation objet qui n'est pas autorisée même s'il existe un document sur cette utilisation. Bon, ça changera peut-être pour la révision C du standard.
2  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 05/08/2010 à 18:57
Citation Envoyé par poukill Voir le message

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.
Citation Envoyé par poukill Voir le message
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.
Citation Envoyé par poukill Voir le message

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).
Citation Envoyé par poukill Voir le message
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.
1  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 06/08/2010 à 0:01
Citation Envoyé par méphistopheles Voir le message

Certes, les templates permettraient justement de définir des static-array ou autres objets permettant de gérer plus facilement nos objet non allouable.
Ou de gérer des tableaux allouables dynamiquement, mais uniquement pendant une phase d'initialisation. Ou encore des tableaux de taille variable mais à la taille maximale fixée.

Citation Envoyé par méphistopheles Voir le message

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é.
Là, je ne vois franchement pas pour quelle raison... Le RAII sert à gérer d'autres ressources que la mémoire aussi, et dans un programme embarqué, il peut y avoir des ressources à prendre et relâcher, et les relâcher correctement peut être crucial.

Et certains systèmes embarqués peuvent se permettre l'allocation de mémoire partout. J'ai déjà bossé sur un système embarqué composé de 11 PC reliés en réseau, et où les contraintes temps réelles, bien que présentes, étaient telles que l'allocation dynamique, on ne s'en privait pas la plupart du temps.

Tout ça pour dire qu'embarqué est un terme un peu vague, mais que quel que soit le type d'embarqué sur lequel bosser, quelles que soient les contraintes associées, je pense que le C++ bien maîtrisé peut apporter une simplicité (et donc une fiabilité) par rapport au C, à condition d'être disponible sur l'architecture cible.

Citation Envoyé par Poukill
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.
Ce n'est pas tant lié à leur vitesse d'évolutions (qui sont à peu près comparables, un standard tous les 10/15 ans...), mais à la complexité de réalisation d'un compilateur C++, au moins d'un ordre de grandeur de plus qu'un compilateur C.
1  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 06/08/2010 à 5:50
Salut,
Citation Envoyé par méphistopheles Voir le message
Je ne parlait 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.
Sauf que la gestion de la mémoire (statique et dynamique) peut être complètement gérée par le projet et ne pas dépendre d'une couche tierce identifiée comme OS et qui ne contiendrait rien pour cela.

Citation Envoyé par méphistopheles Voir le message
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).
Ce n'est pas parce que tu n'as pas d'allocation et que tu connais donc le type de tes objets que l'héritage et les fonctions virtuelles n'ont pas d'intérêt : tu peux être amené à manipuler des objets par leur classe de base et ils peuvent correspondre à des instances de classes dérivées différentes.
Le polymorphisme d'inclusion a beau s'appuyer sur les pointeurs ou les références, cela ne doit pas forcément passer par de l'allocation dynamique.

Et même ce n'est pas tout à fait vrai que tous les objets sont connus au départ. Il y a des projets où certaines parties du code peuvent être reflashée et donc mise à jour indépendamment d'autres parties, et là, l'héritage tu en as sacrément besoin pour respecter le principe ouvert/fermé.

Citation Envoyé par méphistopheles Voir le message
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é.
Comme le dit Loïc, le RAII ça ne sert pas qu'à la gestion mémoire. Exemple : les mutex n'utilisent pas d'allocation dynamique mais ton code gagnera grandement à utiliser une enveloppe RAII pour le lock.

Attention cependant aux compilateurs C++ qui ne sont que des compilateurs d'Embedded C++
1  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 10/08/2010 à 8:54
Citation Envoyé par ac_wingless Voir le message
Il y a encore certaines idées reçues qui trainent... (les exceptions C++ "mal comprises" par les programmeurs embarqués... pardon ? S'il y a vraiment un truc que les programmeurs embarqués comprennent fondamentalement avec leurs tripes, c'est bien le traitement robuste de tout type de situation exceptionnelle, qu'elle soit C++, matérielle, asynchrone, velue, ou verte à pois rouges...).
Salut,
Je crois qu'il y a 2 choses distinctes : la nécessité d'une robustesse 'à toutes épreuves' et le transport d'erreur par exceptions pour son traitement au niveau approprié. Et c'est là où je disais que les exceptions au sens C++ sont souvent mal comprises. Le rejet des exceptions pour cause de surcoût en termes de code, je comprend et j'adhère. En revanche, j'ai vu souvent le rejet des exceptions pour des raisons plus fumeuses qui me semblaient traduire plutôt une mauvaise compréhension de leur rôle et de leur fonctionnement. Ce qui aboutit souvent au final à de fausses robustesses.
Ceci dit, si tu as eu la chance de bosser sur des projets embarqués avec une équipe ayant une bonne compréhension du C++ alors c'est un signe de mutation encourageant.
1  0 
Avatar de méphistopheles
Membre éprouvé https://www.developpez.com
Le 04/08/2010 à 15:03
Citation Envoyé par poukill Voir le message
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.

Citation Envoyé par poukill Voir le message
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.
0  0 
Avatar de méphistopheles
Membre éprouvé https://www.developpez.com
Le 05/08/2010 à 11:12
Citation Envoyé par 3DArchi Voir le message
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++...
Citation Envoyé par 3DArchi Voir le message
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
Citation Envoyé par 3DArchi Voir le message
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 ...

Citation Envoyé par 3DArchi Voir le message
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
0  0 
Avatar de poukill
Membre chevronné https://www.developpez.com
Le 05/08/2010 à 11:34
Citation Envoyé par méphistopheles Voir le message
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.

Citation Envoyé par 3DArchi Voir le message
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 ?
0  0