Bonjour à tous,
Pouvez vous me dire si ce type de calcul avec une constante, un int et un float est correct, car j'ai un doute que l'on puisse faire ça en C++.
#define coef 0.0014
int var1 = 829;
float var2 = 0;
var2 = var1 * coef;
Serial.println(var2,2);
Merci d'avance
Pour moi c'est correct, tu devrais voir 1.16 sur la console
+1, Le résultat sera bon.
Si var1 et var2 sont des constantes, en C++ je le verrai plutôt comme ça :
constexpr float var2 = 829 * 0.0014;
void setup() {
Serial.begin(115200);
Serial.println(var2, 2);
}
void loop() {
}
Bonne soirée 
Vaut mieux éviter les #define mais oui ça fonctionnerait
Ok merci à vous tous.
J'avais un doute, car j'ai rajouté ce calcul dans un de mes programmes et ça ne plantait pas à la compil, mais ça bloquait le loop du programme.
Je vais donc chercher ailleurs pour trouver l'erreur.
Sinon philippe86220, ce ne sont pas des constantes, je l'avais juste présenté comme ça pour simplifier l'exemple.
J-M-L, oui je l'ai vu en cherchant des infos je vais le modifier avec "const".
constexpr float coef = 0.0014;
int var1 = 829;
float var2 = 0;
void setup() {
Serial.begin(115200);
var2 = var1 * coef;
Serial.println(var2, 2);
}
void loop() {
// put your main code here, to run repeatedly:
}
ça le fait également...
J’avais des amis à la maison du coup je ne reviens que maintenant pour expliquer :
constexpr indique une valeur constante et connue lors de la compilation.
const indique une valeur qui n'est que constante, il n'est pas obligatoire de la connaître lors de la compilation.
Voilà mais personne ne l’utilise (je ne lis aucun code qui l’utilise)…
vous vouliez utiliser :
#define coef 0.0014
Il faut donc utiliser constexpr et non const
Bonne soirée
Merci philippe86220 pour les explications, je commençais justement à m'informer sur le sujet, car je ne connaissais pas "constexpr".
Vous avez raison sur le fond. constexpr a été introduit avec C++11 (une version majeure en 2011) et les vielles habitudes ont la vie dure 
Il faut dire aussi qu’avec notre compilateur (et la majorité des compilateurs) quasiment tout ce qui est calculable à la compilation ou lors de l’optimisation est pré-calculé - c’était des optimisations faciles avant 2011 - et donc pour ce genre de code ça ne change rien.
Une importance théorique est dans l’utilisation dans des contextes qui nécessitent des constantes à la compilation comme les tailles de tableaux, les dimensions de classes, etc., peuvent bénéficier de l’utilisation de constexpr mais comme GCC supporte les tableaux à taille dynamique, pour le programmeur ça ne change pas grand chose.
Un des avantages est plus dans la validation statique du code : L’utilisation de constexpr permet au développeur de fournir une information supplémentaire au compilateur ce qui permet de confirmer certaines propriétés du code à la compilation plutôt qu’à l’exécution ➜ ce qui peut aider à détecter les erreurs dès la phase de compilation plutôt qu’à l’exécution.
Bonjour @J-M-L
Ce sujet a déjà été traité ici :
Bonne journée
En complément de ce qui a été dit plus haut et puisque ça reste dans le cadre du sujet, on trouve encore dans certains codes sur le net par exemple l'utilisation de _BV() :
ici j'écris un blink sur la broche 9 d'un 328p :
#include <util/delay.h>
int main (void)
{
DDRB |= _BV(1); // _BV(1) = Pin 9 du 328p
while (true) {
PORTB |= _BV(1);
_delay_ms(1000);
PORTB &= ~_BV(1);
_delay_ms(1000);
}
return 0;
}
alors que je devrais plutôt écrire entre autre :
#include <util/delay.h>
constexpr byte maPin = (1 << (1)); // Pin 9 du 328p
int main (void)
{
Serial.begin(115200);
DDRB |= maPin;
while (true) {
PORTB |= maPin;
_delay_ms(1000);
PORTB &= ~maPin;
_delay_ms(1000);
}
return 0;
}
Après je me dis que l'on trouve quand même beaucoup de #define dans le domaine de l'électronique. Est-ce qu'on ne pourrait pas adopter le cheminement intellectuel suivant :
De même que l'on oppose à juste titre les c-string aux String pour une meilleure gestion de la mémoire sur les AVR, peut-on opposer les #define aux const et constexpr en gardant constexpr pour les programmes C++ hors programmation des µC (sur les grosses machines et les gros programmes par exemple). Après tout, certes :
Mais je me demande si l'avantage est suffisamment conséquent sur nos petits µC AVR et nos programmes d'autant plus que la plupart des programmeurs continuent a utiliser #define et const plutôt que constexpr est que ça fonctionne ?
Moi même je me surprends parfois à ne pas utiliser constexpr ...
Bonne journée.
pour les bêtes constantes numériques, non. const fait le job
là où ça devient intéressant c'est quand on couple cela à des fonctions
par exemple compilez ceci sur ESP32
const int formuleCompliquee(int x) {
return x * x + 1/x;
}
void setup() {
Serial.begin(115200);
const int x = formuleCompliquee(0); // calculé au run time
Serial.println(x);
}
void loop() {}
la compilation se passe sans souci et votre ESP va planter à l'exécution parce 1/0 crée une erreur
➜ const - Wokwi ESP32, STM32, Arduino Simulator
maintenant écrivons la même chose avec des constexpr
constexpr int formuleCompliquee(int x) {
return x * x + 1/x;
}
void setup() {
Serial.begin(115200);
constexpr int x = formuleCompliquee(0); // calculé à la compilation
Serial.println(x);
}
void loop() {}
ce coup ci le compilateur va essayer d'évaluer formuleCompliquee() pour initialiser x à la compilation et va voir le souci directement et refuser de compiler.
sketch.ino: In function 'void setup()':
sketch.ino:8:38: in 'constexpr' expansion of 'formuleCompliquee(0)'
sketch.ino:2:21: error: '(1 / 0)' is not a constant expression
return x * x + 1/x;
~^~
Error during build: exit status 1
Oui effectivement l’exemple est parlant. Et l’intérêt également.
Merci @J-M-L
Bonne journée
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.