Discussion :

[screetch]

il me semblait qu'il y avait aussi des normes pour les compilateurs eux-mêmes, a savoir qu'ils doivent être certifiés générer un code correct (c'est-à-dire qu'il n'y a aucune perte dans la traduction code=> langage machine). Mon prof avait dit a l'époque que seul un compilateur ADA avait été certifié, en raison de la complexité de la certification. C'est vrai que les compilateurs C/C++ ont parfois des bugs de génération de code. Est-ce toujours vrai?

[jabbounet]

il me semblait qu'il y avait aussi des normes pour les compilateurs eux-mêmes, a savoir qu'ils doivent être certifiés générer un code correct (c'est-à-dire qu'il n'y a aucune perte dans la traduction code=> langage machine). Mon prof avait dit a l'époque que seul un compilateur ADA avait été certifié, en raison de la complexité de la certification. C'est vrai que les compilateurs C/C++ ont parfois des bugs de génération de code. Est-ce toujours vrai?

Je parle d'une époque assez ancienne dans ma carrière (il y'a 8 ans environ), et à l'époque toutes les parties lié à la sureté de fonctionnement était effectivement en ADA.
Cela a visiblement changé depuis mais je pense que le code est généré par un outils de modélisation:
http://www.ghs.com/products/industrial_safety.html

Tous les logiciels ont des bugs que ce soit des compilateurs/OS/.... Leur faire passer une certification te donne un niveau confiance supplémentaire et une garantie non négligeable quand à son comportement. malgré tout, une défaillance est toujours possible.

Passer une certification coute cher, donc l'éditeur d'un compilateur fera cette démarche uniquement s'il compte attaquer le marché de la sureté de fonctionnement, ce marché reste petit par rapport au reste du monde informatique, donc il y'a peu de place.

Dans ce domaine le matériel aussi doit être certifié comme les processeurs, les cartes, les capteurs, ...

[ptyxs]

Pour en revenir au sujet de base, je signalerais aussi pour ceux qui sont intéressés par l'utilisation de C++ en embarqué, l'ouvrage :

Effective C++ in an embedded environnment, de Scott Meyers

[Arzar]

Excellent, je ne savais pas du tout que Scott Meyers s'était intéressé au monde de l'embarqué.
Merci pour l'info ptyxs !

[poukill]

Excellent ! Je vais commander de ce pas !
Je l'ai pas trouvé sur amazon, mais je vais chercher ailleurs !

[poukill]

Eh ben, j'ai cherché partout, je ne trouve qu'une version PDF de dispo...
Quelqu'un a trouvé la version livre ?

[3DArchi]

Eh ben, j'ai cherché partout, je ne trouve qu'une version PDF de dispo...
Quelqu'un a trouvé la version livre ?

De ce que j'ai compris il ne s'agit pas d'un livre mais d'un PDF avec lié à une formation qu'il donne sur ce sujet. Bref, un PDF avec les slides de sa conférence à 25$

[Aleph69]

Bonjour,

De ce que j'ai compris il ne s'agit pas d'un livre mais d'un PDF avec lié à une formation qu'il donne sur ce sujet. Bref, un PDF avec les slides de sa conférence à 25$

Les 32 premiers slides dans ce pdf : http://www.artima.com/samples/effCppEmbNotesSample.pdf

En plus de cette généreuse initiative, l'éditeur précise :

You'll get not only the slides Scott shows in class, you'll also get the accompanying notes—the very ones Scott uses.

Vous n'en revenez pas? Alors accrochez-vous bien :

You may copy the PDF to as many devices as you like, annotate it in any way you want, print it in part or in full as many times as you choose.

C'est beau, non?
Si quelqu'un est intéressé, j'ai aussi des présentations powerpoint à vendre!

[James_]

tu as le beagle board standard qui est beaucoup moins puissant...

sinon regarde ce que fait
gumstix
muvium
fox board
ATMega

des cartes sur arm, ppc.... tu en trouves des milliers

tel que déjà dit, un système embarqué de nos jours ne veut plus dire grand chose....

tu peux trouver des systèmes à 40Mhz avec 8K de ram..... et d'autre qui sont dual core à 1.5Ghz avec 2 gig de ram....

tu peux en trouver qui gère le c, d'autre le c++, java, basic...

Oui mais en principe un système embarqué doit tenir compte de la consommation (suivre la mode du développement durable) et ces cartes là consomment quand même beaucoup.
Pour ma part, s'il n'y a pas d'OS et qu'on a besoin de performance et optimisation autant utiliser le C, le développeur "contrôle" mieux le code.

[James_]

il me semblait qu'il y avait aussi des normes pour les compilateurs eux-mêmes, a savoir qu'ils doivent être certifiés générer un code correct (c'est-à-dire qu'il n'y a aucune perte dans la traduction code=> langage machine). Mon prof avait dit a l'époque que seul un compilateur ADA avait été certifié, en raison de la complexité de la certification. C'est vrai que les compilateurs C/C++ ont parfois des bugs de génération de code. Est-ce toujours vrai?

Carrément et ce n'est pas limité qu'aux compilateurs C et C++. Je développe également sur LabVIEW 2010 (entre autre) et je peux vous dire que les bugs de compilations... il y en a pas mal!

[poukill]

De ce que j'ai compris il ne s'agit pas d'un livre mais d'un PDF avec lié à une formation qu'il donne sur ce sujet. Bref, un PDF avec les slides de sa conférence à 25$

Bonjour,
C'est beau, non?
Si quelqu'un est intéressé, j'ai aussi des présentations powerpoint à vendre!

Ouais, c'est abusé...
Des slides sans orateur, ça vaut 0 rouble.

[JolyLoic]

J'ai lu la partie accessible, et franchement... Je n'ai rien vu de ce à quoi je m'attendrais. Revenir pour la n-ième fois sur le coût d'un appel virtuel (même pas vraiment comparé au coût d'un if, qui n'est pas étudié...), je trouve ça plus orienté "le C++ vendu aux aficionados du C" que "Le C++ et l'embarqué".


Le reste de la présentation a l'air plus intéressant, mais je ne comprends pas trop pourquoi il a choisi ainsi cet extrait.

[ptyxs]

Sur l'adoption de C++ par Lockheed pour ses avions de combat :

F-35 Joint Strike Fighter (JSF)

et sur les normes de codage C++ adoptés par Lockheed (et apparemment rédigées par Stroustrup, voir plus haut) :

Joint Strike Fighter Air Vehicles C++ Coding Standards

[Davidbrcz]

Sur l'adoption de C++ par Lockheed pour ses avions de combat :

F-35 Joint Strike Fighter (JSF)

et sur les normes de codage C++ adoptés par Lockheed (et apparemment rédigées par Stroustrup, voir plus haut) :

Joint Strike Fighter Air Vehicles C++ Coding Standards

Extrèmement intéréssant, tu bosses dans ce milieu pour connaitre ce genre de chose ?

Edit: je viens de voir un de tes messages dans ce topic, je comprends mieux.

[poukill]

Très intéressant en effet. On y retrouve beaucoup de principes bien connus traités dans la bonne littérature Meyers, Alexandrescu, ...
Les template sont encouragés, mais pas un mot sur la STL ou Boost, alors qu'il parle de réutilisabilité de composants éprouvés !

[jabbounet]

Très intéressant en effet. On y retrouve beaucoup de principes bien connus traités dans la bonne littérature Meyers, Alexandrescu, ...
Les template sont encouragés, mais pas un mot sur la STL ou Boost, alors qu'il parle de réutilisabilité de composants éprouvés !

boost et STL sont peu être "éprouvé" pour une utilisation standard, mais ils n'ont peu être pas encore passé les certifications requise pour l'embarqué ....

Il faut savoir que dès que tu parle "sureté de fonctionnement" les technologies ont toujours un temps de retard du aux validations de ces dernières composant/libraries/compilateurs, cela prend parfois plusieurs années/h à certifier quelque chose.

[poukill]

Je comprends. Mais si je me trouve dans le cas où j'ai besoin d'une liste doublement chainée. Je fais quoi ? Je code ma classe comme un grand, ou bien j'utilise std::list ?
C'est pas que je me fasse pas confiance, mais j'aurais espéré pouvoir décemment choisir la deuxième solution !

[jabbounet]

Je comprends. Mais si je me trouve dans le cas où j'ai besoin d'une liste doublement chainée. Je fais quoi ? Je code ma classe comme un grand, ou bien j'utilise std::list ?
C'est pas que je me fasse pas confiance, mais j'aurais espéré pouvoir décemment choisir la deuxième solution !

De mémoire si quelque chose n'est pas certifié pour être dans les parties critique tu ne peux pas l'utiliser dans les parties critiques.

Si std::list n'est pas certifié pour être dans les parties critiques alors tu ne peux pas l'utiliser dans les parties critiques. Donc soit tu as de la chance et tu prend le modele de liste déjà implémenté en interne par ta société et qui a passé la certification, soit tu en fait une à la main.

Ce milieu es un mode très restrictif. Tout ce qui n'a pas été autorisé explicitement est interdit.

[Klaim]

J'imagine que ce sont les interfaces ET les implémentations des libs qui doivent être certifiées?

[3DArchi]

De mémoire si quelque chose n'est pas certifié pour être dans les parties critique tu ne peux pas l'utiliser dans les parties critiques.

Si std::list n'est pas certifié pour être dans les parties critiques alors tu ne peux pas l'utiliser dans les parties critiques. Donc soit tu as de la chance et tu prend le modele de liste déjà implémenté en interne par ta société et qui a passé la certification, soit tu en fait une à la main.

Ce milieu es un mode très restrictif. Tout ce qui n'a pas été autorisé explicitement est interdit.

Ceci dit, tout l'embarqué ne relève pas de la sureté de fonctionnement. Le code de commande d'un volet électrique n'a pas les mêmes contraintes que celui d'un équipement ferroviaire ou avionique (et même dans ces domaines, tous les équipements ne tombent pas sous la sureté de fonctionnement).
Il y a aussi des règles MISRA C++ qui concernent plus le monde de l'automobile.