pfffffrrrrt@gmx.de (dmoos AT esigma-systems DOT de) wrote in message news:<c1537n$1dik0i$1@ID-193014.news.uni-berlin.de>...
> Hi,
>
> is it guaranteed that the order and offset of vector-elements
> does not change when doing a push_back() ?
>
> When erasing a vector-element, is it guaranteed, that the order
> and offset of the elements up to the one erased does not change ?
>
> Is it guaranteed, that the order and offset of vector-elements
> is the same in the destination when assigning vectors ?
>
> Any help, hints, pointers are highly appreciated.
>
> Thanks in advance for all your help.
>
> Darius.
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]


Yes, a Defect Report has clarified the situation. The offset
&v[n]-&v[0] must always be n, for any valid v[n] - just like
an array. Apparently everybody just "knew" this and nobody
noticed that the standard technically didn't require this,
until it was published.

Regards,
--
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 01 Mar 2004 18:05:37 +0100, Michiel Salters wrote:
> pfffffrrrrt@gmx.de (dmoos AT esigma-systems DOT de) wrote in message
> news:<c1537n$1dik0i$1@ID-193014.news.uni-berlin.de>...
>> is it guaranteed that the order and offset of vector-elements does not
>> change when doing a push_back() ?
>> When erasing a vector-element, is it guaranteed, that the order and
>> offset of the elements up to the one erased does not change ?
>> Is it guaranteed, that the order and offset of vector-elements is the
>> same in the destination when assigning vectors ?
>
> Yes, a Defect Report has clarified the situation. The offset &v[n]-&v[0]
> must always be n, for any valid v[n] - just like an array. Apparently
> everybody just "knew" this and nobody noticed that the standard
> technically didn't require this, until it was published.

Do you have a link/pointer to the mentioned defect report ?

Thanks in advance,

Darius.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michiel.Salters@cmg.nl (Michiel Salters) wrote in message news:<cefd6cde.0403010848.233003cf@posting.google.com>...
> pfffffrrrrt@gmx.de (dmoos AT esigma-systems DOT de) wrote in message news:<c1537n$1dik0i$1@ID-193014.news.uni-berlin.de>...

I think that you referred to an important issue, but not the one
raised by the OP. I'll illustrate what I think he's talking about with
test code.

> > Hi,
> >
> > is it guaranteed that the order and offset of vector-elements
> > does not change when doing a push_back() ?

#include <vector>
#include <algorith>

