Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #3713

Re: Initializing iterators to one past end() in for loops

Followups directed to: comp.lang.c++

Show all headers | View raw

Noah Roberts wrote:

> On 4/13/2011 8:57 PM, Kai-Uwe Bux wrote:
>> Noah Roberts wrote:
>>
>>> On 4/13/2011 3:32 PM, Kai-Uwe Bux wrote:
>>>> Kai-Uwe Bux wrote:
> 
>>>> Seems, it was the third option:
>>>>
>>>>     [24.1/5] Iterators can also have singular values that are not
>>>>     [associated
>>>>     with any container. [Example: After the declaration of an
>>>>     uninitialized pointer x (as with int* x;), x must always be assumed
>>>>     to have a singular value of a pointer. ] 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. In this case the singular value is overwritten
>>>>     the same way as any other value. Dereferenceable values are always
>>>>     non-singular.
>>>>
>>>> Hence, vec.begin()+1 is not UB (as vec.begin() is non-singular), but
>>>> assigning the resulting singular value to the iterator variable iter is
>>>> UB.
>>>
>>> The problem here though is that if you where interpreting correctly then
>>> pointers could not be iterators since [incrementing past the
>>> past-the-end iterator] is UB.
>>
>> a) Why would that be UB according to my interpretation of [24.1/5]?
> 
> It's not.  It's UB because incrementing a pointer beyond what the
> standard explicitly allows (for example 1 past the end of an array) is
> UB.  Thus if your interpretation of the quoted bits where accurate,
> std::vector<T>::iterator could not be a pointer because past_end_ptr+1
> is not defined, regardless of if its assigned to anything.

Just to make sure, I grok the logic here:

1) For a pointer, past_end_ptr+1 is undefined.

2) According to my interpretation, vec.end()+1 is defined (as long as not 
assigned to anything).

3) Hence: std::vector<T>::iterator could not be a pointer.

I would phrase that point differently: under the proposed interpretation, 
pointers would not satisfy the requirements for random access iterators.


>> c) Why would it be bad if this expression involved UB?
> 
> Practically speaking, most of the time, you probably wouldn't notice any
> unexpected behavior from this particular kind of UB.
> 
>>
>> Exactly. I have a cold, so maybe my brain is not working properly; but
>> the way I read [24.1/5] is as follows:
>>
>>    iterator iter = vec.begin(); // iter holds non-singular value.
>>    vec.begin() + 1;             // vec.begin() is a non-singular operand
>>    iter = vec.begin() + 1;      // if vec is empty, the rhs is singular.
>>                                 // the operation of assignment is UB.
> 
> 24.1/5 isn't actually saying anything about "non-singular values" except
> how assignment of them into previously singular iterators works.  You
> can't use 24.1/5 as evidence that vec.begin() + 1 is defined when
> vec.empty() == true.
>>
>>> It seems
>>> to be quite clearly illustrating that default constructed and
>>> uninitialized iterators can exist but that you'd better not do anything
>>> with them but assign to them from a valid iterator value that actually
>>> iterates something.  Further it isn't allowing for incrementing an
>>> iterator past end().
>>
>> Well, vec.end() is a non-singular value. Hence, the expression
>> vec.end()+1 has a singular _result_ but the operands are non-singular.
>> The way I read
>> [24.1/5] is that the result is defined although singular, i.e., I take
>> [the
>> phrase
>>
>>      Results of most expressions are undefined for singular values
>>
>> to mean "undefined for singular values of the operands".
> 
> To show that it's not defined, we first have to realize that if it's not
> defined by the standard it's as UB as if the standard specifically says
> so.  If you note table 76, r + n is defined in terms of r+= n, which is
> defined in terms of r+n.  r+n is defined in terms of ++r.  The
> precondition for r in this case is that it is dereferenceable (24.1/5.
> Since end() is not, ++end() is not defined.  Since ++end() is not
> defined, neither is end() + n.

This definition in terms of ++r is what I missed. Thanks.

 
> Based on these clauses and tables it would seem to me that the only way
> to get "singular" iterators is to not initialize an iterator.  There's
> no defined way to get one from a non-singular iterator because any
> operation that could create one is not defined to do anything in
> particular by the standard.  In some cases (and I've written them)
> ++end() will crash or do something really stupid like return end().

Yup, seems that way. 


Best,

Kai-Uwe Bux

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Initializing iterators to one past end() in for loops Nikos Chantziaras <realnc@arcor.de> - 2011-04-14 00:38 +0300
  Re: Initializing iterators to one past end() in for loops Leigh Johnston <leigh@i42.co.uk> - 2011-04-13 22:46 +0100
  Re: Initializing iterators to one past end() in for loops Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-04-13 23:48 +0200
    Re: Initializing iterators to one past end() in for loops Leigh Johnston <leigh@i42.co.uk> - 2011-04-13 22:50 +0100
      Re: Initializing iterators to one past end() in for loops Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-04-14 00:23 +0200
        Re: Initializing iterators to one past end() in for loops Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-04-14 00:32 +0200
          Re: Initializing iterators to one past end() in for loops Noah Roberts <dont@email.me> - 2011-04-13 17:16 -0700
            Re: Initializing iterators to one past end() in for loops Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-04-14 05:57 +0200
              Re: Initializing iterators to one past end() in for loops Leigh Johnston <leigh@i42.co.uk> - 2011-04-14 14:29 +0100
                Re: Initializing iterators to one past end() in for loops Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-04-14 17:57 +0200
                Re: Initializing iterators to one past end() in for loops Leigh Johnston <leigh@i42.co.uk> - 2011-04-14 17:56 +0100
                Re: Initializing iterators to one past end() in for loops Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-04-14 19:33 +0200
              Re: Initializing iterators to one past end() in for loops Noah Roberts <dont@email.me> - 2011-04-14 09:54 -0700
                Re: Initializing iterators to one past end() in for loops Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-04-14 20:08 +0200
  Re: Initializing iterators to one past end() in for loops gwowen <gwowen@gmail.com> - 2011-04-13 14:49 -0700
  Re: Initializing iterators to one past end() in for loops Sam <sam@email-scan.com> - 2011-04-13 16:58 -0500
  Re: Initializing iterators to one past end() in for loops Nikos Chantziaras <realnc@arcor.de> - 2011-04-14 01:07 +0300
    Re: Initializing iterators to one past end() in for loops Ian Collins <ian-news@hotmail.com> - 2011-04-14 10:12 +1200
    Re: Initializing iterators to one past end() in for loops gwowen <gwowen@gmail.com> - 2011-04-13 15:24 -0700
    Re: Initializing iterators to one past end() in for loops Paavo Helde <myfirstname@osa.pri.ee> - 2011-04-13 23:05 -0500
      Re: Initializing iterators to one past end() in for loops Ian Collins <ian-news@hotmail.com> - 2011-04-14 16:20 +1200
        Re: Initializing iterators to one past end() in for loops Paavo Helde <myfirstname@osa.pri.ee> - 2011-04-13 23:52 -0500
        Re: Initializing iterators to one past end() in for loops Jeff Flinn <TriumphSprint2000@hotmail.com> - 2011-04-14 07:49 -0400
      Re: Initializing iterators to one past end() in for loops Nikos Chantziaras <realnc@arcor.de> - 2011-04-14 21:45 +0300

csiph-web