Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > container idiom revisited

Reply
Thread Tools

container idiom revisited

 
 
keith
Guest
Posts: n/a
 
      04-13-2010
I'd like all of you to take a look at page 471 of the ISO-IEC-14882
(2003) standard, where you are going to see things like:

*--c.end() and c.erase(--c.end())

I'd like you to comment on this. Maybe you were not right in claiming
the idiom was not well-formed and not portable?
 
Reply With Quote
 
 
 
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      04-13-2010
keith wrote:

> I'd like all of you to take a look at page 471 of the ISO-IEC-14882
> (2003) standard, where you are going to see things like:
>
> *--c.end() and c.erase(--c.end())
>
> I'd like you to comment on this.

[...]

It's a defect in the standard. See, e.g, issue 355 in:
http://www.open-std.org/jtc1/sc22/wg...004/n1685.html

Also: the bug has been fixed in the draft for C++0X.


Best

Kai-Uwe Bux



 
Reply With Quote
 
 
 
 
keith
Guest
Posts: n/a
 
      04-13-2010

> It's a defect in the standard. See, e.g, issue 355 in:
> http://www.open-std.org/jtc1/sc22/wg...004/n1685.html
>
> Also: the bug has been fixed in the draft for C++0X.


I see. How then to erase the last element of a std::multimap<>? I've
tried mmap.erase(mmap.rbegin());, but it does not work.
mmap.erase(--mmap.end()), does work however. I don't see the construct
being wrong for a std::multimap<>::iterator (or any other associate
iterator), because they are not random but bidirectional. Consequently I
see them being of class type.
 
Reply With Quote
 
red floyd
Guest
Posts: n/a
 
      04-13-2010
On Apr 13, 4:37*pm, keith <(E-Mail Removed)> wrote:
> > It's a defect in the standard. See, e.g, issue 355 in:
> >http://www.open-std.org/jtc1/sc22/wg...004/n1685.html

>
> > Also: the bug has been fixed in the draft for C++0X.

>
> I see. How then to erase the last element of a std::multimap<>? I've
> tried mmap.erase(mmap.rbegin());, but it does not work.
> mmap.erase(--mmap.end()), does work however. I don't see the construct
> being wrong for a std::multimap<>::iterator (or any other associate
> iterator), because they are not random but bidirectional. Consequently I
> see them being of class type.


Assuming the map is not empty,

mmap.erase(mmap.rbegin().base)

 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      04-13-2010
keith wrote:

>
>> It's a defect in the standard. See, e.g, issue 355 in:
>> http://www.open-std.org/jtc1/sc22/wg...004/n1685.html
>>
>> Also: the bug has been fixed in the draft for C++0X.

>
> I see. How then to erase the last element of a std::multimap<>? I've
> tried mmap.erase(mmap.rbegin());, but it does not work.
> mmap.erase(--mmap.end()), does work however. I don't see the construct
> being wrong for a std::multimap<>::iterator (or any other associate
> iterator), because they are not random but bidirectional. Consequently I
> see them being of class type.


a) Whether std::multimap<>::iterator is of class type is of no consequence
since operator-- does not need to be implemented as a member function
[17.3.1.2/3]. If it is a free function, the temporary mmap.end() will not
bind to its argument.

b) As for how to erase the last element: you can use a little helper
function:

template < typename Iter >
Iter prev ( Iter i ) {
-- i;
return ( i );
}

and then say: mmap.erase( prev( mmap.end() ) ). Of course, you can also
ditch the goal of doing it in one line


Best

Kai-Uwe Bux
 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      04-14-2010
red floyd wrote:

> On Apr 13, 4:37 pm, keith <(E-Mail Removed)> wrote:
>> > It's a defect in the standard. See, e.g, issue 355 in:
>> >http://www.open-std.org/jtc1/sc22/wg...004/n1685.html

>>
>> > Also: the bug has been fixed in the draft for C++0X.

>>
>> I see. How then to erase the last element of a std::multimap<>? I've
>> tried mmap.erase(mmap.rbegin());, but it does not work.
>> mmap.erase(--mmap.end()), does work however. I don't see the construct
>> being wrong for a std::multimap<>::iterator (or any other associate
>> iterator), because they are not random but bidirectional. Consequently I
>> see them being of class type.

