container idiom revisited

Discussion in 'C++' started by keith, Apr 13, 2010.

  1. keith

    keith Guest

    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?
     
    keith, Apr 13, 2010
    #1
    1. Advertising

  2. keith

    Kai-Uwe Bux Guest

    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/wg21/docs/papers/2004/n1685.html

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


    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Apr 13, 2010
    #2
    1. Advertising

  3. keith

    keith Guest


    > It's a defect in the standard. See, e.g, issue 355 in:
    > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/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.
     
    keith, Apr 14, 2010
    #3
  4. keith

    red floyd Guest

    On Apr 13, 4:37 pm, keith <> wrote:
    > > It's a defect in the standard. See, e.g, issue 355 in:
    > >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/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)
     
    red floyd, Apr 14, 2010
    #4
  5. keith

    Kai-Uwe Bux Guest

    keith wrote:

    >
    >> It's a defect in the standard. See, e.g, issue 355 in:
    >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/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
     
    Kai-Uwe Bux, Apr 14, 2010
    #5
  6. keith

    Kai-Uwe Bux Guest

    red floyd wrote:

    > On Apr 13, 4:37 pm, keith <> wrote:
    >> > It's a defect in the standard. See, e.g, issue 355 in:
    >> >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/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
     
    Kai-Uwe Bux, Apr 14, 2010
    #6
  7. keith

    red floyd Guest

    On Apr 13, 5:00 pm, Kai-Uwe Bux <> wrote:
    > red floyd wrote:
    > > On Apr 13, 4:37 pm, keith <> wrote:
    > >> > It's a defect in the standard. See, e.g, issue 355 in:
    > >> >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/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());
     
    red floyd, Apr 14, 2010
    #7
  8. keith

    James Kanze Guest

    On Apr 14, 12:37 am, keith <> wrote:
    > > It's a defect in the standard. See, e.g, issue 355 in:
    > >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/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
     
    James Kanze, Apr 14, 2010
    #8
  9. keith

    keith Guest


    > 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.
     
    keith, Apr 15, 2010
    #9
  10. keith

    Kai-Uwe Bux Guest

    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
     
    Kai-Uwe Bux, Apr 15, 2010
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Jorgensen
    Replies:
    4
    Views:
    443
    Soren Kuula
    Aug 28, 2005
  2. Vivi Orunitia
    Replies:
    11
    Views:
    4,545
    Martijn Lievaart
    Feb 4, 2004
  3. Maitre Bart
    Replies:
    2
    Views:
    551
    Maitre Bart
    Feb 11, 2004
  4. Mitchel Haas

    tree container library, revisited

    Mitchel Haas, Jan 31, 2006, in forum: C++
    Replies:
    4
    Views:
    480
    Mitchel Haas
    Feb 1, 2006
  5. keith
    Replies:
    2
    Views:
    339
    James Kanze
    Apr 8, 2010
Loading...

Share This Page