Bonjour à tous.
Est ce que ce code à un comportement indéfini ?

//iostream est inclue , ...
int a; //(1)
cout<< a; // (2)

Pour ma part:
Je pense que la valeur de a est indéfinie car (1) créer une variable sur
la pile sans lui affecter de valeur.
Elle prend donc la valeur de ce qui se trouvait avant à cette place.
Il n'y a pas de moyen de connaitre cette valeur. La valeure de a est
indéfini même si certain compilo réalisé une affectation par défaut
(je pense à VC++ en mode débug , on peut confirmer ?)

Par contre la 2eme ligne, elle a un comportement totalement défini.Elle va
afficher la valeur de a, qui peut être n'importe quoi.

Suis-je dans le vrai ?

Merci.

On Wed, 27 Feb 2008 18:56:42 +0100, David Côme <davidcome@wanadoo.fr>:

>int a; //(1)

Jusque-là, pas de problème, même si l'utilité d'un tel code m'échappe.

>cout<< a; // (2)

C'est de toutes façons un comportement indéfini : dans le meilleur des
cas, ça affichera un entier, sans qu'il soit possible d'en prévoir la
valeur à l'avance.

Il me semble que selon la norme, c'est un comportement indéfini tout
court (On ne peut pas du tout prévoir le comportement du code) ;
toutefois, en pratique, je m'attendrais à ce qu'un entier quelconque
soit effectivement affiché. Et il y a même de bonnes chances pour que
ce soit le même à chaque exécution, tant qu'on ne recompile pas.

David Côme a écrit :
> Bonjour à tous.

Bonjour,

> Est ce que ce code à un comportement indéfini ?
>
> //iostream est inclue , ...
> int a; //(1)
> cout<< a; // (2)
>
> Pour ma part:
> Je pense que la valeur de a est indéfinie car (1) créer une variable sur
> la pile sans lui affecter de valeur.
> Elle prend donc la valeur de ce qui se trouvait avant à cette place.
> Il n'y a pas de moyen de connaitre cette valeur. La valeure de a est
> indéfini même si certain compilo réalisé une affectation par défaut
> (je pense à VC++ en mode débug , on peut confirmer ?)
>
> Par contre la 2eme ligne, elle a un comportement totalement défini.Elle
> va afficher la valeur de a, qui peut être n'importe quoi.
>
> Suis-je dans le vrai ?

Si on considère la plupart des implémentations connues, ça donnera en
effet un affichage d'une valeur aléatoire et en effet le comportement
peu changer en mode debug selon les compilateurs.

Cependant, au regard de la norme, ce code est indéfini car accède à une
variable non initialisée (en considérant (1) automatique).

Entre autre, a peut très bien contenir une valeur "invalide" pour le
système ("trap value") qui ferait remarquer au-dit système que la
variable utilisée ne l'est pas d'une manière conforme.

Anthony

On Wed, 27 Feb 2008 19:10:55 +0100, Fabien LE LEZ <gramster@gramster.com>
wrote:

> On Wed, 27 Feb 2008 18:56:42 +0100, David Côme <davidcome@wanadoo.fr>:
>
>> int a; //(1)
>
> Jusque-lÃ, pas de problème, même si l'utilité d'un tel code m'échappe.
>

Ce code n'a pas d'utilité propre. C'est juste pour illustre l'utilisation
d'une variable non initialisée.

>> cout<< a; // (2)
>
> C'est de toutes façons un comportement indéfini : dans le meilleur des
> cas, ça affichera un entier, sans qu'il soit possible d'en prévoir la
> valeur à l'avance.
>
Normal.

> Il me semble que selon la norme, c'est un comportement indéfini tout
> court (On ne peut pas du tout prévoir le comportement du code) ;
Je ne savais pas.

> toutefois, en pratique, je m'attendrais à ce qu'un entier quelconque
> soit effectivement affiché. Et il y a même de bonnes chances pour que
> ce soit le même à chaque exécution, tant qu'on ne recompile pas.
>

Comme moi.

Fabien LE LEZ <gramster@gramster.com> writes:

