Discussion "parallèle hors sujet" : C vs. C++

[naru2to]

Bonsoir à tous

Cette discussion est créée à partir de "réponses" ici:

http://forums.futura-sciences.com/el...ml#post6113464

où il convient de laisser l'auteur achever son projet, qui sera ensuite déplacé vers la section des projets comme c'est l'usage.

Cette discussion est créée pour ne pas perturber le projet commencé, mais ne doit pas se transformer en pugilat.

Merci pour la compréhension de tous.



Bonjour,

Je trouve la présentation du projet intéressante et bien rédigée .

Concernant le C++ j'aurais une question/remarque : Ne perd-on pas la valeur ajoutée du C++ à cause de l'absence d'allocation dynamique de mémoire?
Je fais surtout de l'embarqué "bare metal" en C (STM32, PICs et MSP430) mais n'ai jamais sauté le pas du C++ car je n'y voyais pas l'intérêt pour mes projets à cause de l'impossibilité d'utiliser les allocations de mémoire justement.
-----

[abracadabra75]

Bonjour Murayama
Ce projet que je résume en une mesure d'angle serait-il transposable (évidemment tout ou presque est à réécrire) à des commandes de gouvernes (aéro)?
N'y aurait-il pas un inconvénient, un allongement du temps de réponse consécutif à un code plus volumineux?
Jusqu'à maintenant j'utilise l'assembleur, avec l'inconvénient de n'être pas transposable, ce qui est fort gênant lors d'un changement de matériel.
A+

[naru2to]

Bonjour Murayama!

En plus, quand le programmeur a un chef qui tourne en rond derrière sa
chaise en attendant que le code soit fini, ce n'est pas un contexte propice à se lancer.
J'ai la chance de ne plus être dans ce cas depuis longtemps.