>
> Assuming the map is not empty,
>
> mmap.erase(mmap.rbegin().base)


Isn't mmap.rbegin().base() == mmap.end() as per the identify

&*(reverse_iterator(i)) == &*(i - 1)


Best

Kai-Uwe Bux

 
Reply With Quote
 
red floyd
Guest
Posts: n/a
 
      04-14-2010
On Apr 13, 5:00*pm, Kai-Uwe Bux <(E-Mail Removed)> wrote:
> red floyd wrote:
> > On Apr 13, 4:37 pm, keith <(E-Mail Removed)> wrote:
> >> > It's a defect in the standard. See, e.g, issue 355 in:
> >> >http://www.open-std.org/jtc1/sc22/wg...004/n1685.html

>
> >> > Also: the bug has been fixed in the draft for C++0X.

>
> >> I see. How then to erase the last element of a std::multimap<>? I've
> >> tried mmap.erase(mmap.rbegin());, but it does not work.
> >> mmap.erase(--mmap.end()), does work however. I don't see the construct
> >> being wrong for a std::multimap<>::iterator (or any other associate
> >> iterator), because they are not random but bidirectional. Consequently I
> >> see them being of class type.

>
> > Assuming the map is not empty,

>
> > mmap.erase(mmap.rbegin().base)

>
> Isn't mmap.rbegin().base() == mmap.end() as per the identify
>
> * &*(reverse_iterator(i)) == &*(i - 1)
>
> Best
>
> Kai-Uwe Bux


Oops.

I think the concept is valid, though, if poorly implmented in my q&d
example.

map::reverse iterator it = mmap.rbegin();
++it;
mmap.erase(it.base());

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      04-14-2010
On Apr 14, 12:37 am, keith <(E-Mail Removed)> wrote:
> > It's a defect in the standard. See, e.g, issue 355 in:
> >http://www.open-std.org/jtc1/sc22/wg...004/n1685.html


> > Also: the bug has been fixed in the draft for C++0X.


> I see. How then to erase the last element of a std::multimap<>?


std::multimap<>::iterator i = m.end();
-- i;
m.erase(i);

It isn't too difficult (and is generally useful) to write a
generic pred() function which can be used.

> I've tried mmap.erase(mmap.rbegin());, but it does not work.


Rather obviouslym since multimap<>::erase expects a
multimap<>::iterator.

> mmap.erase(--mmap.end()), does work however.


On some (most? all?) implementations.

> I don't see the construct being wrong for a
> std::multimap<>::iterator (or any other associate iterator),
> because they are not random but bidirectional. Consequently I
> see them being of class type.


And? Class type doesn't guarantee that --mmap.end() will work.

--
James Kanze
 
Reply With Quote
 
keith
Guest
Posts: n/a
 
      04-15-2010

> template < typename Iter >
> Iter prev ( Iter i ) {
> -- i;
> return ( i );
> }
>
> and then say: mmap.erase( prev( mmap.end() ) ). Of course, you can also
> ditch the goal of doing it in one line


Are prev() and next() part of boost or STL? They would resolve the
defect in the C++ 2003 standard nicely, from what I can see.
 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      04-15-2010
keith wrote:

>
>> template < typename Iter >
>> Iter prev ( Iter i ) {
>> -- i;
>> return ( i );
>> }
>>
>> and then say: mmap.erase( prev( mmap.end() ) ). Of course, you can also
>> ditch the goal of doing it in one line

>
> Are prev() and next() part of boost or STL? They would resolve the
> defect in the C++ 2003 standard nicely, from what I can see.


It is in the draft n3090 [24.4.4].


Best

Kai-Uwe Bux
 
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
correct idiom for container keith C++ 2 04-08-2010 08:12 PM
tree container library, revisited Mitchel Haas C++ 4 02-01-2006 12:09 PM
Simplified DOM idiom for building XML - revisited Steve Jorgensen XML 4 08-28-2005 08:54 PM
STL: container's values setup by another container Maitre Bart C++ 2 02-11-2004 12:11 AM
std::container::iterator vs std::container::pointer Vivi Orunitia C++ 11 02-04-2004 08:09 AM



Advertisments