end of std::list

Discussion in 'C++' started by Glen Able, Sep 29, 2004.

  1. Glen Able

    Glen Able Guest

    Without further ado, here's some code:

    std::list<int> things;

    things.push_back(1);
    things.push_back(2);
    things.push_back(3);

    std::list<int>::iterator it;
    int test;

    it = things.end();
    test = *it; // obviously garbage

    things.push_back(4);
    test = *it; // garbage - but I was expecting '4'

    I assumed that 'list' maintained an extra empty node at the end, which is
    what gets returned by list.end(). Then I'd expect the 'push_back(4)' to
    actually attach the value 4 to that node, which should then be returned in
    the second 'test = *it' statement.

    Anyone care to enlighten me?
    thanks,
    G.A.
     
    Glen Able, Sep 29, 2004
    #1
    1. Advertising

  2. "Glen Able" <> wrote in message
    news:cjec9r$88t$1$...
    > Without further ado, here's some code:
    >
    > std::list<int> things;
    >
    > things.push_back(1);
    > things.push_back(2);
    > things.push_back(3);
    >
    > std::list<int>::iterator it;
    > int test;
    >
    > it = things.end();
    > test = *it; // obviously garbage


    Actually undefined behaviour.

    >
    > things.push_back(4);
    > test = *it; // garbage - but I was expecting

    '4'
    >
    > I assumed that 'list' maintained an extra empty node at the end, which is
    > what gets returned by list.end(). Then I'd expect the 'push_back(4)' to
    > actually attach the value 4 to that node, which should then be returned

    in
    > the second 'test = *it' statement.
    >
    > Anyone care to enlighten me?
    > thanks,
    > G.A.


    This is covered by the 'invalidation of iterators' requirements that the STL
    has. The requirements are different for different containers but for
    std::list then only way to invalidate an iterator is to erase the element
    that the iterator is pointing to. In all other cases iterators remain valid,
    so for a std::list the return from end() will be the end of the list no
    matter how many items are subsequently added or removed from the list.

    john
     
    John Harrison, Sep 29, 2004
    #2
    1. Advertising

  3. "Glen Able" <> writes:

    > Without further ado, here's some code:
    >
    > std::list<int> things;
    >
    > things.push_back(1);
    > things.push_back(2);
    > things.push_back(3);
    >
    > std::list<int>::iterator it;
    > int test;
    >
    > it = things.end();
    > test = *it; // obviously garbage
    >
    > things.push_back(4);
    > test = *it; // garbage - but I was expecting '4'


    AFAIK end() returns the data of an fixed node in the list(a member), and
    so end() is always the same node.

    Kind regards,
    Nicolas

    --
    | Nicolas Pavlidis | Elvis Presly: |\ |__ |
    | Student of SE & KM | "Into the goto" | \|__| |
    | | ICQ #320057056 | |
    |-------------------University of Technology, Graz----------------|
     
    Nicolas Pavlidis, Sep 29, 2004
    #3
  4. "Glen Able" <> schrieb im Newsbeitrag
    news:cjec9r$88t$1$...
    > Without further ado, here's some code:
    >
    > std::list<int> things;
    >
    > things.push_back(1);
    > things.push_back(2);
    > things.push_back(3);
    >
    > std::list<int>::iterator it;
    > int test;
    >
    > it = things.end();
    > test = *it; // obviously garbage
    >
    > things.push_back(4);
    > test = *it; // garbage - but I was
    > expecting '4'


    then use:
    test = things.back(); and front(); they both give a reference to the
    last/first element.
     
    Gernot Frisch, Sep 29, 2004
    #4
  5. Glen Able wrote:
    >
    > Without further ado, here's some code:
    >
    > std::list<int> things;
    >
    > things.push_back(1);
    > things.push_back(2);
    > things.push_back(3);
    >
    > std::list<int>::iterator it;
    > int test;
    >
    > it = things.end();
    > test = *it; // obviously garbage
    >
    > things.push_back(4);
    > test = *it; // garbage - but I was expecting '4'
    >
    > I assumed that 'list' maintained an extra empty node at the end, which is
    > what gets returned by list.end(). Then I'd expect the 'push_back(4)' to
    > actually attach the value 4 to that node, which should then be returned in
    > the second 'test = *it' statement.


    Where is it stated, that it has to be that way.

    A list can also always use the very same node for marking the end of list
    (if there is such a node at all, I don't think that dereferencing the end
    iterator is an allowed operation. But I'm not sure about that)

    If you push_back, a new node gets allocated and inserted just before that
    end_of_list node.

    --
    Karl Heinz Buchegger
     
    Karl Heinz Buchegger, Sep 29, 2004
    #5
  6. Glen Able

    Glen Able Guest

    "Karl Heinz Buchegger" <> wrote in message
    news:...

    > Where is it stated, that it has to be that way.
    >
    > A list can also always use the very same node for marking the end of list
    > (if there is such a node at all, I don't think that dereferencing the end
    > iterator is an allowed operation. But I'm not sure about that)
    >
    > If you push_back, a new node gets allocated and inserted just before that
    > end_of_list node.
    >


    Bah. My actual application is trying to store references to positions in a
    list (previously I was using a std::vector and indices). Problem is where
    sometimes I need to add a reference to the place in the list where the next
    element is going to be added, whenever that is. My naive interpretation of
    'list iterators are never invalidated' lead me astray!

    I guess I'll have to wrap the list in a class which has a collection of
    references which need to be set to the next list element, whenever it gets
    appended.

    Thanks everyone.
    G.A.
     
    Glen Able, Sep 29, 2004
    #6
    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. Peter Jansson
    Replies:
    5
    Views:
    6,323
    Ivan Vecerina
    Mar 17, 2005
  2. Vinu
    Replies:
    4
    Views:
    362
    Jim Langston
    Jul 7, 2005
  3. Replies:
    6
    Views:
    653
    Jim Langston
    Oct 30, 2005
  4. Juha Nieminen
    Replies:
    22
    Views:
    1,036
    Kai-Uwe Bux
    Oct 12, 2007
  5. mathieu
    Replies:
    2
    Views:
    2,378
    mathieu
    Apr 8, 2009
Loading...

Share This Page