J'ai aussi la chance de ne pas être dans ce cas, mais comme on fait de la prestation électronique pour les entreprises locales (pépinière d'entreprises) les clients préfèrent le C, et comme on a une bibliothèque de fonctions qui s'accroît régulièrement (surtout au niveau des périphériques et certains composants "standard" comme les EEPROM, etc) c'est vrai que repartir de presque zéro en C++ (ce qui n'est pas tout à fait vrai, on a eu droit à un bel exemple de concurrence des deux langages ) ça reste difficile en entreprise. C'est déjà assez compliqué de passer d'une famille de microcontrôleur à une autre constructeur.
Par contre dans le cadre de projets personnels, ça me paraît envisageable.

Quand on change de contexte, en général, il faut effacer tout l'écran (je parle
d'écrans dans le genre 128 x 64 ou 160 x 128). C'est le rôle de la classe de base, ce
qui fait que l'on est presque certain de ne jamais oublier.

Tiens, ce serait une idée. Montrer un menu manager, avec des boutons, des menus, des
config stockées en flash, etc....

Je vais suivre ça de près, j'ai un écran OLED 128 x 64 avec pour le moment un menu sous forme de machine à état, peut être qu'il sera temps de le faire évoluer

[Chtulhu]

Bonjour,

puis je
passerai petit à petit à un programme en C++, ce qui me permettra de rétablir les
contre-vérités suivantes:

- Mélanger C et C++ est dénaturé
Je vais vous montrer que cela fonctionne très bien ensemble
- C++ n'est pas portable et est en plus dépendant du processeur.
J'ai déjà dit récemment pourquoi c'est portable, voir ANSI C++.
- C++ ne peut pas travailler intimement avec le hardware
Je vais montrer que, au contraire, c'est prévu pour cela.
- C++ n'apporte strictement rien, C++ est une démarche inappropriée, etc,etc...
Je montrerai ce que cela apporte. Qu'on aime ou pas est une autre chose.

Vous polémiquez encore, concentrez vous sur votre "démonstration".
Pour l'instant vous ne démontrez rien.
Et notamment le portage vers une cible tel que PIC comme je vous l'avais proposé et que vous avez décliné, cela aurait été plus pertinent pour la fameuse démonstration.
Il est toujours plus facile de faire du C++ quand la cible le permet. même si l'intérêt est nul dans ce contexte.
Il va falloir faire beaucoup mieux pour convaincre.





Bonjour à tous

Ceci est le dernier message déplacé pour crééer la nouvelle discussion parallèle.

Toutes les réponses suivantes seront faites après ce déménagement.

Pardon pour cette incursion/modification.

[A voir en vidéo sur Futura]

[3king]

Bonjour.

-- Mélanger C et C++ est dénaturé
-- C++ n'est pas portable et est en plus dépendant du processeur.
-- C++ ne peut pas travailler intimement avec le hardware

--> De bien curieuses assertions... N'importe quel programmeur qui a un peu d'expérience en C et C++ (dans l'embarqué) ouvrira des grands yeux en lisant cela. Il fait ça tous les jours sans pour autant avoir l'impression de vivre dans la 5e dimension...

-- C++ n'apporte strictement rien, C++ est une démarche inappropriée, etc,etc...

--> Là où les notions d'encapsulation, d'objet, voire d'héritage paraissent évidentes et bien C++ est un bon choix.
Par contre choisir C++ là où il n'apportera rien par rapport à C c'est vraiment chercher la complication.

[Murayama]

Bonjour!

-- Mélanger C et C++ est dénaturé
-- C++ n'est pas portable et est en plus dépendant du processeur.
-- C++ ne peut pas travailler intimement avec le hardware
--> De bien curieuses assertions... N'importe quel programmeur qui a un peu
d'expérience en C et C++ (dans l'embarqué) ouvrira des grands yeux en lisant cela.
Il fait ça tous les jours sans pour autant avoir l'impression de vivre dans la 5e dimension...

À tout hasard, puisqu'il n'y a que des morceaux repris, je précise que ceci est l'avis
de notre expert, pas le mien.

Par contre choisir C++ là où il n'apportera rien par rapport à C c'est vraiment
chercher la complication.

Bien sûr, mais c'est à chaque programmeur de juger si C++ lui apporte quelque chose ou pas.
Je suis plutôt pour la liberté de décision quand c'est possible.

Pascal

[3king]

Mille excuses Miramaya, j'avais bien compris que vous commentiez des propos qui n'étaient pas les votres. De fait, j'abondais dans votre sens. Quand au choix entre C et C++ vous avez tout à fait raison, à chacun de peser le pour et le contre.

[3king]

Je voulais dire Murayama...

[PA5CAL]

Il est toujours plus facile de faire du C++ quand la cible le permet

+1.

Je suis curieux de voir un programme en (véritable) C++ écrit pour un PIC disposant de 256 mots de mémoire programme, de 16 octets de mémoire vive et d'une pile de 2 octets (ce qui, du reste, est très suffisant pour réaliser une girouette) .

La finalité (sinon l'intérêt) du C++ est de mener une conception centrée sur les données traitées, qui généralement évoluent peu durant la vie des gros projets. Le C, son ancêtre, est plus adapté à une conception centrée sur les traitements (programmation procédurale structurée).

Or, plus les systèmes cibles sont petits, plus leurs ressources matérielles sont limitées, et plus on est contraint d'axer la programmation sur ces dernières afin d'éviter de les gaspiller. Dans les cas extrêmes, on en est quasiment réduit à faire de la programmation séquentielle, en assembleur ou dans une forme limitée d'un langage plus évolué (C, BASIC, ...).


Plus le langage utilisé implique de mécanismes complexes pour concrétiser ses abstractions, plus les ressources nécessaires sont susceptibles d'augmenter en taille, en performance et/ou en spécificité.

Ainsi, si une programmation en C++ pleine et complète est aisée sur de gros micro-contrôleurs (e.g. ARM), elle n'est rendue possible sur de plus petits modèles (e.g. AVR 8 bits) que grâce à la disponibilité de ressources assez notables et/ou à l'efficacité (voire aux acrobaties) du compilateur. Et il existe une taille critique au-dessous de laquelle l'utilisation de ce langage n'est plus envisageable que sous une forme tellement restreinte qu'elle n'en mérite certainement plus le nom.

[Chtulhu]

Mille excuses Miramaya, j'avais bien compris que vous commentiez des propos qui n'étaient pas les votres. De fait, j'abondais dans votre sens. Quand au choix entre C et C++ vous avez tout à fait raison, à chacun de peser le pour et le contre.

Je pense que PA5CAL a répondu.
Ce n'est pas un choix comme savoir si on va prendre une pomme ou du fromage... il faut de la cohérence dans ce métier.

[Chtulhu]

À tout hasard, puisqu'il n'y a que des morceaux repris, je précise que ceci est l'avis
de notre expert, pas le mien.

Je ne suis pas "votre" expert, je sens bien que ce qualificatif vous fait mal, un jour vous le deviendrez peut être, patientez encore une bonne décennie en R&D et sachez accepter la critique, dans ce métier c'est indispensable.

Bien sûr, mais c'est à chaque programmeur de juger si C++ lui apporte quelque chose ou pas.
Je suis plutôt pour la liberté de décision quand c'est possible.

Je ne vois pas bien ce que viens faire la liberté dans un choix technique, à part vouloir se faire plaisir, ce qui est justement l'inverse de l'efficacité recherchée sur un projet, tout développeur sérieux sait cela.
Soit C++ est plus pertinent soit il ne l'est pas, ça ne se décide pas avec ce type d'appréciation, ne vous en déplaise.
Si vous vouliez faire une démonstration il aurait fallut prendre un sujet adapté à C++, il n'en manque pas, la girouette est typiquement un mauvais exemple, ce que je me tue de vous dire depuis le début.
Si vous aviez une commercialisation à faire avec ça, prendre un 16 bits comme le MSP430 est une erreur fondamentale, il vaut 16$ à l'unité chez Arrow:
msp430.PNG

Un PIC 16F16f1824 chez le même fournisseur 1.27$ à l'unité:
pic16f1824.PNG

J'invente rien.

Par quantité c'est encore pire, ce 8 bits s'achète quelques dizaines de centimes.
Il faudrait peut être commencer par les fondamentaux avant de faire de longs discours prétentieux.
J'attends la suite de votre démonstration mais c'est bien mal parti pour le moment.

[abracadabra75]

Encore une guéguerre de religion....
J'en conclue que tel un dinosaure, je vais garder mon assembleur antédiluvien.

[antek]

Encore une guéguerre de religion....
J'en conclue que tel un dinosaure, je vais garder mon assembleur antédiluvien.

Ouais, y'en a qui ont l'acrimonie chevillée au corps.
'toute façon le C++ c'est pour les lopettes, les guerriers programment en assembleur . . .

[freepicbasic]

+1.

Je suis curieux de voir un programme en (véritable) C++ écrit pour un PIC disposant de 256 mots de mémoire programme, de 16 octets de mémoire vive et d'une pile de 2 octets (ce qui, du reste, est très suffisant pour réaliser une girouette) .

+1


Sur un pic16F84 qui a 1k mot de programme, ce programme ci dessous prendra tout les 1K !

Difficile de faire quelque chose dans ces conditions en employant une lib standard.
Sachant qu'il a une fabuleuse pile de 2 adresses et pas de pile data, la programmation sera de l'assembleur à la sauce C et à condition de n'utiliser que le C basic et de savoir ce qu'il génère ...

// exemple du printf extrait de wikipédia
#include <stdio.h>

int main()
{
printf("Hello");
return 0;
}

NB)
Je ne parle même pas du C++ . LOL

[Chtulhu]

Encore une guéguerre de religion....

Dommage que ce soit ressenti ainsi, il ne s'agit pas de croyances.
J'explique juste que C++ ne peut pas être appliqué à tous les µC, c'est la problématique à résoudre qui conditionne le choix.
Dans le monde des 8 bits le C++ n'a aucun intérêt, C et assembleur sont bien plus pertinents, juste que l'assembleur semble compliqué pour certains.
Le C reste le langage haut niveau le plus près de la couche matériel.
Comme il a été dit, si c'est pour utiliser C++ sans exploiter ce qu'il peut apporter, ça n'a aucun intérêt.
C'est de cela dont il est question ici, rien de plus.

[antek]

J'explique juste que C++ ne peut pas être appliqué à tous les µC, c'est la problématique à résoudre qui conditionne le choix.

Mais tout le monde le sait !

[abracadabra75]

Bon...
Comme ça, c'est plus clair.
Auparavant, pour un béotien ne connaissant rien du C++, cela ressemblait à la discussion du sexe des anges, ou pour être un peu plus moderne Linux vs Windows.

[abracadabra75]

Mais tout le monde le sait !

Ben non... pas les béotiens

[antek]

Ben non... pas les béotiens

Je voulais dire ceux qui sont concernés.
Si tu avais voulu apprendre à programmer en C++ tu aurais rapidement compris qu'un 16f84 est inadapté !

[Chtulhu]

Non justement tout le monde ne semble pas le savoir!
Murayama tente de nous prouver que choisir C++ est la bonne démarche, qu'aujourd'hui utiliser C est démodé, c'est bien loin d'être le cas.
La plupart utilise C++ sans aucune distinction du besoin, juste parce qu'ils utilisent des IDE qui leur apportent des librairies toutes faites (arduino en l'occurrence).
Et j'insiste aussi que la portabilité n'est pas aussi simple qu'avec C, ce qui n'est pas qu'un détail entre les 2 approches.

