Bonjour ou bonsoir,
Auriez l'amabilité de me dire quelle est la formule à privilégier, #define ou int...? Et pour quelle raison?
Un grand merci pour l'aide à un débutant
Cordialement
Jean-Pierre
Si tu veux optimiser la mémoire, il faut prendre le define : il indique au compilateur de changer toutes les occurrences de LEDPIN dans le source par 13. Donc, cela n'utilise pas de variable.
Sinon, tu peux très bien déclarer une variable et l'utiliser dans le code : comme ça si tu veux en changer la valeur un jour, il suffit de la changer dans cette déclaration. Tant qu'à faire déclare la en const :
const byte LEDPIN = 13;
Bonjour,
Il vaut mieux utiliser const byte LEDPIN=13;
Ca permet au compilateur/optimiseur qui connait le type de la constante de mieux optimiser le code.
Le compilateur ne crée pas de variable ou constante si ce n'est pas nécessaire.
Dans les cas simples comme pour un numéro de pin, le code généré avec #define ou const byte sera le même.
Merci pour votre compétence et votre diligence.
Bonne soirée
Normalement, les instructions au preprocesseur (fonctionnent aussi avec Fortran et avec certain assembleur) sont très mal vues:
- elles sont difficilement lisibles
- les testeurs de code automatique souffrent énormémement
- elles peuvent provoquer des effets de bord bizarroîdes et difficiles à corriger (operations arithmetiques)
Les compilateurs modernes savent très bien transformer un * const anytype truc* de sorte que pas de RAM n'est consommée (ce d'autant plus que les optimisations par défaut de l'arduino portent sur la taille mémoire -size-)
Autant ne pas prendre cette habitude et reserver l'usage à des cas désespérés, extrêmement rares-
en C++ maintenant on peut aussi utiliser constexpr qui a l'avantage d'être figée à la compilation donc dans l'absolu on écrirait
constexpr byte ledPin = 13;
on évite généralement les macros que l'on réservera plutôt aux directives de compilations
cela dit, pour les programmes que l'on voit ici, peu importe, les 3 versions seront généralement totalement équivalentes après le passage de l'optimiseur
J'ai été intrigué par constexpr et me suis tourné vers la Providence des Cancres, stackoverflow
Ils arrivent à trouver des avantages -très limités- aux macros, qui permettent de rendre du code dormant
#ifndef CODE_PAS_CACHE ... #endif permet de compiler des morceaux de code affectés de messages d'erreur et de les rendre plus propres progressivement, par exemple. Mais ce sont des cas tout à fait exceptionnels
Sinon pour les fainéants, on ne définit rien du tout et on utilise LED_BUILTIN
Merci à tous! Un problème de plus en moins...
Oui c’est quand on utilise les macros pour de la compilation conditionnelle
Oui les macros sont quand même massivement utilisé dans la compilation conditionnelle ou pour connaitre les différentes propriétés de la plateforme entre autre.
Oui et c’est là où par elles devraient être cantonnées quand il y a une alternative efficace dans le langage apportant plus d’info au compilateur (type par exemple)
La compilation conditionnelle mène à des codes difficiles à lire.
Ceci a nécessité la création de logiciels tels que unifdef unifdef(1) - Linux man page permettant à des êtres humains de lire certains sources (installable sur RPi et clones) sans être très ennuyés par le fait que cpp est un autre langage que C(++) (ou gfortran ou ...)
Je n'ai jamais utilisé de unifdef et je ne vois pas trop l'apport de tel outil, qui ne sait pas forcément les options de compilation que tu va choisir.
De toute façon le problème n'est pas là, si on veut un code portable, le choix est limité.
Je ne vois pas non plus ce qu'il y a de spécifique à RPi ou un clone?
Après libre à toi de ne pas les utiliser, mais cela ne semble pas le choix de la plus part des outils open-source.
Je n'ai jamais utilisé de unifdef et je ne vois pas trop l'apport de tel outil, qui ne sait pas forcément les options de compilation que tu va choisir.
C'est manifeste (et pourtant, j'avais lié au mode d'emploi d'un outil open source digne de ce nom , permettant de faire connaître à l'outil open source quelles options de compilation doivent être fixées; eh oui,, l'outil open source sait nettoyer intelligemment du code et le rendre tout simplement lisible). Il est tout aussi manifeste que vous n'avez pas pris la peine ... de lire un manuel au standard open_source.... avant de disserter doctement.
Je ne vois pas non plus ce qu'il y a de spécifique à RPi ou un clone?
Il 'agit d'un paquet debian, que j'ai utilisé avec satisfaction uniquement sur RPi et clones (et je ne prends pas position sur des outilsOpenSource que je ne connais manifestement pas! ni sur des conditions d'utilsation que je n'ai pas testées -question d'honnêteté, si cette notion existe dans l'open-source)
Après libre à toi de ne pas les utiliser, mais cela ne semble pas le choix de la plus part des outils open-source
Une des libertés fondamentales de l'open source étant d'avoir des sources lisibles, l'outil_open_source unifdef est un outil de récurage sérieux et efficace; vous vous sentez manifestement libre d'étaler votre méconnaissance du sujet (le pseudo raisonnement "ça compile, donc ça mârche" est une plaie de l'open source).
Je ne conteste pas la qualité de cet outil ou alors tu n'a pas bien lu mon commentaire.
Qu'un outil existe aussi performant soit-il, ,ne veut pas dire que c'est la seul façon de faire et qu'une majorité d'utilisateur l'utilise.
C'est pour cela que je précise que lors de ma modeste expérience, je n'ai jamais cherché un tel outil.
Après peut être que d'autre comme @J-M-L ne seront pas de cet avis.
Si tu prends sur ton Rpi, les sources linux entre autre, tu verra que les #ifdef sont très largement utilisées.
Si tu cherche bien, te verra les librairies sont compiler avec certaines directive assez générale et que quelque fois, tu es obligé de recompiler avec d'autre option.
Cela ou je ne comprends pas ton soucis avec ça, si tu veux des sources qui compiles sur des plateformes complétement différente, je ne connais pas d'autre façon de faire.
Sans compilation conditionnel, tu ne sera libre de rien du tout, tu pourra voir des sources très lisibles, mais qui ne compilerons pas sur ta machine.
Je te trouve très culotter de me reprocher d'étaler ma connaissance, peut être devrais tu déjà balayer devant ta porte!
étonnement je suis complétement d'accord avec toi, ce raisonnement sur la compilation est complétement débile.
Si tu prends sur ton Rpi, les sources linux entre autre, tu verra que les #ifdef sont très largement utilisées
Cet argument d'autorité est aussi absurde que de justifier la traction hippomobile -utilisée très majoritairement pendant quelques millénaires.
Depuis trente ans, on a largement eu le temps de constater que c'est une source de confusion et d'évoluer quand c'était possible ... et de nettoyer le code quand on pouvait faire autrement et qu'on avait le temps...
Si tu cherche bien, te verra les librairies sont compiler avec certaines directive assez générale et que quelque fois, tu es obligé de recompiler avec d'autre option
Normalement (sauf pour mes applications favorites : R, opencv et quelques moteurs de réseaux de neurones profonds) je suis plus que satisfait du travail des développeurs debian, et je n'ai pas besoin de recompiler; le cas de mes applications favorites me permet d'avoir des versions très récentes et des options exotiques; le prix à payer est que je fais des entrées sorties sur un "disque" -carte SD- à écritures limitées (eh oui, je sais qu'il est très déconseillé de compiler sur les RPis...; mais alors, pourquoi voulez vous que je me "sente obligé"? alors que j'ai choisi une distribution ou presque tout est bien fait)
effectivement Rpi n'utilise pas du tout de #ifdef par ex ici ou là 
Mais comme d'habitude tu as complétement raison!
Donc j'arrête là cette discutions stérile avec un #ifdef 0 
Unidef, outre le fait qu'il soit totalement obsolète et non maintenu à ma connaissance, a des limites (détaillées dans la doc) qui sont quand même rédhibitoires pour des codes un peu avancés
Sunifdef" (Son of Unifdef aka Coan) a plus de capacités mais date aussi de 15 ans....
Quand j'ai le besoin, extrêmement rarement, il y a toujours une option (-E de mémoire pour gcc) qui montre ce qui sera compilé après passage de l'étape du préprocesseur. Je préfère cette solution à des outils tiers car je suis sûr que ce que je vois c'est vraiment ce qui sera compilé et pas une interprétation d'un outil séparé
Evidemment, il y a 100 ans, les gens utilisaient des chevaux...
Evidemment, vous avez contribué à une remarque informative (il existe un moyen de nettoyer du code pollué par des ifdef et de le rendre lisible -pas compilable, lisible) adressé à d'autres que vous, dans la mesure de vos talents généreusement étalés....
Evidemment, un grep permet à un claveteur de trouver des ifdefs dans du code.... et de se la péter.. (c'est la protection des sources par la confusion,
garantissant l'emploi de certains "informaticiens")
Evidemment, le paquet Debian unifdef a été mis pour casser des sources... pas pour qu'on puisse les lire
FYI: normalement, je ne vous réponds pas - sauf si vos remarques dépassent la décence-