C : plusieurs noms pour une même variable

Salut

ton #define buzzer RC2 va remplacer tout tes buzzer par RC2 à la compilation donc ce sera seulement peut etre plus compréhensible mais je dirais pas que c'est portable

tu peux très bien faire comme l'exemple qu'on t as donnée en C++ seulement en C la reference n'existe pas et il me semble que ca en est, par contre tu peux utiliser les pointeur seulement pour initialiser au début :

int buzzer;
&buzzer = &RC2;

si c'est une compilation croisée et que ton RC2 est déclaré dans un autre fichier C
tu as juste a ajouter
extern int RC2;

@Pierre Richard&buzzer = &RC2;
ça ne devrais pas compiler, tu ne peux pas modifier l'adresse d'une telle variable normalement.
Sinon, tu peux utiliser une fonction pour la lecture : int buzzer(){return RC2;}
en C++, tu pourrai faire en lecture écriture avec int& buzzer(){return RC2;}
Je ne comprends pas pourquoi il n'y a pas ce passage par référence en C alors que c'est le cas dans les autre langages (C++, pascal, Fortran), bien qu'il est clair que c'est plus rigoureux en C (en effet, sinon comment savoir si f(x) modifie ou non x ?).

@Char SnipeurDsl Char Sniper a raison, tu peux pas faire, il y a en effet une erreur a la compilation
&buzzer = &RC2;

il faut déclarer buzzer en pointeur par ex :
int RC2;
int * buzzer = &RC2;

mais apres il faut ecrire *buzzer a chaque fois que tu veux utiliser/modifier la valeur et non le pointeur

*buzzer = 10;
printf("buzzer = %d", *buzzer);

Ben en C il y a les pointeur est c tout f(x) ne modifie pas la variable x a moins que ce soit un pointeur et qu'il modifie x dans f bien sur. car on peut passer des pointeurs pour gagner de la place sans pr autant modifier x. Apres on peux expliciter qu'on ne modifie pas la variable avec const ...

oui mais avec cette solution je gère un pointeur. Donc je passe de RC2 à *Buzzer. C'est moins propre.

Mais je ne suis pas sûr que le C++ soit génial pour un microcontrolleur. Enfin, encore que...

@kilianCe que je disais, c'est que j'avais des doutes sur la compatibilité C de cette déclaration, mais si tu dit que c'est réservé au C++, alors il ne faut pas l'utiliser.
C'est la seule procédure que je vois pour contrôler l'adresse d'une variable non alloué avec new. Le #define est une solution, mais pas très propre, les macros entraînes des erreurs à la con, et il vaut mieux les éviter au maximum !

@Char SnipeurEn fait oui le define est la seule solution à son problème. Les références n'existent pas en C.
Donc rien à faire sinon du crade.

@Char SnipeurMerci pour votre aide sur le sujet.

Pour info je reste avec mon #define qui marche niquel. Je n'avais jamais entendu que ce n'était pas propre et au contraire. Dans l'embarqué c'est très utilisé et ça permet de gagner énormément de temps quand un paramètre change. Et puis ça ne m'a jamais posé de problème de compilation avec mplab ou codewarrior par exemple.

Et la dans mon cas précis ça facilitera belle et bien la portabilité puisqu'il suffira de remplacer RC2 par le nouveau port si je change de plateforme.

Et dernier point ça améliore grandement la lisibilité.

A+

@benoitgNon t'inquiète ce n'est pas une solution crade. C'est une solution tout court.
Une solution crade c'est quand il y a de la bidouille. Là, c'est fait pour. Après effectivement, il peut y avoir des erreurs bêtes, mais ça c'est parce que l'utilisateur s'en est mal servi (je pense notamment à l'utilisation du point virgule dans le define ^^).
Sinon par contre en C, au lieu d'utiliser les macros, c'est mieux d'utiliser les fonctions inline.
Cdlt

Et surtout il y a une vérification de type avec les fonctions inline, chose que ne font pas les macros.

En terme de maintenance ?
Faut savoir faire la part des choses. Tout coder en macro, effectivement c'est illisible. Par contre utiliser des define pour définir une constante (#define MAX 50), ça c'est tip top (surtout en C, norme 89) Après, il y a d'autres cas où c'est bien pratique (comme le guard, etc).

C'est pas "mieux" d'utiliser les macros c'est juste que la fonction inline fait comme une macro et que c'est plus agréable à lire
Les fonctions inline sont mieux que les macros dans le sens que le compilateur les gère mieux. Dans une macro, le contrôle des types n'existe pas par exemple. Donc, ce n'est pas juste une question de lisibilité.

pour la maintenance, c'est une plaie les macro, en effet. Pour llustrer, ce qui m'est arriver : windows.h contient "#define IN" et le source que j'essayais de compiler "int IN" et forcément, ça génère une erreur, qui n'est pas du tout évidente à trouver !!!
Pour utiliser les nom de macro, je te conseil de les nommé en majuscule et avec un "_" devant, soit "_BUZZER_" pour ton cas.
Le goto, je li partout que c'est vraiment à éviter.
La fonction inline est vraiment mieux, la macro peut entrainer des erreurs vraiment chiante. Par exemple prenons la macro fonction :
#define SQR(x) x*x
Si dans le code source tu fais :
SQR(1+2) le résultat sera 5 (et non 9), car le préprocesseur écrira : 1+2*1+2
C'est pour ces raisons que j'évite au maximum de mélanger ce qui est dans les macros avec ce qui est dans le source, surtout que bien souvent il est possible de faire autrement.

@kilianEt, je ne peux même pas dire copieur car t'as posté avant moi :s

@Char SnipeurEh oui, les macro, c'est pas terrible pour ça lol. Vive l'inline :d
Les goto, c'est à éviter d'une manière générale car algorithmiquement moche, et illisible.
Mais il y a des cas, ou c'est bien plus joli. Notamment pour la gestion d'erreurs. Faut juste éviter le code spaghetti ^^.

Ah oui tout à fait j'ai jamais dit le contraire...