// a is a std::vector<T>, non-empty.
T *backup = new T[a.size()];
std::copy(a.start(),a.end(),backup);
a.push_back(t);
if(std::equal(a.start(),a.end()-1,backup)
   ;// not explicitly guaranteed

> > When erasing a vector-element, is it guaranteed, that the order
> > and offset of the elements up to the one erased does not change ?

// i is an iterator into 'a', which does NOT point at a[0]
std::vector<T>::iterator last_safe = i-1;
a.erase(i);
if(std::equal(a.start(), last_safe, backup))
    ; // not explicity guaranteed

> > Is it guaranteed, that the order and offset of vector-elements
> > is the same in the destination when assigning vectors ?

// r refers to another std::vector<T>
r = a;
if(u==a)
    ; // This one is explicitly guaranteed as a post-condition
    // on r=a

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 2 Mar 2004 23:33:55 +0000 (UTC), kuyper@wizard.net (James
Kuyper) wrote:

>Michiel.Salters@cmg.nl (Michiel Salters) wrote in message news:<cefd6cde.0403010848.233003cf@posting.google.com>...
>> pfffffrrrrt@gmx.de (dmoos AT esigma-systems DOT de) wrote in message news:<c1537n$1dik0i$1@ID-193014.news.uni-berlin.de>...
>
>I think that you referred to an important issue, but not the one
>raised by the OP. I'll illustrate what I think he's talking about with
>test code.
>
>> > Hi,
>> >
>> > is it guaranteed that the order and offset of vector-elements
>> > does not change when doing a push_back() ?
>
>#include <vector>
>#include <algorith>
>
>// a is a std::vector<T>, non-empty.
>T *backup = new T[a.size()];
>std::copy(a.start(),a.end(),backup);
>a.push_back(t);
>if(std::equal(a.start(),a.end()-1,backup)
>   ;// not explicitly guaranteed

if a.size() < a.capacity(), the guarantee does exist.
This follows from the requirement that the iterators and references to
elements in the vector are not invalidated.
Unless the implementation is capable of updating all possible
references and iterators, including those that are temporarily stored
elsewhere, the location of elements of the vector can not be changed.

Bart v Ingen Schenau

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bart.van.Ingen.Schenau@ict.nl (Bart van Ingen Schenau) wrote in message news:<7sgb40dsfskmtcheqndct5pbdpjfkcsipa@4ax.com>...
> On Tue, 2 Mar 2004 23:33:55 +0000 (UTC), kuyper@wizard.net (James
> Kuyper) wrote:
>
> >Michiel.Salters@cmg.nl (Michiel Salters) wrote in message news:<cefd6cde.0403010848.233003cf@posting.google.com>...
> >> pfffffrrrrt@gmx.de (dmoos AT esigma-systems DOT de) wrote in message news:<c1537n$1dik0i$1@ID-193014.news.uni-berlin.de>...
> >
> >I think that you referred to an important issue, but not the one
> >raised by the OP. I'll illustrate what I think he's talking about with
> >test code.
> >
> >> > Hi,
> >> >
> >> > is it guaranteed that the order and offset of vector-elements
> >> > does not change when doing a push_back() ?
> >
> >#include <vector>
> >#include <algorith>
> >
> >// a is a std::vector<T>, non-empty.
> >T *backup = new T[a.size()];
> >std::copy(a.start(),a.end(),backup);
> >a.push_back(t);
> >if(std::equal(a.start(),a.end()-1,backup)
> >   ;// not explicitly guaranteed
>
> if a.size() < a.capacity(), the guarantee does exist.
> This follows from the requirement that the iterators and references to
> elements in the vector are not invalidated.
> Unless the implementation is capable of updating all possible
> references and iterators, including those that are temporarily stored
> elsewhere, the location of elements of the vector can not be changed.

Just because two iterators remain valid, doesn't guarantee that the
locations those iterators refer to remain in the same order. Changing
the order doesn't require changing the iterators: the information
needed to figure out where the next item may be found could be stored
in the container itself, or in a wrapper around each of the contained
objects.

You might be able to derive a conclusion that it's impossible to have
the order be changeable while satisfying the complexity requirements
on std::vector and std::vector::iterator. However, that's a very
indirect argument. My point was that the guarantee, while it may be
derivable from the standard, is not given explicitly in the standard.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

is it guaranteed that the order and offset of vector-elements
does not change when doing a push_back() ?

When erasing a vector-element, is it guaranteed, that the order
and offset of the elements up to the one erased does not change ?

Is it guaranteed, that the order and offset of vector-elements
is the same in the destination when assigning vectors ?

Any help, hints, pointers are highly appreciated.

Thanks in advance for all your help.

Darius.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pfffffrrrrt@gmx.de (dmoos AT esigma-systems DOT de) wrote in message news:<c1537n$1dik0i$1@ID-193014.news.uni-berlin.de>...
> Hi,
>
> is it guaranteed that the order and offset of vector-elements
> does not change when doing a push_back() ?
>
> When erasing a vector-element, is it guaranteed, that the order
> and offset of the elements up to the one erased does not change ?
>
> Is it guaranteed, that the order and offset of vector-elements
> is the same in the destination when assigning vectors ?

vector<> is a sequence container. For sequences, a.push_back(t) is
defined as equivalent to a.insert(a.end(),t). The fact that a.insert()
is supposed to leave the other elements of the sequence in the same
relative order is not explicitly stated anywhere, as far as I can see,
but it seems to be implied by the name "sequence", and implicitly
assumed in many places.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]