Discussion :

[koala01]

Salut,

Si je me souviens : Le C++ n' est qu' une forme de syntaxisme qui crée un mode de vision (objet) et donc qui signale les dérappagent par des règles de compilation qui seraient plutot des règle de précompilation.

Conclusion : Il s'gait d'un concensus ... pour justement pouvoir partager entre développeur ... Et je n'ai jamais connu cette phase ...

Justement, le gros de la puissance du C++ ne vient pas du paradigme objet, mais bel et bien du fait qu'il permet de combiner à notre guise trois paradigmes pourtant considérés comme particulièrement distincts (ce qui est normal, vu qu'un paradigme est considéré comme un rail dont il est dangereux de s'écarter, cf la définition donnée par wikipedia).

Mais, comme l'orienté objet est déjà mal compris à la base (non : le principe fondamentale de l'OO, ce n'est pas l'encapsulation comme beaucoup de vieux le pensent encore, mais bel et bien la substituabilité au termes du respect du LSP; qui est souvent très mal compris lui aussi d'ailleurs) et que les langages qui "ont le vent en poupe" (ou qui l'on eu... allez savoir) on tapé sur le clou OO au point que certains ont l'impression qu'ils ne peuvent plus faire que cela sans se prendre une mandale, je peux personnellement comprendre que certains "affisionados" du procédural hésitent très sérieusement avant de se lancer dans l'étude d'un langage qui passe encore trop souvent pour être "orienté objets".

