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

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

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 3:32 PM, Kai-Uwe Bux wrote:
>> Kai-Uwe Bux wrote:
>>
>>> Leigh Johnston wrote:
>>>
>>>> On 13/04/2011 22:48, Kai-Uwe Bux wrote:
>>>>> Nikos Chantziaras wrote:
>>>>>
>>>>>> Is there some simple way to convert this:
>>>>>>
>>>>>>      std::vector<int>   vec;
>>>>>>      // ...
>>>>>>      for (size_t i = 1; i<   vec.size(); ++i)
>>>>>>          // do something with vec[i]
>>>>>>
>>>>>> to a for-loop that uses iterators?  I've tried:
>>>>>>
>>>>>>      typedef std::vector<int>::iterator it_t;
>>>>>>      for (it_t i = vec.begin() + 1; i != vec.end(); ++i)
>>>>>>          // do something with *i
>>>>>>
>>>>>> but I'm not surprised that it doesn't work.
>>>>>
>>>>> Iterators for std::vector<>   are random access. Hence, they
>>>>> are<-comparable and you can add integers to them. So, you should be
>>>>> able to translate one- to-one:
>>>>>
>>>>>     for ( std::vector<int>::iterator iter = vec.begin() + 1;
>>>>>           iter<   vec.end(); ++ iter ) {
>>>>>       // do something with *iter
>>>>>     }
>>>>
>>>> If the vector is empty then surely vec.begin() + 1 is UB?
>>>
>>> Hm, my first impulse was to say: "oh, true; that kills it". However,
>>> upon looking up table 76 in the standard, it appears that
>>>
>>>    r += n
>>>
>>> has no pre-condition (like r is dereferencable). Now, r+n is defined in
>>> terms of r += n. Also, the dereferencability precondition is mentioned
>>> at other places (e.g., for ++r in table 74 about forward iterators). So,
>>> maybe vec.begin()+1 is not undefined behavior after all. Of course, it
>>> could also be an omission in the standard, or it could be that I am too
>>> tired to figure it out correctly.
>>
>> 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 (arr + sizeof(arr))++ is UB.

a) Why would that be UB according to my interpretation of [24.1/5]?
b) It seems UB for iterators according to table 74: r++ is defined in terms 
of ++r which needs r to be dereferencable.
c) Why would it be bad if this expression involved UB?
d) Is sizeof(arr) really what you mean?

> Luckily I believe you're interpreting incorrectly.  The quote you show
> there quite explicitly calls "most expressions are undefined...".  The
> only exception it provides is assignment FROM a non-singular.

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.

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


Something that also stirs up my curiosity is whether destructing an iterator 
object that holds a singular value is UB.


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