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.

Sylvain <noSpam@mail.net> writes:

| 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 ???

et donc ?

-- Gaby

Sylvain <noSpam@mail.net> writes:

> surtout je ne vois pas ce que serait un *int* "invalide" !!

J'ai donné 3 cas de machines ayant existés où la non initialisation
pourrait fournir un int invalide. Je ne sais pas s'il y a eu des
implémentations de C++ pour ces machines, mais le C++ est conçu pour y
permettre une implémentation sans lui imposer d'initialiser toutes les
variables. On peut aussi parfaitement imaginer une implémentation qui
vérifierait dynamiquement la non utilisation de variables non intialisées.

Une autre source de problèmes, même avec des machines où toutes les
représentations sont valides, ce sont les optimisations. A partir du
moment où le comportement est formellement indéfini, le compilateur peut
supposer qu'il n'arrive pas et laisser ses algorithmes d'optimisation se
comporter n'importe comment si l'hypothèse n'est pas vraie. N'importe
comment, ca peut avoir des effets non causals, ou inconsitants.

int x; //0
for (i = 0; i < 10; ++i) {
if (f(i)) x = g(i);
}
std::cout << x << std::endl; //1
int y;
for (i = 0; i < 10; ++i) {
if (h(i)) { y = p(i); x = q(i); }
}
std::cout << x << " " << y << std::endl; //2

peut parfaitement afficher deux fois des valeurs différentes pour x même si
f(i) et h(i) ne retourne jamais true. Raisonnement pas hors de portée des
techniques d'optimisation actuelles:

x est non initialisé en 0, utilisé en 1 donc on assigne une valeur entre
les deux.

même raisonnement pour y entre 1 et 2. Mais si y est assigné entre 1 et 2,
x l'est aussi, donc x a deux utilisations distinctes (entre 0 et 1 et entre
1 et 2) et donc la valeur de x ne doit pas être conservée après 1, pour
diminuer la pression sur l'allocateur de registre, on introduit une
variable en plus pour ce deuxième intervalle.

L'allocateur fait son boulot et assigne des registres différents à x pour x
entre 0 et 1 et entre 1 et 2. Résultat, deux valeurs différentes pour x
sont affichées.

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

On Feb 27, 7:10 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
> On Wed, 27 Feb 2008 18:56:42 +0100, David Côme <davidc...@wanadoo.fr>:

> >int a; //(1)

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

On peut vouloir le faire si la valeur d'initialization dépend
d'un bloc de code, avec par exemple des if. Mais ce n'est pas
courant, et même dans ce cas-ci, je préfèrerais l'initialiser
avec quelque chose (peut-être 0), simplement pour que le code
soit déterministe, même dans le cas d'erreur plus tard qui fait
qu'on ne l'initialise pas.

> >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.

Dans le meilleur des cas, ça provoquera un core dump. Avec la
plupart des implémentations, en revanche, ça affichera une
valeur numérique non-spécifiée (dans le langage de la norme,
c-à-d même pas garantie d'être la même deux fois de suite).

> 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.

Dans les cas simple, oui. Si par exemple ça, dans le main(),
c'est tout son programme. Dans les cas plus compliqué, je n'y
compterais pas -- si ce bout de code se trouve dans une
fonction, et qu'on a appelé d'autres fonctions avant, ce qu'il
affiche dependrait de ce qu'ont fait ces autres fonctions, d'une
façon assez imprévisible.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Feb 27, 8:47 pm, Jean-Marc Bourguet <j...@bourguet.org> wrote:
> Fabien LE LEZ <grams...@gramster.com> writes:

> > On Wed, 27 Feb 2008 18:56:42 +0100, David Côme
> > <davidc...@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).

Une autre possibilité (qui existe réelement) : l'implémentation
traque les accès, maintient un bit map de ce qui est initialisé,
et ce qui ne l'est pas, et vérifie à chaque accès. (Purify le
fait, par exemple, et le code ci-dessus génèrerait une sortie
d'erreur de la part de Purify.)

[...]
> 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).

À 0, je ne sais pas, mais une machine à usage général est bien
obligé d'y écrire quelque chose, pour des raisons de sécurité.
(La mémoire qui est affectée à mon processus aurait bien pû
appartenir à un processus à toi avant, et en contenir des
données confidentielles.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Feb 28, 2:33 am, Sylvain <noS...@mail.net> wrote:
> 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
> ???

C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Feb 28, 6:25 am, Jean-Marc Bourguet <j...@bourguet.org> wrote:
> Sylvain <noS...@mail.net> writes:

> On peut aussi
> parfaitement imaginer une implémentation qui vérifierait
> dynamiquement la non utilisation de variables non intialisées.

Pas besoin de l'imaginer. Chez la plupart de mes clients, on
interdisait le déployement du code sans qu'il ait tourné sur un
tel système (Purify, en l'occurance). (Je me rappelle le
problème que ça a causé quand on voulait écrire sur disque une
struct avec un char[n] initializé avec strcpy(). Purify râlait
bien qu'on écrivait des octets qui n'avaient pas été
initialisés.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze <james.kanze@gmail.com> writes:

> On Feb 28, 6:25 am, Jean-Marc Bourguet <j...@bourguet.org> wrote:
> > Sylvain <noS...@mail.net> writes:
>
> > On peut aussi
> > parfaitement imaginer une implémentation qui vérifierait
> > dynamiquement la non utilisation de variables non intialisées.
>
> Pas besoin de l'imaginer. Chez la plupart de mes clients, on
> interdisait le déployement du code sans qu'il ait tourné sur un
> tel système (Purify, en l'occurance). (Je me rappelle le
> problème que ça a causé quand on voulait écrire sur disque une
> struct avec un char[n] initializé avec strcpy(). Purify râlait
> bien qu'on écrivait des octets qui n'avaient pas été
> initialisés.)

Purify fait un peu trop pour qu'on puisse le considerer comme part de
l'implementation (je l'ai deja vu raler sur du code genere par le
compilateur sans que rien dans le source ne pose probleme par exemple),
mais je l'avais en tete quand j'ai ecrit cela.

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