[Chtulhu]

Je voulais dire ceux qui sont concernés.
Si tu avais voulu apprendre à programmer en C++ tu aurais rapidement compris qu'un 16f84 est inadapté !

C'est l'inverse... vous voyez bien que vous n'avez pas compris.

[antek]

C'est l'inverse... vous voyez bien que vous n'avez pas compris.

Oui, l'inverse est vrai aussi !

[Chtulhu]

Pour résumer:

en employant C vous pouvez répondre à TOUTES les cibles 8, 16 et 32 bits sans exceptions, toutes les marques ont un compilateur C, toutes les marques n'ont pas un compilateur C++.
Vous pouvez donc porter vos codes plus facilement en C.
Avec C++ c'est 16 et 32 bits et vous êtes limités selon si un compilateur existe ou pas, si il est bien supporté ou pas, ça limite pas mal les choses.
La raison est très simple, les fabricants de 8 bits ayant pignon sur rue ne voient aucun intérêt à proposer des outils coûteux inadaptés à leur cibles.
D'où le mariage que vous serez amené à faire et la difficulté d'en sortir dès que vous devrez opter pour des cibles moins chers et pour lesquelles vous n'aurez pas de solutions en C++.
L'incursion de C++ dans le mode du 8 bits est contre productif et n'apporte strictement RIEN de plus que C, si ce n'est des habitudes qui vont vous éloigner de la couche matérielle.
C'est uniquement de cela dont on parle depuis le début!
Créer des librairies logicielles fiabilisées représente beaucoup de temps, et jusqu'à preuve du contraire, l'immense majorité des codes 8 et même 16 bits ont été écrits en C, pas en C++. Migrer vers C++ doit avoir un intérêt majeur et décisif.
Donnez moi un exemple que vous argumenteriez à votre patron pour le convaincre de basculer de C à C++, et donc de devoir balayer peut être 10 ans de dev.
Et ensuite on en reparle.