> On Wed, 27 Feb 2008 18:56:42 +0100, David Côme <davidcome@wanadoo.fr>:
>
> >int a; //(1)
>
> Jusque-là, pas de problème, même si l'utilité d'un tel code m'échappe.
>
> >cout<< a; // (2)
>
> C'est de toutes façons un comportement indéfini : dans le meilleur des
> cas, ça affichera un entier, sans qu'il soit possible d'en prévoir la
> valeur à l'avance.
>
> Il me semble que selon la norme, c'est un comportement indéfini tout
> court (On ne peut pas du tout prévoir le comportement du code) ;

J'ai pas vérifié, mais c'est ce que je pense. En particulier, ça peut être
une valeur déclanchant une exception (trois cas plausibles: la
représentation de ce qui serait -0 sur une machine en complément à 1 ou
grandeur et signe qui n'admet pas de -0; mauvais tags sur une machine où
les valeurs ont un tag; il y a eu une machine n'ayant que des nombres en
virgule flottante, mais où certaines opérations trappaient si une donnée
n'était pas entière).

> toutefois, en pratique, je m'attendrais à ce qu'un entier quelconque soit
> effectivement affiché.

Sur les machines courantes, c'est le comportement le plus vraissemblable.

> Et il y a même de bonnes chances pour que ce soit le même à chaque
> exécution, tant qu'on ne recompile pas.

Ca dépend de ce que tu appelles exécution. Ca ne m'étonnerait pas trop que
ceci

void f(int i) { int k = i; }
void g() { int a; std::cout << a << std::endl; }

int main() {
f(42);
g();
f(36);
g();
}

affiche 42 puis 36.

Et ca dépend aussi du système, tous ne remettent pas toute la mémoire à 0
entre processus (c'est certainement une mauvaise idée de ne pas le faire
sur des machines à usage général).

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/...ite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Anthony Fleury wrote on 27/02/2008 19:29:
>
>> Est ce que ce code à un comportement indéfini ?
>>
>> //iostream est inclue , ...
>> int a; //(1)
>> cout<< a; // (2)
>>
> Entre autre, a peut très bien contenir une valeur "invalide" pour le
> système ("trap value") qui ferait remarquer au-dit système que la
> variable utilisée ne l'est pas d'une manière conforme.

j'ai du mal à saisir la finesse de l'indéfinition.
je ne vois ici qu'une imprévision (non connaissance d'une valeur
aléatoire, ou comment se paraphraser).

surtout je ne vois pas ce que serait un *int* "invalide" !!
vous avez des machines sur lesquelles un int, disons 32 bits, peut
contenir toutes les valuers entières entre 0x00000000 et 0xFFFFFFFF
*plus* d'autres valeurs invalides ???

Sylvain.

Sylvain <noSpam@mail.net> writes:

| Anthony Fleury wrote on 27/02/2008 19:29:
| >
| >> Est ce que ce code à un comportement indéfini ?
| >>
| >> //iostream est inclue , ...
| >> int a; //(1)
| >> cout<< a; // (2)
| >>
| > Entre autre, a peut très bien contenir une valeur "invalide" pour le
| > système ("trap value") qui ferait remarquer au-dit système que la
| > variable utilisée ne l'est pas d'une manière conforme.
|
| j'ai du mal à saisir la finesse de l'indéfinition.
| je ne vois ici qu'une imprévision (non connaissance d'une valeur
| aléatoire, ou comment se paraphraser).
|
| surtout je ne vois pas ce que serait un *int* "invalide" !!
| vous avez des machines sur lesquelles un int, disons 32 bits, peut
| contenir toutes les valuers entières entre 0x00000000 et 0xFFFFFFFF
| *plus* d'autres valeurs invalides ???

So ?

-- Gaby

Gabriel Dos Reis wrote on 27/02/2008 23:37:
> |
> | surtout je ne vois pas ce que serait un *int* "invalide" !!
> | vous avez des machines sur lesquelles un int, disons 32 bits, peut
> | contenir toutes les valuers entières entre 0x00000000 et 0xFFFFFFFF
> | *plus* d'autres valeurs invalides ???
>
> So ?

so, vous avez des machines sur lesquelles un int, disons 32 bits,
peut contenir toutes les valuers entières entre 0x0 et 0xFFFFFFFF
*plus* d'autres valeurs, accessoirement invalides ???

la hiérarchie fr. utilise ISO-8859-1 pas UTF-8.

Sylvain.