Questions générales : size_t, i = i++ ...

Voir le sujet précédent Voir le sujet suivant Aller en bas

Questions générales : size_t, i = i++ ...

Message  Romu' le Ven 6 Fév 2009 - 22:19

Bonsoir en ce vendredi !

J'ai plusieurs questions générales, indépendantes, dont certaines que j'ai oublié en route. Je répondrai à ce message si elles me reviennent.

1. Je cite un passage de ce site concernant size_t :
Notes a écrit:
Il convient pour les tailles, les dimensions de tableau, les index croissants et non négatifs...
J'ai récemment codé un programme simple qui manipule des tableaux. J'ai donc beaucoup utilisé ce type. Néanmoins à un moment donné je devais parcourir le tableau d'un indice donné jusqu'à l'indice 0. J'ai estimé que çe sont des "index décroissants" : j'ai donc utilisé un autre type. Ma question est : pourquoi size_t ne convient pas pour des indices décroissants (mais qui restent positifs, par exemple de 10 à 0) ?

2. Comportement indéterminé :
J'ai pu lire sur le site du zéro (remarque de -ed-) que :
Code:

i = i++;
invoque un comportement indéterminé. Je ne comprend pas pourquoi.
Ca ne tiendrais qu'à moi je dirais que c'est équivalent à (en décomposant vu que l'incrémentation est faite après) :
Code:

i = i;
i++;
et ce code n'a pas l'air de provoquer de comportement indéterminé.
Ca a sans doute un rapport avec le fait qu'on ne sache pas dans quel ordre les opérandes sont évaluées, comme pour :
Code:

/* là je comprend bien pourquoi il y a U.B. */
a[i] = i++;
Mais je ne comprend toujours pas après ça.

J'espère me rappeler de mes autres questions...

Merci d'avance pour les réponses !

Romu'
Bavard
Bavard

Messages : 21
Date d'inscription : 09/07/2008
Age : 27
Localisation : France

Voir le profil de l'utilisateur

Revenir en haut Aller en bas

Re: Questions générales : size_t, i = i++ ...

Message  -ed- le Sam 7 Fév 2009 - 12:16

Romu' a écrit:pourquoi size_t ne convient pas pour des indices décroissants (mais qui restent positifs, par exemple de 10 à 0) ?
Si jamais un -- est appliqué à un indice non signé valant 0, il pend la valeur max du type (ici, (size_t) -1), soit tous les bits à 1, c'est à dire une valeur énorme qui risque de perturber la boucle (while i >= 0), par exemple.

Si on sait parfaitement ce qu'on fait (while (i >0)), c'est sans risque.

Je suis d'accord que ça demanderait une explication plus détaillée. Je vais y réfléchir.

2. Comportement indéterminé :
J'ai pu lire sur le site du zéro (remarque de -ed-) que :
Pour que les choses soient claires, -ed-, c'est moi !
Code:

i = i++;
invoque un comportement indéterminé. Je ne comprend pas pourquoi.
Ca ne tiendrais qu'à moi je dirais que c'est équivalent à (en décomposant vu que l'incrémentation est faite après) :
Code:

i = i;
i++;
et ce code n'a pas l'air de provoquer de comportement indéterminé.
Ca a sans doute un rapport avec le fait qu'on ne sache pas dans quel ordre les opérandes sont évaluées, comme pour :
Code:

/* là je comprend bien pourquoi il y a U.B. */
a[i] = i++;
Mais je ne comprend toujours pas après ça.
Comme tu l'as suggéré, le langage C ne définis pas l'ordre dans lequel les opérandes sont évalués.

Mon compilateur (gcc) me signale 'possible undefined behaviour'

probablement, suite à l'implémentation dans le compilateur de cette remarque (non normative) de la norme (Annexe J) :

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf


J.2 Undefined behavior
[...]
— Between two sequence points, an object is modified more than once, or is modified
and the prior value is read other than to determine the value to be stored (6.5).
qui renvoit au § 6.5 de la norme, qui dit :

6.5 Expressions
1 An expression is a sequence of operators and operands that specifies computation of a
value, or that designates an object or a function, or that generates side effects, or that
performs a combination thereof.
2 Between the previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression.72) Furthermore, the prior value
shall be read only to determine the value to be stored.73)
3 The grouping of operators and operands is indicated by the syntax.74) Except as specified
later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation
of subexpressions and the order in which side effects take place are both unspecified.
4 Some operators (the unary operator ~, and the binary operators <<, >>, &, ^, and |,
collectively described as bitwise operators) are required to have operands that have
integer type. These operators yield values that depend on the internal representations of
integers, and have implementation-defined and undefined aspects for signed types.
5 If an exceptional condition occurs during the evaluation of an expres​sion(that is, if the
result is not mathematically defined or not in the range of representable values for its
type), the behavior is undefined.
6 The effective type of an object for an access to its stored value is the declared type of the
object, if any.75) If a value is stored into an object having no declared type through an
lvalue having a type that is not a character type, then the type of the lvalue becomes the

72) A floating-point status flag is not an object and can be set more than once within an expression.
73) This paragraph renders undefined statement expressions such as
i = ++i + 1;
a[i++] = i;
while allowing
i = i + 1;
a[i] = i;

74) The syntax specifies the precedence of operators in the evaluation of an expression, which is the same
as the order of the major subclauses of this subclause, highest precedence first. Thus, for example, the
expressions allowed as the operands of the binary + operator (6.5.6) are those expressions defined in
6.5.1 through 6.5.6. The exceptions are cast expressions (6.5.4) as operands of unary operators
(6.5.3), and an operand contained between any of the following pairs of operators: grouping
parentheses () (6.5.1), subscripting brackets [] (6.5.2.1), function-call parentheses () (6.5.2.2), and
the conditional operator ?: (6.5.15).
Within each major subclause, the operators have the same precedence. Left- or right-associativity is
indicated in each subclause by the syntax for the expressions discussed therein.
[...]

-ed-
Admin
Admin

Messages : 289
Date d'inscription : 26/05/2008
Age : 60
Localisation : Paris 6eme arrondissement (75, France)

Voir le profil de l'utilisateur http://bien-programmer.fr

Revenir en haut Aller en bas

Re: Questions générales : size_t, i = i++ ...

Message  Romu' le Dim 8 Fév 2009 - 14:08

Tout est clair maintenant, merci !

Romu'
Bavard
Bavard

Messages : 21
Date d'inscription : 09/07/2008
Age : 27
Localisation : France

Voir le profil de l'utilisateur

Revenir en haut Aller en bas

Re: Questions générales : size_t, i = i++ ...

Message  Contenu sponsorisé Aujourd'hui à 15:25


Contenu sponsorisé


Revenir en haut Aller en bas

Voir le sujet précédent Voir le sujet suivant Revenir en haut

- Sujets similaires

 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum