Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > STL std::map erase

Reply
Thread Tools

STL std::map erase

 
 
Howard
Guest
Posts: n/a
 
      05-13-2004

"Karl Heinz Buchegger" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> John Harrison wrote:
> >
> > "Karl Heinz Buchegger" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > John Harrison wrote:
> > > >
> > > >
> > > > No, that's exactly the point. i++ is a function call, and that

function
> > must
> > > > happen before the call to erase.
> > >
> > > Ahm.
> > > Thats the wrong explanation.
> > > The correct explanation is:
> > > There is a sequence point immediatly after all arguments
> > > to functions have been evaluated and just before the
> > > function gets called.
> > >
> > > So the compiler has no other choice: If there are side
> > > effects during the evaluation of arguments, those side
> > > effects have to be completed before the function gets
> > > called.
> > >
> > > That i++ in case of iterators is implemented as a function is
> > > an implementation detail.
> > >

> >
> > I wasn't completely sure if the same rules applied to ++ on a built in

type,
>
> The ++ has nothing to do with it other then generating a side effect.
>
> --
> Karl Heinz Buchegger
> http://www.velocityreviews.com/forums/(E-Mail Removed)



So even if i were an int, it would still have to be incremented prior to
calling the function? That sure seems counter-intuitive to the notion of
"post-increment". Makes sense though, I guess.

Also, I guess that means that what is actually passed to the function is a
*copy* of the original iterator, since the original already has to point to
the next item, right?

This is very enlightening. It seems that I always have more to learn with
this language. Thanks...

-Howard







 
Reply With Quote
 
 
 
 
Andrey Tarasevich
Guest
Posts: n/a
 
      05-13-2004
Howard wrote:
> ...
> So even if i were an int, it would still have to be incremented prior to
> calling the function?


Yes.

> That sure seems counter-intuitive to the notion of
> "post-increment". Makes sense though, I guess.


The function will still receive the original value of 'i'. That's why it
is called "post-increment".

> Also, I guess that means that what is actually passed to the function is a
> *copy* of the original iterator, since the original already has to point to
> the next item, right?


Since this function receives its parameter "by value" - yes, it actually
receives a copy of the original iterator.

--
Best regards,
Andrey Tarasevich

 
Reply With Quote
 
 
 
 
Howard
Guest
Posts: n/a
 
      05-13-2004

"Andrey Tarasevich" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Howard wrote:
> > ...
> > So even if i were an int, it would still have to be incremented prior to
> > calling the function?

>
> Yes.
>
> > That sure seems counter-intuitive to the notion of
> > "post-increment". Makes sense though, I guess.

>
> The function will still receive the original value of 'i'. That's why it
> is called "post-increment".
>
> > Also, I guess that means that what is actually passed to the function is

a
> > *copy* of the original iterator, since the original already has to point

to
> > the next item, right?

>
> Since this function receives its parameter "by value" - yes, it actually
> receives a copy of the original iterator.
>


Ok...but then, what if you were to pass the iterator *by reference* to some
function instead? What value would the function then get, (considering the
previously stated rule that the increment side-effect has to be completed
prior to the calling of the function)? Would a temporary (un-incremented)
copy be created, passed by reference, and then that copy destroyed after the
return of the function? (That seems to be the only way to maintain the
concept of post-increment without violating the side-effect rule.)

-Howard





 
Reply With Quote
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      05-13-2004
Howard wrote:

>> Since this function receives its parameter "by value" - yes, it actually
>> receives a copy of the original iterator.

>
> Ok...but then, what if you were to pass the iterator *by reference* to
> some
> function instead? What value would the function then get, (considering
> the previously stated rule that the increment side-effect has to be
> completed
> prior to the calling of the function)? Would a temporary (un-incremented)
> copy be created, passed by reference, and then that copy destroyed after
> the
> return of the function? (That seems to be the only way to maintain the
> concept of post-increment without violating the side-effect rule.)


That depends on how the iterator implements the pre and post ++ operators.
Habitually the post version returns a copy of the old value.

--
Salu2
 
Reply With Quote
 
joey tribbiani
Guest
Posts: n/a
 
      05-13-2004
Pieter Thysebaert wrote:
>
> Hello,