[Chtulhu]

On voit à travers cette discussion la différence d'approche entre un technicien qui se fout des implications budgétaires et ne voit que le coté technique.
Heureusement que dans les boites il y a aussi des gens qui pensent à l'efficacité et à la notion de coût.
Ca échappe visiblement à beaucoup ici.
J'appelle ça se faire plaisir.
Dans les loisirs on a le droit de se faire plaisir, ne mélangeons pas tout svp.

[invite39886733]

Bonjour a tous

Pour moi le C++ est le bienvenue dans l'embedded. Bien sur ce n'est jamais le "full C++" qui est disponible mais des subset avec beaucoup de fonction manquantes (template, virtual class...)
L'avantage est clairement la réutilisation du code objet et la lisibilite.

Mais il faut etre honete si vous produisez deja du code illisible, de passer au c++ ne va pas magiquement vous transformer en grand programmeur

[invite39886733]

Dommage que ce soit ressenti ainsi, il ne s'agit pas de croyances.
J'explique juste que C++ ne peut pas être appliqué à tous les µC, c'est la problématique à résoudre qui conditionne le choix.
Dans le monde des 8 bits le C++ n'a aucun intérêt, C et assembleur sont bien plus pertinents, juste que l'assembleur semble compliqué pour certains.
Le C reste le langage haut niveau le plus près de la couche matériel.
Comme il a été dit, si c'est pour utiliser C++ sans exploiter ce qu'il peut apporter, ça n'a aucun intérêt.
C'est de cela dont il est question ici, rien de plus.

