Variable, globale ou passage par pointeur ?

Bonjour,

Ma question est :
Utiliser un pointeur ou une variable globale pour passer une structure à des fonctions.

Etat de la situation :

Hardware : Arduino MKR1010 SAMD21 Cortex®-M0+ 32bit low power ARM® MCU
Utilisateur : 1 l'arduino.
Programmeur :1 moi.

Le programme: Lire les valeurs de capteurs et les mettre dans un tableau de valeurs moyennes glissantes minutes.

Avec un ordinateur "standard", la question ne se poserait que peu, un pointeur évidemment.

Mais avec Arduino, la séquence est quelque peu différente.

Un Arduino démarre avec un "setup" qui n'est effectué qu'une fois au démarrage , puis un "loop" qui est répété ad vitam.....

Pour Calculer une moyenne glissante dans le loop, je fais ainsi:

Code:

---

1 2 3 4

............... Vm.dTT += sens.readTemperature(); Vm.dTT /=2; ..........

---

Opération repetée tous les 10secondes.
A chaque minute, je stocke les valeurs dans un fichier ou une DB sur un Raspberry (MariaDb)

Le soucis vient du départ du logiciel.
Lorsque le code est effectué pour la première fois, la valeur dans Vm.dTT est la moitié de la valeur lue par le capteur.
Il faut alors écrire une boucle pour vérifier si l'on est au premier passage ou aux suivants......
Pour palier cela, il est simple de faire:

Code:

---

Vm.dTT = sens.readTemperature();

---

dans le setup.

Oui mais :
Si je déclare

Code:

---

struct ValeurMinute Vm;

---

dans le "Loop", je ne peut utiliser Vm dans le setup...
Si je declare Vm dans le setup, Cette variable n'existe pas dans le loop.......

De plus, si j’enchaîne le passage de fonction,
Main() -> menu() ->MetEnForme()->affiche()
Je dois chaque fois passer le pointeur pour chaque appel de fonction ....?

Si j'ai plusieurs variables à passer à mes fonctions, leur déclarations devient vite complexe.(C'est là qu'on devient fainéant ???)

Comme je programme tout seul dans mon petit coin et vu la structure de l'Arduino, les variables globales me semble une solution(de feignasse) simple à écrire.

Si je pouvais avoir des avis sur la question....

Un grand merci


Michel

Je n'ai pas bien compris ton problème :oops: :oops: (<- édit: Bktero mon voisin du dessous a répondu les fonctions setup et loop sont spécifiques à Arduino, que je ne connais pas du tout)

Mais "passer 1 pointeur" s'appelle de l'injection de dépendances (Wikipédia français et anglais)

Citation:

---

Envoyé par michel.semal

Je dois chaque fois passer le pointeur pour chaque appel de fonction ....?

---

:mrgreen: ben ouais, cela s'appelle du découplage (<- lien Wikipédia) … et c'est l'avantage de l'injection de dépendances et l'inconvénient MAJEUR des variables globales/ "god object" (<- lien Wikipédia)

Citation:

---

Envoyé par michel.semal

Si j'ai plusieurs variables à passer à mes fonctions, leur déclarations devient vite complexe.(C'est là qu'on devient fainéant ???)

---

:mrgreen: il faut regrouper les paramètres dans des ""objets"" (en C, on n'a que les structures) et passer les pointeurs sur 1 ""objet"".
Ensuite, 1 ""objet"" peut avoir du sens dans la conception de ton programme (représenter tel ou tel "concept") ou alors c'est juste 1 DTO (Data Transfert Object) (<- lien Wikipédia en anglais, en gros c'est 1 objet sans logique sauf de données)

Après tu as la solution intermédiaire entre les variables globales et l'injection de dépendances : le gros "god object" créé dans la fonction main (donc pas global et c'est le premier truc créé et initialisé dans le programme) et que tu passes partout :wow:
Édit: c'est d'ailleurs 1 peu le code du message #4 de @dalfab : on court-circuite la fonction setup en créant 1 nouvelle fonction initialisation, on créé toutes les variables au début de la fonction loop et ensuite, on les passe partout.