Alors, oui, bien sur, il y a la forme canonique orthodoxe de Coplien ou la règle des trois grands (qui est devenue la règle des cinq grands depuis l'apparition de la sémantique de mouvement) qui nous incitent à appliquer le RAII, la dualité entre la sémantique d'entité et la sémantique de valeur qui gagne vraiment à être prise en compte (j'irais meme jusqu'à dire : qu'il est criminel de ne pas prendre en compte), et oui, tout cela, ce sont des concepts OO auxquels on a tendance à être très attaché.

Mais le fait est que ce sont justement ces concepts (qui pourraient très bien être adaptés en C, du moins dans une certaine mesure) qui nous permettent d'obtenir des choses "sécurisantes" à l'utilisation, sans souffrir de pertes de performances et qui permettent au compilateur de constater de nombreuses erreurs impossible à détecter en C.

Mais il ne faut pas oublier que C est un langage particulièrement laxiste, car il nous permet de transtyper strictement n'importe quoi en n'importe quoi d'autre sans tirer la moindre sonnette d'alarme et ce, même s'il n'est simplement pas opportun de permettre le transtypage en question.

Et l'on peut encore continuer à énumérer les faiblesses du C, avec la possibilité qu'il donne de fournir "n'importe quel nombre de paramètre" à une fonction, sans nous donner réellement les moyens de nous assurer qu'ils sont "en nombre suffisant" et du type adéquat ou qu'il nous permet d'ignorer purement et simplement un retour de fonction ou, à contrario, que si l'on veut garantir la sécurité de tous les chemins d'exécution potentiels, on est rapidement parti pour gérer une quantité de tests et de valeurs différentes propres à donner le tourni à un dervishe tourneur!

J'ai lu à peu près toutes les interventions depuis que le fil a été ouvert. Et beaucoup de pro C (anti C++) ne se plaignent finalement que d'une seule et unique fonctionnalité : la possibilité de pratiquer un héritage public. Or, c'est une des fonctionnalités dont on peut sans doute se passer le plus facilement en C++. Et n'allez pas croire que la présence d'un constructeur, d'un constructeur de copie, d'un opérateur d'affectation et d'un destructeur soit faite pour vous embêter!!! Bien au contraire, ce sont les fonctionnalités qui vous permettent de garantir à peu de frais que n'importe quel objet est dans un état valide dés sa création, et qu'il le reste jusqu'à ce qu'il sera détruit.

Après, si vous tenez à refuser toute fonction membre autre que ces quatre là (il faudrait encore m'expliquer pourquoi, car une fonction membre n'est jamais que l'équivalent d'une fonction libre à laquelle on dont implicitement un pointeur sur la donnée courante), libre à vous de le faire... Avec la facilité (entre autre) de pouvoir profiter de la surcharge de fonctions, de la prise de décision (et d'une très forte capacité à reprérer les incohérences) à la compilation, j'en passe, et de meilleures!

[CodeurPlusPlus]

C'est souvent ce que font les personnes qui n'ont jamais pris le temps d'apprendre le C++ correctement oui.
Quand tu as compris la puissance du langage, et ce qu'il apporte en terme de généricité, safety, efficacité.... Tu ne reviens pas en arrière.

La plupart des programmeurs C arguent que la première faiblesse du C++, c'est sa complexité. C'est faux, et c'est déjà prouver qu'ils ne comprennent pas le C++.

C'est ça. Je n'ai pas compris C++. Tu me prends pour un con ? La prétendue complexité de C++, c'est de la pisse.

Aujourd'hui quand je vois des personnes qui pondent des cathédrales en C, impossible à maintenir, bourrées d'overflow, et de memory leaks, (...)

Ceux-là tu peux vraiment les insulter en revanche... c'est quand même pas compliqué de s'assurer qu'un programme C n'a pas de fuite de mémoire.

[mister3957]

C'est toujours pénible ces débats entre C et C++, bloqués sur les subtilités du code. Le code, toujours le code...

Les paradigmes sont différents et par conséquent c'est pas le code qui effraye les uns ou les autres, mais la méthodologie, la manière de construire qui est totalement différente d'un langage à l'autre ce qui fait deux langages totalement différents à commencer par le plan organisationnel et donc intellectuel.

Convertir les développeurs C en développeur C++ c'est une hérésie, tout comme le serait le souhait de convertir les développeurs C++ en développeur C, dans la mesure où on est là sur deux technos qui demandent beaucoup de temps et beaucoup de connaissances pour les maîtriser afin de construire de manière optimale tant à niveau structurel qu'à niveau performances.

Alors changer, perdre ses repères qui ont pris des années à acquérir et qui vont prendre des années à muter avec un retour à la "case départ, comme un junior" en prime, c'est donné à trop peu de gens et je n'en fais clairement pas parti (je sais faire du C juste pour faire, pas pour construire, tout comme j'ai des collègues qui font du C depuis 35 ans et qui voient du code C++ telle une poule devant un œuf).

Les arguments concernant les fuites de mémoire, les performances, les stack overflows etc. importent peu, c'est pas le langage qui crée ça, mais celui qui le parle, donc autant jouer à celui qui pisse le plus loin sur ce terrain là.

J'ai tendance à croire que le C permet de mieux appréhender différents contextes, principalement celui de l'embarqués, que le C++, mais je reste sans arguments concrets à ce niveau là, pourtant je taf dans l'embarqué depuis 3 ans.

Ha si une fois, pour contrôler une machine vieille de 15 ans, plus supportée mais toujours utilisée dont le fournisseur ne fournissait pas de compilo C++, uniquement du C. Quoi que.. c'était de l'ARM, y'a moyen de s'en sortir avec une toolchain ARM..

[Vincent PETIT]

C'est toujours pénible ces débats entre C et C++, bloqués sur les subtilités du code. Le code, toujours le code...

Oui c'est dommage que cela parte dans cette direction car ce ne sont pas les mêmes langages, même si la syntaxe est semblable.
Mais initialement, le sujet était de savoir pourquoi le C++ n'arrive pas a percer dans l'embarqué.

Je vais donner un autre exemple et avec un autre microcontrôleur Cette fois ci c'est avec un MSP430 (micro 16 bits) et le compilateur MSP430-GCC.

Voici comment se faire avoir comme un bleu :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
int i;
 
interrupt (TIMERA0_VECTOR) irq_routine(void) // a chaque débordement du TIMERA, toutes les secondes par exemple 
{
    i = 42; // la variable globale i vaut 42
}
 
void func(void) // fonction "attendre" qui est appelée par le programme principal, peu importe quand 
{
    i = 0; // on met i à 0
    while (i == 0);  // on boucle indéfiniment tant que i est à 0
}

Pour l'explication, rapidement, ici dans ce code nous sommes au niveau +1. C'est à dire que le niveau 0, si je puis dire, est déjà codé et il correspond à la configuration des registres avec des instructions du genre TIMERA = 0xFF; WDTCTL = WDTPW + WDTHOLD; autrement dit on ne peut comprendre ça qu'avec la doc constructeur devant les yeux puisqu'on ne peut pas deviner l'utilité de chaque bit. Le vrai bare metal sous le programme en C pour vulgariser.

On peut comparer cet extrait de programme à la naissance d'un Thread. Toutes les secondes une interruption apparaît, toute l'exécution courante est empilée, le code dans la routine de l'interruption s'exécute, puis on dépile tout pour revenir à l'exécution avant l'interruption. Ce qui veut dire que même lorsqu'on est bloqué dans le while de la fonction "func" et bien toute les secondes la variable "i" vaudra 42. C'est tout ce qu'il y a à savoir.

Et voilà le problème

1. Lorsque la fonction "func" sera appelée, "i" va être mis dans un registre de travail pour manipulation, donc ce registre sera mis à 0 puis testé avec la valeur 0 dans une boucle.
   
   
2. Puis le TIMERA va déborder et la routine d'interruption va s'exécuter en stoppant tout (on empile), l'emplacement mémoire de "i" va valoir 42.
   
   
3. Enfin, on sort de l'interruption (on dépile), on retourne dans le code de la fonction "func" et le registre de travail qui valait 0, avant, et qui est testé avec la valeur 0 n'a aucune raison de se mettre à jour avec la nouvelle valeur de "i" ! Soit la valeur 42 !

C'est la boucle infinie.


Pire encore !
Si jamais les options d'optimisation sont activées alors GCC va voir tout de suite une comparaison avec la valeur 0 et un registre qui est mis a 0 .... et il risque de retirer la condition qui pour lui ne sert strictement a rien et c'est vrai puisqu'on test 0 avec 0. Bref ce problème se règle facilement avec le mot clé volatile qui va forcer le compilateur générer du code supplémentaire pour aller vérifier l'emplacement mémoire de la variable "i" à chaque vérification ou manipulation.

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

volatile int i;

Ce que je veux dire ?
C'est que dans la plus grande majorité des programmes embarqués on est amené a faire attention a des trucs comme ça. On est amené a faire des structures switch/case car le code assembleur généré est bien plus performant qu'avec des conditions if/else, on va utiliser de préférence un OU logique plutôt que de faire des "+" pour faire des masques. Les options de compilations détectent les temps morts (boucle de temporisations) et les éliminent. Et j'en passe et des meilleurs.

Et comme je le disais dans un précédent poste, comme il n'y a pas d'OS, il n'y a pas d'exception, pas de notion de thread, souvent pas assez de place pour de la POO, pas de STL, pas de memory management et toute allocation dynamique de mémoire ne fait que déplacer le pointeur de pile (pour l'augmenter/diminuer) mais rien ne vous assure que vous n'êtes pas entrain d'écrabouiller autre chose pas de "segment fault" non plus. Je ne vois pas comment utiliser une quelconque notion d'abstraction ? Si part exemple le TIMERA de l'exemple déborde toutes les 10µs alors peut être que dans cette partie du programme vous serez en assembleur pour que le code s'exécute en moins de 10µs. Pour l'histoire du mot clé volatile on ne peut même pas le rendre générique car il génère du code supplémentaire. En clair on se méfie du compilateur pour certaine chose. On est pas sur les problématiques que le C++ règlent.

Je suis convaincu que le langage C++ est supérieur, et de loin, au C mais pas dans la grande majorité des systèmes embarqués (donc les micro petits/moyens et sans OS) je ne vois pas ce qu'il apportera de plus si ce n'est de la lourdeur et de la complexité.

Ou bien je me goure complètement comme la grande majorité des développeurs qui restent sur C !?

[nikko34]

Ou bien je me goure complètement comme la grande majorité des développeurs qui restent sur C !?

Ben tu as regardé comment on peut utiliser le C++ pour l'embarqué (voir les post plus haut?). Notamment sur la précompilation.

Perso je me sers des classes pour représenter des objets physiques branchés à mon micro-controleur. Mais peut-être que tu fais la même chose avec des structs. J'essaye de mettre tout le code pour un même élement dans un même fichier, et d'appeller des méthodes (genre euh door.open() ) depuis la partie principale du programme.

[Vincent PETIT]

Ben tu as regardé comment on peut utiliser le C++ pour l'embarqué (voir les post plus haut?). Notamment sur la précompilation.

Perso je me sers des classes pour représenter des objets physiques branchés à mon micro-controleur. Mais peut-être que tu fais la même chose avec des structs. J'essaye de mettre tout le code pour un même élement dans un même fichier, et d'appeller des méthodes (genre euh door.open() ) depuis la partie principale du programme.

Si si j'ai vu mais dit moi, sur quel microcontrôleur tu travailles ?
Est ce que tu as un bout concret de code (j'ai bossé sur beaucoup de micro et je devrais m'y retrouver) surtout sur les couches (très) basses ? Il me faut aussi la ref du micro pour regarder la datasheet.

Merci

[Bousk]

Je ne vois toujours rien qui fasse que le C soit tant idôlatré
Préférer les switch/case aux if/else c'est une optimisation triviale qui... oui oui est aussi présente et utilisée en C++ (d'ailleurs remplacer des comparaisons de chaînes par un switch/case et l'utilisation de constexpr est énorme)
Idem pour tout le reste de ton exemple.
En fait ton code, au mot-clé interrupt (TIMERA0_VECTOR) qui n'apporte rien à ton exemple, pourrait très bien utiliser dans un programme QT, une appli console ou n'importe quoi gérant des threads écrit par un débutant ne sachant pas ce que peut faire le compilateur - et oui ça s'apprend tout comme le langage -, il n'est absolument pas lié à l'utilisation d'un quelconque microcontroleur ou que sais-je d'embarqué

[Vincent PETIT]

Je ne vois toujours rien qui fasse que le C soit tant idôlatré

Tout comme moi qui ne voit pas en quoi il y a un avantage a passer au C++ (sur un microcontrôleur uniquement)

Préférer les switch/case aux if/else c'est une optimisation triviale qui... oui oui est aussi présente et utilisée en C++ (d'ailleurs remplacer des comparaisons de chaînes par un switch/case et l'utilisation de constexpr est énorme)

Oui et justement, où est l'intérêt de prendre un tel langage qui permet de la programmation générique, un niveau d'abstraction supérieur et plein d'autres choses, si c'est pour aller faire ce genre de bidouille d'optimisation dans le programme ?

Idem pour tout le reste de ton exemple.
En fait ton code, au mot-clé interrupt (TIMERA0_VECTOR) qui n'apporte rien à ton exemple, pourrait très bien utiliser dans un programme QT, une appli console ou n'importe quoi gérant des threads écrit par un débutant ne sachant pas ce que peut faire le compilateur - et oui ça s'apprend tout comme le langage -, il n'est absolument pas lié à l'utilisation d'un quelconque microcontroleur ou que sais-je d'embarqué

Je ne comprends pas ce que tu as voulu me dire mais je vais m'expliquer autrement.
Mon exemple montre que sur un microcontrôleur sans OS, il te faut parfois une "loupe" pour aller chercher et faire un zoom ce qui ne fonctionne pas. Mon exemple le montre bien car d'un point de vu conception purement informatique, il n'y a pas de piège, on peut se dire que tout fonctionne, que c'est du soft et qu'accessoirement on peut même faire ça dans n'importe quel langage et pourtant il y a un bug ! Depuis le début, certain dise que le but du C++ est d'apporter plus d'informations et de généricité pour que le compilateur fasse un boulot de qualité => code plus efficace. Hors mon exemple montre bien que le compilateur peut aussi faire des catastrophes justement car ce n'est pas générique.

Pour ce qui est des threads, ils ne sont absolument pas comparable a une interruption sur un micro même si ça y ressemble. A moins que je ne me trompe un mais un thread a sa propre pile d'appel (si dedans on a des fonctions) et l'OS veille aussi au débordement des processus sur les autres. Pardonnez moi la comparaison mais un thread est une interruption avec des roulettes. Sur un micro y a pas ce memory management qui fait que sur un PC, tu n'as pas vraiment a te soucier de ce que ton compilateur fait.

[foetus]

A moins que je ne me trompe un mais un thread a sa propre pile d'appel (si dedans on a des fonctions) et l'OS veille aussi au débordement des processus sur les autres

Cours système: un fil d'exécution ("thread") est un processus qui partage la mémoire avec les autres fils ("threads")

[Bktero]

Oui et justement, où est l'intérêt de prendre un tel langage qui permet de la programmation générique, un niveau d'abstraction supérieur et plein d'autres choses, si c'est pour aller faire ce genre de bidouille d'optimisation dans le programme ?

Je repose la question qu'on t'as déjà posé : t'as regardé les vidéos postées précédemment ? Tu as répondu "si si" et tu as vite changé de sujet alors j'insiste. Notamment, as-tu regardé la vidéo sur le Commodore64 ? C'est assez fou ! J'en ai regardé 45 minutes ce matin et vivement demain matin pour regarder la suite ! (oui le matin, de 7h30 à 8h30, c'est mon instant vidéo depuis quelques jours ).

[Matt_Houston]

Cours système: un fil d'exécution ("thread") est un processus qui partage la mémoire avec les autres fils ("threads")

Le tas est partagé oui, mais chaque thread dispose de sa propre pile.

[Vincent PETIT]

Cours système: un fil d'exécution ("thread") est un processus qui partage la mémoire avec les autres fils ("threads")

En effet les thread se partage la même mémoire virtuelle que le processus au quel ils appartiennent.

Mais...

A moins que je ne me trompe un mais un thread a sa propre pile d'appel (si dedans on a des fonctions) et l'OS veille aussi au débordement des processus sur les autres

Wikipédia, même si ce n'est pas un référence, semble d'accord avec moi.

On peut remarquer la présence des mots mémoires virtuelles, processus, ... lorsqu'on parle de thread sur PC mais tout ça sur un micro n'est pas absolument pas implémenté ou alors il faut que tu le fasses (ou mettre un OS)

[Bousk]

Oui et justement, où est l'intérêt de prendre un tel langage qui permet de la programmation générique, un niveau d'abstraction supérieur et plein d'autres choses, si c'est pour aller faire ce genre de bidouille d'optimisation dans le programme ?

Ben comment tu remplaces l'utilisation de constexpr en C par exemple ?
Tu peux pas, tu devrais ajouter une étape avant de commencer à compiler. Donc quelque chose de plus à maintenir, là où constexpr te permet d'utiliser un même code à toutes les étapes de compilation.
Et tips : t'es pas obligé d'utiliser tous les mot-clés du langage dans ton programme, permettre de la programmation générique et un niveau d'abstraction supérieur c'est mignon, mais tu as le droit de ne pas en utiliser (sisi j'te jure).

...

Ce que je veux dire c'est que ton exemple ne montre rien de plus qu'une mauvaise utilisation de compréhension du système de thread ou interruption ou n'importe quoi qui tourne en parallèle et ne comprend pas comment fonctionne la mémoire et le compilateur.
Et les optimisations et fix de ce genre ne sont pas propres à l'utilisation d'un microcontroleur contrairement à ce que tu sembles croire.

Sur un micro y a pas ce memory management qui fait que sur un PC, tu n'as pas vraiment a te soucier de ce que ton compilateur fait.

Oui tu es libre de noyer ton PC en ne désallouant jamais la mémoire, jusqu'à ce que ton programme plante parce qu'une allocation échoue.
Là encore, en quoi ça montre un intérêt quelconque à utiliser du C ? Scoop : t'auras le même résultat avec un programme en C.

[Vincent PETIT]

Je repose la question qu'on t'as déjà posé : t'as regardé les vidéos postées précédemment ? Tu as répondu "si si" et tu as vite changé de sujet alors j'insiste.

Si si j'ai vu [...]

Je pensais que nikko34 faisait référence aux codes postés plus haut et ma question portait sur la taille des micro avec les quels ils bossent en C++.
Car depuis le début je dis que le C++ est la solution une fois qu'on fait de l'embarqué sur un OS car ce dernier apporte la couche générique sur laquelle on peut s'appuyer (le compilateur peut faire ce qu'il veut et on peut faire confiance en son optimisation, on peut faire de la programmation générique et être efficace et plus qu'en C !)

Mais pour moi cela représente la minorité des systèmes embarqués (la majorité étant les petits/moyens micro sans aucun OS)

Notamment, as-tu regardé la vidéo sur le Commodore64 ? [...]

Non j'ai regardé les autres ! Mais je vais le faire.

Et si je suis convaincu de m'être trompé depuis le début alors je reviendrai le dire sans aucun complexe

[Vincent PETIT]

@Bousk,
Je crois qu'on ne se comprend car tu pars du principe ou il n'y a pas de différence entre faire du soft (les outils, les pratiques) sur des PC équipés d'OS et sur un microcontrôleur.
La notion de maintien du code par exemple, dit moi combien de fois tu as mis à jour le microcontrôleur de ton calculateur de voiture ? Celui dans ta chaudière ? Dans des jouets, dans les machines a laver et dans tous ceux qui t'entoure et qui sont dans les appareils électroniques de ton quotidien ? Probablement jamais. Parce que ce que tu entends par "maintenir le code" n'existe pas pour 95% des systèmes embarqués (c'est à dire tous les petits/moyens micro) en revanche pour les 5% restants, les gros micro équipant les BOX internet, les smartphones etc... cela oui puisqu'on est sur du embarqué de haut niveau (du même niveau que sur un PC)

Ben comment tu remplaces l'utilisation de constexpr en C par exemple ?
Tu peux pas, tu devrais ajouter une étape avant de commencer à compiler. Donc quelque chose de plus à maintenir, là où constexpr te permet d'utiliser un même code à toutes les étapes de compilation.

Tu as raison en C je ne peux pas faire de la précompilation et évaluer des fonctions car je n'ai pas constexpr.

Et tips : t'es pas obligé d'utiliser tous les mot-clés du langage dans ton programme, permettre de la programmation générique et un niveau d'abstraction supérieur c'est mignon, mais tu as le droit de ne pas en utiliser (sisi j'te jure).

Oui c'est vrai.

Ce que je veux dire c'est que ton exemple ne montre rien de plus qu'une mauvaise utilisation de compréhension du système de thread ou interruption ou n'importe quoi qui tourne en parallèle et ne comprend pas comment fonctionne la mémoire et le compilateur.

Mon exemple montre que dans le bas niveau il y a des pièges qui vont nécessiter de programmer de manière proche du matériel et que toute couche d'abstraction peut être plus problématique qu'autre chose.
Mais comme tu me l'as dit juste au dessus "le niveau d'abstraction c'est mignon et on peut s'en passer".

Et les optimisations et fix de ce genre ne sont pas propres à l'utilisation d'un microcontroleur contrairement à ce que tu sembles croire.

Je n'ai pas dit le contraire.

Oui tu es libre de noyer ton PC en ne désallouant jamais la mémoire, jusqu'à ce que ton programme plante parce qu'une allocation échoue.
Là encore, en quoi ça montre un intérêt quelconque à utiliser du C ? Scoop : t'auras le même résultat avec un programme en C.

Les notions de constructeurs/destructeurs d'objets lorsqu'on a pas d'OS sont quand même bien plus délicates car toutes la mécanique habituelle sur PC n'est pas implémentée.

Donc, si la programmation générique, l'abstraction, la POO ne sont pas obligatoires en C++ pour faire de l'embarqué alors qu'est ce qui reste ? A part constexpr où j'y vois plusieurs intérêts.
Ce que je dis depuis le début c'est qu'il va être difficile de faire basculer vers le C++ 95% des développeurs qui n'en n'ont pas le réel besoin. Quant aux autres personnes qui développent de l'embarqué sur des OS oui eux c'est en C++ qu'il faut bosser ça je le pense vraiment.

[Bktero]

La notion de maintien du code par exemple, dit moi combien de fois tu as mis à jour le microcontrôleur [...] dans ta chaudière ?

Et ben justement mon bon monsieur, je bosse chez un grand fabricant de matériel de chauffage et je suis justement dans l'équipe qui fait et maintient les cartes des chaudières.

Et t'imagine même pas combien de soft on maintient !!! Les produits restent en vente des années et après la fin de la commercialisation, on doit fournir des pièces pendant 15 ans. T'as des produits à maintenir pendant des plombes, avec des changements de composants et donc des ajustements de code, des corrections de bugs, des ajouts de fonctionnalités. Alors OUI, le code d'une chaudière se met à jour ! Pas dans la tienne chez toi, mais celles qui sortent de l'usine, c'est le même modèle mais pas nécessairement le même code.

Les notions de constructeurs/destructeurs d'objets lorsqu'on a pas d'OS sont quand même bien plus délicates car toutes la mécanique habituelle sur PC n'est pas implémentée.

MAIS QUEL RAPPORT ? D'où un constructeur et un destructeur ont besoin d'un OS ? Désolé mais c'est n'importe quoi de dire ça...

[Vincent PETIT]

Et ben justement mon bon monsieur, je bosse chez un grand fabricant de matériel de chauffage et je suis justement dans l'équipe qui fait et maintient les cartes des chaudières.

Et t'imagine même pas combien de soft on maintient !!! Les produits restent en vente des années et après la fin de la commercialisation, on doit fournir des pièces pendant 15 ans. T'as des produits à maintenir pendant des plombes, avec des changements de composants et donc des ajustements de code, des corrections de bugs, des ajouts de fonctionnalités. Alors OUI, le code d'une chaudière se met à jour ! Pas dans la tienne chez toi, mais celles qui sortent de l'usine, c'est le même modèle mais pas nécessairement le même code.

Je me suis mal exprimé.... c'est vrai.... car moi aussi je maintenais du code mais juste lors de la production et ce n'était pas si souvent que ça (un client que veut un logo perso sur son écran à l'allumage, un réglage spécial nécessitant de créer un nouveau menu dans l'IHM, etc.) Je suis sur qu'entre un code maintenu dans le secteur d'activité de Bousk (ou dans le milieu de l'informatique) et du code embarqué sur des petits ou moyens microcontrôleurs, on est pas sur la même échelle de complexité. D'ailleurs Bktero, je ne serai pas surpris que tu sois entrain de parler de gros microcontrôleurs ARM.
Je voulais montrer que la programmation sur PC et sur micro sans OS est différente (sur le fond).

MAIS QUEL RAPPORT ? D'où un constructeur et un destructeur ont besoin d'un OS ? Désolé mais c'est n'importe quoi de dire ça...

hop, hop, hop.... me fait pas dire ce que je n'ai pas dit.

Alors à nouveau et si je ne me trompe pas (comme les thread qui avait bien leur propre pile d'appel tout en partageant la même mémoire virtuelle du processus), lorsque tu as un OS et que ton programme/processus fait de l'allocation dynamique, l'OS lui alloue un peu plus de mémoire et inversement il lui en retire lors de la destruction. Donc ça vie, ça bouge, ça s'ajuste bien comme il faut avec des mécanismes sous-jacents hyper performants. C'est ce j'ai appelé surement maladroitement le "Memory management".
Rassurez moi je ne dis pas de connerie là ?

Ce que j'écris ci dessous est fonction du fait que je me suis planté ou pas à la question du dessus
Je dis que c'est carrément plus délicat de faire de la construction et destruction d'objet car le mécanisme de la gestion de la mémoire n'existe pas (sauf a l'implémenté soi même). C'est une des raison pour la quelle on évite la POO sur les petits/moyens micro. Sur un micro, une fois que tu as compilé un programme, le compilateur a mis le pointeur de pile a une une certaine adresse mémoire (ou alors tu le fais toi même) et le reste de la mémoire restante c'est le tas. Et puis il n'y a plus rien qui bouge de manière dynamique.

Je n'ai pas dit que le langage C protégeait de ça !!!! Je dis que c'est une des raisons pour la quelle les langages objets ne nous aident pas plus que le C en embarqué (j'ai bien compris aussi que C++ est polyvalent et peu faire les deux)

[Bktero]

Et bien tu te trompes On va peut-être passer sur des Cortex-M0 pour des nouveaux produits et c'est la révolution ! Jamais fait aussi gros et de très loin ! On n'a même jamais fait de 32 bits. Les produits actuels utilisent des PIC 8 bits et beaucoup de Renesas 16 bits, par exemple.

Tu dis peut-être pas de connerie si on parle de PC mais si on parle de RTOS pour MCU, je pense que tu sais qu'ils ne savent pas faire tout ça

Un constructeur n'a pas besoin d'allocation dynamique. Il n'y a pas de mécanique compliquée derrière. Pour le prouver, copie ce code :

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
class ClassicDisplay
{
public:
    ClassicDisplay(unsigned int width, unsigned int height) :
            width_m(width), height_m(height_m)
    {}
 
    unsigned int width_m;
    unsigned int height_m;
};
 
int main()
{
    ClassicDisplay cd(320, 240);
    return cd.width_m + cd.height_m;
}

Tu vas sur Compiler Explorer, tu colles le code et tu regardes l'assembleur.

Pour amusement, tu pourras le comparer à un code C équivalent :

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
struct ClassicDisplay
{
    unsigned int width_m;
    unsigned int height_m;
};
 
ClassicDisplay create_display(unsigned int w, unsigned int h)
{
  ClassicDisplay d = {w, h};
  return d;
}
 
int main()
{
    ClassicDisplay d = create_display(320, 240);
    return d.width_m + d.height_m;
}

EDIT : et si tu veux encore plus t'amuser, tu pourras regarder ce code utilisant un template :

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
template<unsigned int __width, unsigned int __height>
class TemplateDisplay
{
public:
    void draw()
    {
    }
 
    unsigned int width = __width;
    unsigned int height = __height;
};
 
int main()
{
    TemplateDisplay<320, 240> td;
    td.draw();
 
    return td.width + td.height;
}

Et un code C équivalent :

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
struct ClassicDisplay
{
    unsigned int width_m;
    unsigned int height_m;
};
 
void draw(ClassicDisplay* d)
{
}
 
int main()
{
    ClassicDisplay d = {320, 240};
    draw(&d);
 
    return d.width_m + d.height_m;
}

Ces deux derniers sources génèrent le même assembleur. Il ne reste donc plus qu'à comparer le style des sources pour savoir ce qu'on a envie de faire : du C ou des templates C++. Le coût est le même

[bacelar]

Rassurez moi je ne dis pas de connerie là ?

Si, un peu, mais c'est pas trop grave.
Le truc qui manage la mémoire, c'est très variable en fonction des compilateurs et des OS.

Par exemple, sous Windows, c'est la C-Runtime qui gère les allocations C, donc aussi C++, en fin de chaine.
Et sous Windows, la C-Runtime ne fait pas partie de l'OS et on peut livrer sa version, qui fait ce qu'elle veut, ou peut, pour minimiser l'usage mémoire et ou sa performance.

J'ai vraiment l'impression de voir les mêmes arguments des programmeurs assembleurs versus les programmeurs C, dans ma prime-jeunesse.
Mais ici, c'est programmeurs C versus les programmeurs C++.

Pour savoir si l'on en a besoin, bin, faut connaitre. Si on ne connait pas, oui, on ne voit pas l'intérêt.

Mais est-ce que les avantages du C++ mérite de passer du C au C++, ça c'est du ressort des programmeurs C, qui connaissent leurs besoins.

Mais c'est pas une raison pour dire d'énormes inepties sur le C++, OK.

Pour le truc inverse, C++ vers C, moi, je ne connais que le VLA qui n'existe qu'en C et pas en C++. Clairement, c'est pas le genre de truc qui me fera choisir le C à la place du C++.

Je suis de la vieille école, Pascal, puis C, puis C++, puis Java, puis C#, etc.... J'ai du mal à comprendre pourquoi je ne serais pas performant en C, même si j'ai des réflexe de C++istes.
Les machines, les interruptions, les registres, les rings, les mapping mémoires, les stacks, les µ-codes, injection de code, pilotage d'hardware, etc..., c'est de l'informatique, et C++ ou C, c'est toujours la même chose.
Ok, en couche base, sur machines contraintes, les outils C++ sont pas forcément des outils de productivités super avantageux, mais est-ce un handicap sur le C, qui n'offre que les VLA ?

[Vincent PETIT]

Et bien tu te trompes On va peut-être passer sur des Cortex-M0 pour des nouveaux produits et c'est la révolution ! Jamais fait aussi gros et de très loin ! On n'a même jamais fait de 32 bits. Les produits actuels utilisent des PIC 8 bits et beaucoup de Renesas 16 bits, par exemple.

Arf ! Je croyais que c'était du ARM dont tu parlais.

Un constructeur n'a pas besoin d'allocation dynamique. Il n'y a pas de mécanique compliquée derrière.

Je ne le savais pas et je m'étais référé à la FAQ de chez nous http://cpp.developpez.com/faq/cpp/?p...n-constructeur pour quand même vérifier mes dires.

Super intéressant ton lien sur le compilateur GCC.

Si, un peu, mais c'est pas trop grave.

Merci pour l'explication !


Donc !
Je vais m'arrêter là dans cette discussion car certain m'ont mis un doute et d'autre m'ont un peu convaincu. Je vais essayé pour en avoir le cœur net !
Je vais essayer de faire, quand j'aurai le temps, un petit programme très bas niveau en C et en C++ (j'aurai surement besoin d'aide car je suis entrain de rafraichir mon Java avec un énorme bouquin et je m'aperçois que la transition C -> POO n'est pas si simple)