Je ne comprend même pas que l'on parle encore d'assembleur... Son utilité est devenue tellement ultra spécifique que l'on peut presque dire que ça ne devrait plus être utilise du tout.
Pour avoir le droit de l'utiliser bientôt il faudra montrer sa carte vermeille

[Chtulhu]

Que vous ne compreniez pas n'est pas en soit un argument technique, bien au contraire même.
Ca confirme au moins le coté amateur.... faut dire que c'est un peu plus subtil que de faire des copié-collé piochés sur le net.
Ce n'est pas une question de droit mais de compétences que l'on a, ou pas, pour traiter des cas particuliers.
Et vous semblez également ignorer que c'est au final du code assembleur qui est généré...

Puisqu'on parle de MSP430, je vous conseille de lire ceci:
http://www.ti.com/lit/ug/slau131r/slau131r.pdf

Vous pensez que Texas est un repère de vieux?

[invite39886733]

Les MSP430 sont les "ultra low power" de Ti.

Quand on choisit un MSP430 on ne l'a surement pas selectionne pour sa vitesse... (vitesse = consommation)
Et c'est la seule chose a laquelle l'assembleur est encore bon a quoi que se soit.

Je ne vois vraiment pas pourquoi programmer un MSP430 en assembleur mais si ca vous fait plaisir allez-y!!! Bon courage au pèlerin qui passera derrière vous pour utiliser votre code plus tard

[Chtulhu]

1/ il existe bon nombre de µC ayant une très faible consommation, l'assembleur n'a que peu avoir là dedans.
Accessoirement on peut obtenir de la vitesse dans un traitement sans nécessairement avoir recours à une base de temps rapide.
Justement, ceux qui ignorent l'assembleur compense la lourdeur du code évolué par la vitesse et donc augmente la consommation...
2/ L'assembleur est nécessaire lorsqu'on veut imposer au compilateur certaines subtilités fonctionnelles qu'il ne génère pas forcément ou aussi optimisées.
Des méthodes et des objectifs à atteindre sont exigés dans les procédures de sûreté de fonctionnement, il ne faut pas faire une confiance aveugle aux compilateurs, sauf ceux qui répondent à ces exigences conceptuelles.

Le "pélerin" comme vous dites est formé à cela et les codes sont dûment renseignés et documentés, comme cela est la règle pour les gens qui codent autrement qu'avec les pieds.
Le choix n'est pas toujours de mise, il faut aussi tenir compte des contraintes et ne pas toujours succomber au confort ambiant.

Croyez-vous que dans un OS de PC il n'y a pas d'assembleur?
L'assembleur est encore présent et nécessaire, que vous le compreniez ou non.

[naru2to]

Je ne comprend même pas que l'on parle encore d'assembleur... Son utilité est devenue tellement ultra spécifique que l'on peut presque dire que ça ne devrait plus être utilise du tout.

Parfois il est nécessaire de savoir ce que l'on fait, soit avec des instructions intégrées dans du C (sur micro 8 bit ou 16 bit) soit projet complet sur des microcontrôleurs très restreints (PIC10F et 12F par exemple). Je vous l'accorde ça doit représenter 1% de mes projets, mais c'est pas négligeable pour autant, et je suis loin de la carte vermeille

Et c'est la seule chose a laquelle l'assembleur est encore bon a quoi que se soit.

Nuance, même si la vitesse peut découler de l'assembleur, on (je) l'utilise avant tout pour la maîtrise du temps d'exécution. On peut très bien vouloir quelque chose de "lent" mais avec une répétabilité à 1 cycle près

EDIT : grillé par Ctulhu ^^