La norme ne parle pas de variable locale/globale mais y-a-t-il un usage admis ?
La norme ne parle pas de variable locale/globale mais y-a-t-il un usage admis ?
La norme ne parle pas de variable locale/globale mais y-a-t-il un usage admis ?
candide écrivit :La norme ne parle pas de variable locale/globale mais y-a-t-il un
usage admis ?
Quant tu parles de variables, te réfères-tu à l'objet (la case mémoire)
ou au nom (identificateur) qui sert à le désigner ?
candide écrivit :
La norme ne parle pas de variable locale/globale mais y-a-t-il un
usage admis ?
Quant tu parles de variables, te réfères-tu à l'objet (la case mémoire)
ou au nom (identificateur) qui sert à le désigner ?
candide écrivit :La norme ne parle pas de variable locale/globale mais y-a-t-il un
usage admis ?
Quant tu parles de variables, te réfères-tu à l'objet (la case mémoire)
ou au nom (identificateur) qui sert à le désigner ?
Bonjour,
Êtes-vous d'accord avec la définition suivante :
"Pour qu'une variable soit locale (ou automatique) il faut que sa portée soit
locale ainsi que sa persistance. "
?
La norme ne parle pas de variable locale/globale mais y-a-t-il un usage admis ?
Bonjour,
Êtes-vous d'accord avec la définition suivante :
"Pour qu'une variable soit locale (ou automatique) il faut que sa portée soit
locale ainsi que sa persistance. "
?
La norme ne parle pas de variable locale/globale mais y-a-t-il un usage admis ?
Bonjour,
Êtes-vous d'accord avec la définition suivante :
"Pour qu'une variable soit locale (ou automatique) il faut que sa portée soit
locale ainsi que sa persistance. "
?
La norme ne parle pas de variable locale/globale mais y-a-t-il un usage admis ?
Il me semble que dans la pratique quand on parle de variable on fait allusion à
l'identificateur, enfin , je ne parle pas de MON usage, mais de l'usage commun.
Il me semble que dans la pratique quand on parle de variable on fait allusion à
l'identificateur, enfin , je ne parle pas de MON usage, mais de l'usage commun.
Il me semble que dans la pratique quand on parle de variable on fait allusion à
l'identificateur, enfin , je ne parle pas de MON usage, mais de l'usage commun.
Et pour cause car c'est ambigu.
Il faut distinguer la classe d'allocation mémoire (auto, static, extern,
const, etc.)
et la visibilité (le scope) car si je déclare, par exemple,
une variable "static" à l'intérieur d'une fonction, je ne pourrai
l'utiliser que dans cette fonction mais elle sera allouée avant la
première instruction exécutable du programme principal (main).
Et pour cause car c'est ambigu.
Il faut distinguer la classe d'allocation mémoire (auto, static, extern,
const, etc.)
et la visibilité (le scope) car si je déclare, par exemple,
une variable "static" à l'intérieur d'une fonction, je ne pourrai
l'utiliser que dans cette fonction mais elle sera allouée avant la
première instruction exécutable du programme principal (main).
Et pour cause car c'est ambigu.
Il faut distinguer la classe d'allocation mémoire (auto, static, extern,
const, etc.)
et la visibilité (le scope) car si je déclare, par exemple,
une variable "static" à l'intérieur d'une fonction, je ne pourrai
l'utiliser que dans cette fonction mais elle sera allouée avant la
première instruction exécutable du programme principal (main).
Antoine Leca a écrit :candide écrivit :La norme ne parle pas de variable locale/globale mais y-a-t-il un
usage admis ?
Quant tu parles de variables, te réfères-tu à l'objet (la case mémoire)
ou au nom (identificateur) qui sert à le désigner ?
[...] quand on parle de variable on fait allusion à l'identificateur [...]
Antoine Leca a écrit :
candide écrivit :
La norme ne parle pas de variable locale/globale mais y-a-t-il un
usage admis ?
Quant tu parles de variables, te réfères-tu à l'objet (la case mémoire)
ou au nom (identificateur) qui sert à le désigner ?
[...] quand on parle de variable on fait allusion à l'identificateur [...]
Antoine Leca a écrit :candide écrivit :La norme ne parle pas de variable locale/globale mais y-a-t-il un
usage admis ?
Quant tu parles de variables, te réfères-tu à l'objet (la case mémoire)
ou au nom (identificateur) qui sert à le désigner ?
[...] quand on parle de variable on fait allusion à l'identificateur [...]
Wykaaa a écrit :Et pour cause car c'est ambigu.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)Il faut distinguer la classe d'allocation mémoire (auto, static, extern,
const, etc.)
const n'est pas une classe de mémorisation.
réfèretait-il pas plutôt à la syntaxe du langage C et se distinguant ainsi de la
"durée de mémorisation" (je crois qu'ici certains disent "persistance", dans la
Norme "storage duration" je pense) ?
et la visibilité (le scope) car si je déclare, par exemple,
une variable "static" à l'intérieur d'une fonction, je ne pourrai
l'utiliser que dans cette fonction mais elle sera allouée avant la
première instruction exécutable du programme principal (main).
Mais si j'ai le code
while (1)
{
static int a[5];
int x;
extern int y;
/* code */
}
qu'est-il d'_usage_ (dans les "milieux autorisés" dont je ne fais pas partie) de
qualifier de variables locales ?
Wykaaa a écrit :
Et pour cause car c'est ambigu.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern,
const, etc.)
const n'est pas une classe de mémorisation.
réfèretait-il pas plutôt à la syntaxe du langage C et se distinguant ainsi de la
"durée de mémorisation" (je crois qu'ici certains disent "persistance", dans la
Norme "storage duration" je pense) ?
et la visibilité (le scope) car si je déclare, par exemple,
une variable "static" à l'intérieur d'une fonction, je ne pourrai
l'utiliser que dans cette fonction mais elle sera allouée avant la
première instruction exécutable du programme principal (main).
Mais si j'ai le code
while (1)
{
static int a[5];
int x;
extern int y;
/* code */
}
qu'est-il d'_usage_ (dans les "milieux autorisés" dont je ne fais pas partie) de
qualifier de variables locales ?
Wykaaa a écrit :Et pour cause car c'est ambigu.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)Il faut distinguer la classe d'allocation mémoire (auto, static, extern,
const, etc.)
const n'est pas une classe de mémorisation.
réfèretait-il pas plutôt à la syntaxe du langage C et se distinguant ainsi de la
"durée de mémorisation" (je crois qu'ici certains disent "persistance", dans la
Norme "storage duration" je pense) ?
et la visibilité (le scope) car si je déclare, par exemple,
une variable "static" à l'intérieur d'une fonction, je ne pourrai
l'utiliser que dans cette fonction mais elle sera allouée avant la
première instruction exécutable du programme principal (main).
Mais si j'ai le code
while (1)
{
static int a[5];
int x;
extern int y;
/* code */
}
qu'est-il d'_usage_ (dans les "milieux autorisés" dont je ne fais pas partie) de
qualifier de variables locales ?
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la
traiter différemment en l'allouant en mémoire non écrivible.
Typiquement, sur une machine à segments mémoire, les variables const
seront allouées dans un segment "unwritable".
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la
traiter différemment en l'allouant en mémoire non écrivible.
Typiquement, sur une machine à segments mémoire, les variables const
seront allouées dans un segment "unwritable".
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la
traiter différemment en l'allouant en mémoire non écrivible.
Typiquement, sur une machine à segments mémoire, les variables const
seront allouées dans un segment "unwritable".
Cependant, que le compilateur utilise des segments invariables pour
des variables constantes me parait bizarre. Cela signifierait qu'il est
illégal de transtyper une variable constante en son pendant variable, et
de l'utiliser en tant que tel. On constatera aussi que le C++,
particulièrement influencé par le C, propose un opérateur de transtypage
dédié à ce genre d'opérations const_cast<>, ce qui va dans le sens de ma
compréhension de l'usage des variables constantes : la constance d'une
variable est une protection supplémentaire pour aider le programmeur
dans son travail, et non une barrière absolue.
Cependant, que le compilateur utilise des segments invariables pour
des variables constantes me parait bizarre. Cela signifierait qu'il est
illégal de transtyper une variable constante en son pendant variable, et
de l'utiliser en tant que tel. On constatera aussi que le C++,
particulièrement influencé par le C, propose un opérateur de transtypage
dédié à ce genre d'opérations const_cast<>, ce qui va dans le sens de ma
compréhension de l'usage des variables constantes : la constance d'une
variable est une protection supplémentaire pour aider le programmeur
dans son travail, et non une barrière absolue.
Cependant, que le compilateur utilise des segments invariables pour
des variables constantes me parait bizarre. Cela signifierait qu'il est
illégal de transtyper une variable constante en son pendant variable, et
de l'utiliser en tant que tel. On constatera aussi que le C++,
particulièrement influencé par le C, propose un opérateur de transtypage
dédié à ce genre d'opérations const_cast<>, ce qui va dans le sens de ma
compréhension de l'usage des variables constantes : la constance d'une
variable est une protection supplémentaire pour aider le programmeur
dans son travail, et non une barrière absolue.
Wykaaa a écrit :const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la
traiter différemment en l'allouant en mémoire non écrivible.
Typiquement, sur une machine à segments mémoire, les variables const
seront allouées dans un segment "unwritable".
Je pense que tu généralises trop. De toute façon, je pense aussi qu'on
est parti du mauvais pied sur cette discussion. Vous parlez tous sans
jamais préciser le contexte de déclaration des variables, alors que
c'est certainement ce qu'il y a de plus important.
Qu'une variable globale, c'est à dire une variable déclarée au niveau
d'une unité de compilation, déclarée const soit placée par le
compilateur dans un segment protégé en écriture, je suis d'accord. Et
c'est ce que je m'attends à ce que le compilateur fasse. Même si je m'en
fou, et que l'important est que la constance de la variable soit
contrôlée à la compilation. Mais pour une variable locale normale (pas
déclarée static), c'est à dire déclarée dans un flux d'exécution, je ne
vois pas pourquoi le compilateur s'embêterait à allouer de la mémoire
dans un segment constant. Pour la simple et bonne raison que les
variables locales sont allouées sur la pile et non sur le tas.
À moins que je n'ai pas compris une subtilité.
Cependant, que le compilateur utilise des segments invariables pour
des variables constantes me parait bizarre. Cela signifierait qu'il est
illégal de transtyper une variable constante en son pendant variable, et
de l'utiliser en tant que tel. On constatera aussi que le C++,
particulièrement influencé par le C, propose un opérateur de transtypage
dédié à ce genre d'opérations const_cast<>, ce qui va dans le sens de ma
compréhension de l'usage des variables constantes : la constance d'une
variable est une protection supplémentaire pour aider le programmeur
dans son travail, et non une barrière absolue.
Enfin bref, un exemple pour aider à clore le débat me semble
nécessaire. N'étant pas un programmeur très expérimenté, il e peut que
le code suivant agrémenté de commentaires soit imprécis, et manque
d'exhaustivité. J'invite les participant à me corriger (gentillement) et
à compléter :
== scope.c = >
/* En considérant les abréviations :
* - Segment de Données Statiques SDS
* - Segment de Données Globales SDG
*
* Les variables globales et statiques on un espace mémoire réservé
* alloué (et initialisé à 0) au chargement de l'exécutable
*
* Les variables locales sont allouée lors de l'entrée dans le bloc
* d'exécution dans lequel elles sont déclarées, et ne sont pas
* initialisées.
*/
int g ; /* portée globale au programme, alloué dans le SDG */
static int gs ; /* portée globale à l'unité de compilation,
* alloué dans le SDG (ou SDS ?)
*/
int /* portée inexistante, allouée sur la pile */
main
( int argc /* portée locale à la fonction, allouée sur la pile */
, char ** argv
)
{
int l ; /* portée locale à la fonction, allouée
* sur la pile
*/
static ls ; /* portée locale à la fonction, allouée
* dans le SDS
*/
{
int lb ; /* portée locale au bloc, allouée sur la
* pile
*/
}
return 0 ;
}
============ >
Par contre, qu'est-ce que vous entendez par variable auto ? Le seul
endroit où j'ai entendu parlé d'un tel modificateur c'est en C++. Et ça
n'a rien à voir avec la portée ^^;
Wykaaa a écrit :
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la
traiter différemment en l'allouant en mémoire non écrivible.
Typiquement, sur une machine à segments mémoire, les variables const
seront allouées dans un segment "unwritable".
Je pense que tu généralises trop. De toute façon, je pense aussi qu'on
est parti du mauvais pied sur cette discussion. Vous parlez tous sans
jamais préciser le contexte de déclaration des variables, alors que
c'est certainement ce qu'il y a de plus important.
Qu'une variable globale, c'est à dire une variable déclarée au niveau
d'une unité de compilation, déclarée const soit placée par le
compilateur dans un segment protégé en écriture, je suis d'accord. Et
c'est ce que je m'attends à ce que le compilateur fasse. Même si je m'en
fou, et que l'important est que la constance de la variable soit
contrôlée à la compilation. Mais pour une variable locale normale (pas
déclarée static), c'est à dire déclarée dans un flux d'exécution, je ne
vois pas pourquoi le compilateur s'embêterait à allouer de la mémoire
dans un segment constant. Pour la simple et bonne raison que les
variables locales sont allouées sur la pile et non sur le tas.
À moins que je n'ai pas compris une subtilité.
Cependant, que le compilateur utilise des segments invariables pour
des variables constantes me parait bizarre. Cela signifierait qu'il est
illégal de transtyper une variable constante en son pendant variable, et
de l'utiliser en tant que tel. On constatera aussi que le C++,
particulièrement influencé par le C, propose un opérateur de transtypage
dédié à ce genre d'opérations const_cast<>, ce qui va dans le sens de ma
compréhension de l'usage des variables constantes : la constance d'une
variable est une protection supplémentaire pour aider le programmeur
dans son travail, et non une barrière absolue.
Enfin bref, un exemple pour aider à clore le débat me semble
nécessaire. N'étant pas un programmeur très expérimenté, il e peut que
le code suivant agrémenté de commentaires soit imprécis, et manque
d'exhaustivité. J'invite les participant à me corriger (gentillement) et
à compléter :
== scope.c = >
/* En considérant les abréviations :
* - Segment de Données Statiques SDS
* - Segment de Données Globales SDG
*
* Les variables globales et statiques on un espace mémoire réservé
* alloué (et initialisé à 0) au chargement de l'exécutable
*
* Les variables locales sont allouée lors de l'entrée dans le bloc
* d'exécution dans lequel elles sont déclarées, et ne sont pas
* initialisées.
*/
int g ; /* portée globale au programme, alloué dans le SDG */
static int gs ; /* portée globale à l'unité de compilation,
* alloué dans le SDG (ou SDS ?)
*/
int /* portée inexistante, allouée sur la pile */
main
( int argc /* portée locale à la fonction, allouée sur la pile */
, char ** argv
)
{
int l ; /* portée locale à la fonction, allouée
* sur la pile
*/
static ls ; /* portée locale à la fonction, allouée
* dans le SDS
*/
{
int lb ; /* portée locale au bloc, allouée sur la
* pile
*/
}
return 0 ;
}
============ >
Par contre, qu'est-ce que vous entendez par variable auto ? Le seul
endroit où j'ai entendu parlé d'un tel modificateur c'est en C++. Et ça
n'a rien à voir avec la portée ^^;
Wykaaa a écrit :const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la
traiter différemment en l'allouant en mémoire non écrivible.
Typiquement, sur une machine à segments mémoire, les variables const
seront allouées dans un segment "unwritable".
Je pense que tu généralises trop. De toute façon, je pense aussi qu'on
est parti du mauvais pied sur cette discussion. Vous parlez tous sans
jamais préciser le contexte de déclaration des variables, alors que
c'est certainement ce qu'il y a de plus important.
Qu'une variable globale, c'est à dire une variable déclarée au niveau
d'une unité de compilation, déclarée const soit placée par le
compilateur dans un segment protégé en écriture, je suis d'accord. Et
c'est ce que je m'attends à ce que le compilateur fasse. Même si je m'en
fou, et que l'important est que la constance de la variable soit
contrôlée à la compilation. Mais pour une variable locale normale (pas
déclarée static), c'est à dire déclarée dans un flux d'exécution, je ne
vois pas pourquoi le compilateur s'embêterait à allouer de la mémoire
dans un segment constant. Pour la simple et bonne raison que les
variables locales sont allouées sur la pile et non sur le tas.
À moins que je n'ai pas compris une subtilité.
Cependant, que le compilateur utilise des segments invariables pour
des variables constantes me parait bizarre. Cela signifierait qu'il est
illégal de transtyper une variable constante en son pendant variable, et
de l'utiliser en tant que tel. On constatera aussi que le C++,
particulièrement influencé par le C, propose un opérateur de transtypage
dédié à ce genre d'opérations const_cast<>, ce qui va dans le sens de ma
compréhension de l'usage des variables constantes : la constance d'une
variable est une protection supplémentaire pour aider le programmeur
dans son travail, et non une barrière absolue.
Enfin bref, un exemple pour aider à clore le débat me semble
nécessaire. N'étant pas un programmeur très expérimenté, il e peut que
le code suivant agrémenté de commentaires soit imprécis, et manque
d'exhaustivité. J'invite les participant à me corriger (gentillement) et
à compléter :
== scope.c = >
/* En considérant les abréviations :
* - Segment de Données Statiques SDS
* - Segment de Données Globales SDG
*
* Les variables globales et statiques on un espace mémoire réservé
* alloué (et initialisé à 0) au chargement de l'exécutable
*
* Les variables locales sont allouée lors de l'entrée dans le bloc
* d'exécution dans lequel elles sont déclarées, et ne sont pas
* initialisées.
*/
int g ; /* portée globale au programme, alloué dans le SDG */
static int gs ; /* portée globale à l'unité de compilation,
* alloué dans le SDG (ou SDS ?)
*/
int /* portée inexistante, allouée sur la pile */
main
( int argc /* portée locale à la fonction, allouée sur la pile */
, char ** argv
)
{
int l ; /* portée locale à la fonction, allouée
* sur la pile
*/
static ls ; /* portée locale à la fonction, allouée
* dans le SDS
*/
{
int lb ; /* portée locale au bloc, allouée sur la
* pile
*/
}
return 0 ;
}
============ >
Par contre, qu'est-ce que vous entendez par variable auto ? Le seul
endroit où j'ai entendu parlé d'un tel modificateur c'est en C++. Et ça
n'a rien à voir avec la portée ^^;