De manière générale, les variables globales, c'est nul. Ca semble une bonne idée au début parce que c'est pratique, mais avec le temps, ça devient le bazar.

Le cas d'Arduino est un peu spécial. Si tu veux accéder à des variables dans setup() et dans loop(), tu n'as pas trop de le choix. Tu es obligé de les déclarer hors des fonctions, au niveau fichier. Tu peux ajouter static pour limiter le scope toutefois.

Bonjour,

C'est cette décomposition de l'Arduino en 2 fonctions disjointes qui empêche de faire les choses proprement.
On peut contourner le problème en faisant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

void setup(void) { } void loop(void) { // définitions des variables d'application partagées entre setup() et loop().   initialisation( passage_par_pointeur_des_données_necessaires ); // ce qu'il y avait dans setup for (;;) { actions_cycliques( passage_par_pointeur_des_données_necessaires); // ce qu'il y avait dans loop() } // donc la fonction loop() n'est finalement appelée qu'une seule fois, c'est main()! }

---

On a alors plus besoin de globales sauf pour les données accédées par les interruptions où c'est alors incontournable.

Bonjour,

Si les variables globales posent problème, les bannir systématiquement avec la technique du "passe à ton voisin" de fonction en fonction présentent de nombreux risques.

Le premier est la lisibilité car cela induit un accroissement du nombre d'arguments qui rend plus difficile de trouver ce qui est propre à la fonction. Or la lisibilité et la maintenance se tiennent par la main.

Le second est l'effet de chaîne notamment s'il y a des pointeurs, et il y en a toujours. Quand ça commence à tanguer, le pistage d'erreur mérite bien son nom. Sans aucun recul, on peut continuer à se moquer de ces temps archaïques de la programmation spaghetti.

Le troisième est la surcharge que cela induit au niveau de la pile. Je sais que beaucoup pensent que les ressources sont quasi infinies (et les microcontrôleurs ?), mais outre la consommation de ressources mémoires, une gestion lourde de la pile prend du temps.

Tout ceci pour dire qu'il est bien de tenir compte des risques de chaque pratique mais de ne pas en faire des règles absolues qui engendrent, d'une part un manque de réflexion (j'ai été dans le mur mais j'ai bien suivi la ligne blanche), et d'autre part des contorsions qui peuvent être plus dangereuses que ce que les règles sont censées éviter.

Je considère que les règles sont seulement des barrières dont le franchissement doit être murement réfléchi et justifié. Cela ne va pas au-delà.

Salutations

Citation:

---

Envoyé par Guesset

Le premier est la lisibilité car cela induit un accroissement du nombre d'arguments qui rend plus difficile de trouver ce qui est propre à la fonction. Or la lisibilité et la maintenance se tiennent par la main.

---

Les paramètres font partie de la compréhension. Par exemple, avec 1 fonction write, tu attends 1 "destination" et 1 "origine".
Justement, avec les variables globales, tu vas n'avoir [par exemple] qu'1 fonction write sans paramètres destination ? origine ?
Après sûrement que cela dépend de comment tu conçois ton code.

Citation:

---

Envoyé par Guesset

Le second est l'effet de chaîne notamment s'il y a des pointeurs, et il y en a toujours.

---

Étant expert, tu sais bien qu'1 passage par adresse/ sortie ou entrée-sortie, n'induit pas forcément 1 pointeur.
On manipule 1 objet au travers de son adresse, mais cela n'implique pas forcément 1 allocation mémoire (avec malloc, realloc, calloc, …)

C'est pour cela, en mon sens que la notion d'alias & du C++ est mieux : on manipule 1 objet normalement et le compilation ""fait la translation"" avec son adresse pour nous.

Citation:

---

Envoyé par Guesset

Le troisième est la surcharge que cela induit au niveau de la pile.

---

Si tu créés des ""objets"" pour ton code, tu vas être forcément obligé de les passer en paramètre … et en C, cela veut dire 4 (32 bits) ou 8 (64 bits) octets sur la pile.
Et (comme je l'ai dit avant) si tu as des paramètres hétéroclites, tu crées des DTO.
Après sûrement que cela dépend de comment tu conçois ton code : limiter le nombre de paramètres, faires les bonnes structures, créer des DTOs (ou autres), …

Citation:

---

Envoyé par Guesset

Le troisième est la surcharge que cela induit au niveau de la pile. Je sais que beaucoup pensent que les ressources sont quasi infinies (et les microcontrôleurs ?), mais outre la consommation de ressources mémoires, une gestion lourde de la pile prend du temps.

---

C'est intéressant et important de s'intéresser aux conséquences, mais il ne faut pas non plus tomber dans la paranoïa. Sur bien des processeurs modernes, beaucoup de paramètres sont passés par des registres. Prenons par exemple un code comme ça :

Code:

---

1 2 3 4 5 6 7 8

static int value; void set(int* p); void print(int v);   int main() { set(&value); print(value); }

---

Avec Compiler Explorer, on peut voir que le paramètre de la fonction est dans un registre.

• Pour x64, Windows utilise 4 registres avant d'utiliser de la pile pour les paramètres
• Linux, c'est 6 registres !
• Pour ARM (au moins en 32 bits), c'est aussi 4 registres

L'appel de fonction lui-même est donc potentiellement plus coûteux que quelques pointeurs en paramètres.

Bonjour foetus,

C'est un forum C. Il y a un peu de mélimélo.

Citation:

---

Envoyé par foetus

Les paramètres font partie de la compréhension. Par exemple, avec 1 fonction write, tu attends 1 "destination" et 1 "origine". Justement, avec les variables globales, tu vas n'avoir qu'1 fonction write sans paramètres destination ? origine ? ...

---

Pour répondre au sujet : write(stdout,...), stdout n'est pas une variable globale ? En C, hormis les instructions de base, tout est en bibliothèques y compris write() et ... stdout. Le fait que stdout soit un alias système ne change rien à sa déclaration. Cet exemple de ton choix illustre bien la différence qui existe entre théorie et réalité. Pour être clair, sans défendre l'usage systématique des variables globales, je pense que toute règle absolue incite à la paresse intellectuelle et se heurte au réel. Concevoir du code sans discuter ni comprendre les règles ?

Citation:

---

...1 passage par adresse/sortie ou entrée-sortie, n'induit pas forcément 1 pointeur. On manipule 1 objet au travers de son adresse, mais cela n'implique pas forcément 1 allocation mémoire (avec malloc, realloc, calloc, …)

---

En C on ne passe que des paramètres par valeur. La seule astuce qui permette d'agir sur une variable (simple ou composite) est de passer la valeur de son adresse : un pointeur. Je n'ai parlé de gestion de ressource mémoire que par l'usage effréné de la pile. C'est une gestion induite par le développeur mais non gérée directement par lui comme les instructions d'allocation citées. C'est parce cette gestion peut paraître transparente qu'il faut attirer l'attention sur certains comportements qui peuvent la malmener.
Le passage d'un argument passe par une gestion de pile sauf à utiliser le très limité, mais performant, register. D'une part la pile est une ressource bien plus limitée que le tas mais les empilages dés-empilages coûtent chers. La recherche d'éviter à tout prix le recours à des variables globales peut conduire une fonction à transmettre des informations en cascade à des fonctions qui n'en n'ont pas nécessairement besoin directement mais qui appellent une fonction qui pourrait en avoir besoin ou l'une des fonctions qu'elle appelle etc.

Citation:

---

Si tu créés des ""objets"" pour ton code, tu vas être forcément obligé de les passer en paramètre … et en C, cela veut dire 4 (32 bits) ou 8 (64 bits) octets sur la pile...

---

Dans cet exemple, tu ne passes pas ces structures en paramètre mais seulement leur adresse. C'est un choix fréquent pour éviter de recopier des volumes importants dans la pile. Mais ce n'est pas obligatoire et présente d'autres risques comme le risque de modification intempestive de la variable appelée.

Les conseils émis me paraissent bons. Mais pratiquement aucun ne méritent de devenir une règle absolue. J'aurais eu tendance à écrire (et à justifier ce que je ne fais pas ici) :

• On évitera l'usage systématique de variables globales
• On évitera la surcharge en nombre de paramètres des fonctions

Salut.

Bonjour Bktero,

Citation:

---

Envoyé par Bktero

...Sur bien des processeurs modernes, beaucoup de paramètres sont passés par des registres...

---

Ce ne sont pas les processeurs qui décident ce qui passe en registre mais le compilateur éventuellement épaulé par une directive register (qu'il peut allègrement ignorer).

Citation:

---

Envoyé par Bktero

...L'appel de fonction lui-même est donc potentiellement plus coûteux que quelques pointeurs en paramètres.

---

Mais merci, car cela montre qu'il faut éviter les chaînes trop importantes de paramètres qui vont mécaniquement engendrer un cadre de pile. C'est bien le risque que je citais : multiplier les paramètres pour éviter les variables globales. Bien sûr, il y a la solution d'une structure gérant un ensemble hétéroclite, mais dont on peut passer la seule adresse : c'est pire qu'une variable globale puisque ce fourre-tout donne accès à des informations non nécessaires aux fonctions appelées.

Par ailleurs, l'exemple est biaisé car il n'y a pas de variables locales qui provoquent systématiquement la création d'un cadre de pile qu'il y ait peu ou pas de paramètres. Le gain register n'existe alors plus.

En outre le moindre passage d'une structure par valeur fera disparaître tout usage des registres même pour un seul paramètre.

Salut

J'ai simplifié dans mes exemples en disant processeurs. En réalité, ce sont les ABI qui dictent les calling conventions. Les compilateurs suivent des ABI. Pour x68 / x64, il y a plusieurs ABI. Pour x64 par exemple, Microsoft a la sienne, la plupart des autres suivent https://itanium-cxx-abi.github.io/cxx-abi/abi.html . Pour ARM, je crois que l'ABI est définie directement par ARM.

En C++, le mot-clé register est deprecated depuis C++17. Je sais pas trop où en est le C, ça semble toujours valide, mais ça n'a toujours été qu'un "hint", jamais un ordre.

Il est possible de passer des structures par des registres, si une instance tient dans les registres que l'ABI permet d'utiliser comme paramètres de fonction. Tu peux faire l'essai avec le code précédent, en utilisant une structure simple à la place d'int :

Code:

---

1 2 3 4

struct S { int a; int b; };

---

J'ai l'impression que tu mélanges allègrement tout (variables locales, chaînage de fonctions, multiplication à outrance des paramètres, agrégation sans limite d'objets, etc) pour justifier que les variables globales, c'est OK. Tu as le droit de trouver ça pratique, ce n'est pas nécessaire de pousser le bouchon pour te justifier ;)

Bonjour Bktero,

Citation:

---

Envoyé par Bktero

...En C++, le mot-clé register est deprecated depuis C++17. Je sais pas trop où en est le C, ça semble toujours valide, mais ça n'a toujours été qu'un "hint", jamais un ordre.

---

Ok je mélange tout.

Mais pas compilateur et CPU (juste une simplification professeur ?) , c'est le compilateur qui traduit les règles définies par les OS pour une architecture donnée.

Mais pas C et C++. Et ai-je dit que register était un ordre ("compilateur...peut allègrement ignorer").?

Une micro structure bien découpée peut passer mais pas une structure de 6 uint8_t (qui pourtant tient dans un seul registre 64 bits). Mettre en avant l'usage des registres sans vouloir prendre en considération tout ce qui les rend inopérants est symptomatique.

Si j'avais écrit que les variables globales c'étaient bien, je pourrais comprendre cette acrimonie. Mais ce n'est pas le cas, j'ai juste évoqué que toute règle appliquée sans discernement était porteuse de problèmes. Celle-là comme d'autres. Caricaturer les propos pour les dénier est un grand classique des dépositaires du "vrai savoir".

Un peu de souplesse et de réflexion sur une règle semble interdit. Dommage.

Salut

Bonjour

Citation:

---

Envoyé par Guesset

Si j'avais écrit que les variables globales c'étaient bien, je pourrais comprendre cette acrimonie. Mais ce n'est pas le cas, j'ai juste évoqué que toute règle appliquée sans discernement était porteuse de problèmes.

---

Moi je suis d'accord. Les outils ont des rôles et les globales ont le leur. C'est les utiliser "juste parce que c'est plus simple" qui amène souvent dans le mur (et c'est je pense l'idée qui a été tentée d'être exprimée ici).
Mais certains de tes arguments contre les pointeurs me semblent aussi exagérés.

Citation:

---

Envoyé par Guesset

Le premier est la lisibilité car cela induit un accroissement du nombre d'arguments qui rend plus difficile de trouver ce qui est propre à la fonction.

---

On peut parfaitement regrouper "plusieurs éléments" dans une structure et passer le (l'unique) pointeur à la fonction => un seul pointeur pour n éléments. Si par exemple on doit gérer le HOME, le dossier de travail, le nom du projet, la version du projet etc (vécu) on met tout ça dans une structure "environnement" et c'est réglé. Et idem si on doit gérer ensuite d'autres notions associatives.

Citation:

---

Envoyé par Guesset

Le second est l'effet de chaîne...

---

Je vois l'idée. Telle info (et pas nécessairement un pointeur) transitera dans 40 fonctions etc. Mais est-ce bien le cas ? Si on en arrive là, peut-être peut-on se demander si le C était vraiment le langage le plus adapté à ce projet...? Quelque part il me semble que le C était surtout fait pour créer des drivers, piloter des contrôleurs etc. Il n'a pas été conçu pour recréer MsOffice. Même parfois (disgression) je vois des trucs comme "faire de l'objet en C" alors ok si c'est pour le fun et pour se faire plaisir car sinon dans la vraie vie, si on veut faire de l'objet alors on prend un langage objet.

Citation:

---

Envoyé par Guesset

Le troisième est la surcharge que cela induit au niveau de la pile.

---

Je pense que ça se recoupe avec l'idée précédente. Mais quoi qu'il en soit oui, aucune solution ne peut venir sans son lots d'inconvénients et le reste n'est qu'une gestion du risque et du coût. De mon point de vue, les globales utilisées hors de leur but premier font prendre plus de risque et amènent généralement plus de soucis (ou peut-être moins de soucis mais des soucis plus chiants à régler) que les pointeurs et les inconvénients que tu cites.

Citation:

---

Envoyé par Guesset

Une micro structure bien découpée peut passer mais pas une structure de 6 uint8_t (qui pourtant tient dans un seul registre 64 bits). Mettre en avant l'usage des registres sans vouloir prendre en considération tout ce qui les rend inopérants est symptomatique.

---

Et pourtant c'est possible. Mais en vrai on s'en fout. Penser qu'éviter quelques opérations de stack fera forcément une grosse différence sur les performances me semblent être une mauvaise idée. Cela relève de la micro optimisation a priori qui sera généralement sans effet.

Citation:

---

Envoyé par Guesset

Un peu de souplesse et de réflexion sur une règle semble interdit. Dommage.

---

Hé ho j'ai proposé de faire des variables globales dans mon premier message dans cette discussion, alors merci de calmer tes ardeurs sur la souplesse des autres ;)

En global !
Par contre il est possible que le micro ait des registres utilisateurs...
Donc éventuellement déclarer comme volatile (donc forcer en RAM) ainsi qu'on peut le faire pour les AtMega (ARDUINO MEGA...).

Pour résoudre la moyenne de la première capture avec une précédente qui n'a pas eu lieu...

Puisque l'on initialise ce qui doit l'être dans setup, rien n'empèche d'y faire, en respectant bien l'ordre des initialisations : precedente = capture.
et dans loop ou dans une interruption (si c'est possble...) : actuelle = capture;
donc :
moyenne = actuelle + precedente / 2;
report dans un tableau ... carte SD, ... transmission ble ...
puis :
precedente = actuelle
...prêt pour la suivante

de telle sorte que ta moyenne sur deux captures est cohérente dès la première capture.