When describing the behavior of an iterator constructed with the
default constructor, the standard (both current and draft) says
"Results of most expressions are undefined for singular
values;[...]".  I presume this is meant to mean "Using singular
values in most expressions is undefined behavior;[...]", but
then why doesn't it say so?  Wouldn't a statement like: "Using a
singular value in an expression except as the left operand of a
simple assignment is undefined behavior."

Or was the intent something else?  Given:

     std::vector< int >  v ;
     std::vector< int >::iterator
                         i1 ;
     if ( i1 == v.end() ) ...

I believe the intent here is undefined behavior (and the authors
of both the Dinkumware and the g++ libraries apparently agree
with me, since both core dump in debugging mode), but the
current wording could be interpreted to mean that it is simply
undefined whether the condition in the if evaluates to true or
false.

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


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 27, 4:57 pm, James Kanze <james.ka...@gmail.com> wrote:
> When describing the behavior of an iterator constructed with the
> default constructor, the standard (both current and draft) says
> "Results of most expressions are undefined for singular
> values;[...]".

[...]

> Wouldn't a statement like: "Using a
> singular value in an expression except as the left operand of a
> simple assignment is undefined behavior."
>

However, if I read the stand/draft correctly, the sentence
you omitted shows the same point :

 Results of most expressions are undefined for singular values;
 the only exception is an assignment of a non-singular value to
 an iterator that holds a singular value.

That is, for valid assignment, using singular values is not
undefined behavior.

Of course, your wording is more readable in my mind.

BTW, it seems like there lacks the formal definition of
"singular" and "non-singular" in 24.1.  Though we have

 Iterators can also have singular values that are not
 associated with any container.

, but can this sentence can be used as definition?

Regards,

Jiang


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 26, 11:57 pm, James Kanze <james.ka...@gmail.com> wrote:
> When describing the behavior of an iterator constructed with the
> default constructor, the standard (both current and draft) says
> "Results of most expressions are undefined for singular
> values;[...]".  I presume this is meant to mean "Using singular
> values in most expressions is undefined behavior;[...]", but
> then why doesn't it say so?  Wouldn't a statement like: "Using a
> singular value in an expression except as the left operand of a
> simple assignment is undefined behavior."

Although the suggested revision is probably clearer than the original
text, I don't see any real change in its meaning. After all, the word
"result" in the existing text is a shorthand for "resulting behavior".
And there are a few other cases in the Standard in which the result is
similarly undefined. For example, in    24.5.3: "The result of operator*
() on an end of stream is undefined." Or    23.2.2.4: "The result is
undefined if 'position' is an iterator in the range[first, last)."
Note, moreover that the Standard in this case states that the
'result'  of the expression (with the singular iterator) is undefined
- not (merely) that  its 'value' is undefined.

The question being raised here (although not by this specific example)
is what does the Standard means by an undefined value anyway? Is an
undefined value the same as an "unspecified" value, or is it an
undefined value one whose calculation engenders undefined behavior?
This question is not merely academic, because, as it turns out, there
are values that are in fact, undefined - according to the Standard.
For example, in the description of valarray::min() - "the value
returned for an array of length 0 is undefined. [   26.3.2.7]" Now in
this case the language does seem unclear. Does a program that calls
calling min() on a zero-length valarray have undefined behavior, or
does it merely receive an unspecified return value from the function
call?

Greg




--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]