> According to the STL docs, erasing an element in a map invalidates all
> iterators pointing to that element
>
> so
>
> for (map<...>::iterator i = mymap.begin(); i != mymap.end(); i++) {
> if (test(i)) {
> mymap.erase(i);
> mymap.insert(newelement);
> }
> }


Why not the following?

for (map<...>::iterator i = mymap.begin(); i != mymap.end(); i++) {
if (test(i)) {
i = mymap.erase(i);
}
}




 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      05-13-2004
joey tribbiani wrote:
>
> Why not the following?
>
> for (map<...>::iterator i = mymap.begin(); i != mymap.end(); i++) {
> if (test(i)) {
> i = mymap.erase(i);
> }
> }


Because map::erase returns void according to the standard. Our
implementation returns an iterator, just like vector::erase. The next
version of the standard will probably make that change official.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
 
Reply With Quote
 
Jeff Flinn
Guest
Posts: n/a
 
      05-13-2004

"Pete Becker" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> joey tribbiani wrote:
> >
> > Why not the following?
> >
> > for (map<...>::iterator i = mymap.begin(); i != mymap.end(); i++) {
> > if (test(i)) {
> > i = mymap.erase(i);
> > }
> > }

>
> Because map::erase returns void according to the standard. Our
> implementation returns an iterator, just like vector::erase. The next
> version of the standard will probably make that change official.


Even with this extension/future std, the above is incorrect. 'i' will be
effectively incremented twice for each true 'test(i)'. 'i++' needs to be
moved from the for statement to an else clause.

Jeff F


 
Reply With Quote
 
joey tribbiani
Guest
Posts: n/a
 
      05-13-2004
Pete Becker wrote:

> joey tribbiani wrote:
>
>>Why not the following?
>>
>>for (map<...>::iterator i = mymap.begin(); i != mymap.end(); i++) {
>> if (test(i)) {
>> i = mymap.erase(i);
>> }
>>}

>
>
> Because map::erase returns void according to the standard. Our
> implementation returns an iterator, just like vector::erase. The next
> version of the standard will probably make that change official.
>

Oh, thanks, i didn't know - always thought you are the standard
(actually, never really thought about it)
 
Reply With Quote
 
Howard
Guest
Posts: n/a
 
      05-13-2004

"Pete Becker" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> joey tribbiani wrote:
> >
> > Why not the following?
> >
> > for (map<...>::iterator i = mymap.begin(); i != mymap.end(); i++) {
> > if (test(i)) {
> > i = mymap.erase(i);
> > }
> > }

>
> Because map::erase returns void according to the standard. Our
> implementation returns an iterator, just like vector::erase. The next
> version of the standard will probably make that change official.
>


Even if it *did* return an iterator, the above code would only work if it
returned an iterator to the *previous* item, because the for loop is going
to increment i every time. The implementation I'm using returns an iterator
to the *next* item (or to end(), if there are none beyond the given item).
In that case, it would have to be writtien:

for (map<...>::iterator i = mymap.begin(); i != mymap.end(); )
{
if (test(i))
i = mymap.erase(i);
else
i++;
}

-Howard


 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      05-13-2004
Jeff Flinn wrote:
>
> "Pete Becker" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > joey tribbiani wrote:
> > >
> > > Why not the following?
> > >
> > > for (map<...>::iterator i = mymap.begin(); i != mymap.end(); i++) {
> > > if (test(i)) {
> > > i = mymap.erase(i);
> > > }
> > > }

> >
> > Because map::erase returns void according to the standard. Our
> > implementation returns an iterator, just like vector::erase. The next
> > version of the standard will probably make that change official.

>
> Even with this extension/future std, the above is incorrect. 'i' will be
> effectively incremented twice for each true 'test(i)'. 'i++' needs to be
> moved from the for statement to an else clause.
>


So tell the person who posted it.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
erase vs. erase al.cpwn@gmail.com C++ 7 03-30-2006 11:45 AM
How do i erase all information in my orkut and erase the link to the orkut account? mountbatten@gmail.com Computer Support 1 10-31-2005 12:03 AM
Re: STL insert/erase behaviour Andrew Koenig C++ 0 08-13-2003 06:08 PM
Re: STL insert/erase behaviour John Harrison C++ 0 08-13-2003 05:51 PM
How do I erase a file that wont let me erase it? Dale Custer Computer Support 4 07-06-2003 09:48 AM



Advertisments