Runtime error using list<int>.erase()

This is a discussion on Runtime error using list<int>.erase() within the C++ Programming forums, part of the General Programming Boards category; My problem is that when I use erase() on a set<int>, I get a runtime error (windows must close the ...

  1. #1
    Registered User
    Join Date
    Nov 2006
    Posts
    6

    Runtime error using list<int>.erase()

    My problem is that when I use erase() on a set<int>, I get a runtime error (windows must close the program, etc.). Chances are it is something obvious. Here is the relevant code:

    Code:
    typedef pair<int,set<int> > Square;
    typedef vector<Square*> LinePtr;
    //...
    for(lt2=0;lt2<3;++lt2) {
       LinePtr l = getMyl();
         for(LinePtr::iterator it=l.begin();it!=l.end();++it) {
             Square *sp = *it;
             int lownum = *(ls.begin());
             int highnum = *(++ls.begin());
             if(sp->second.count(lownum)>0) sp->second.erase(lownum);
             if(sp->second.count(highnum)>0) sp->second.erase(highnum);
          }
       }
    }
    By extensive testing I have concluded that it is the actual erase function that is causing the error, so it is not an invalidated iterator or some other such error. The answer might possibly have to do with my layered use of iterators and pointers.

    If the answer is not apparent, what possible causes could there be for a runtime error with erase()?

  2. #2
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >int lownum = *(ls.begin());
    >int highnum = *(++ls.begin());
    What's ls?

    >if(sp->second.count(lownum)>0)
    >if(sp->second.count(highnum)>0)
    You don't need these tests. erase will simply return 0 if the item doesn't exist.

    Could you provide a compilable example so that we can troubleshoot? At a glance the code looks okay.
    My best code is written with the delete key.

  3. #3
    Registered User
    Join Date
    Jan 2005
    Posts
    7,340
    If sp is null or invalid, then the crash could easily happen in the call to erase.

  4. #4
    Registered User
    Join Date
    Nov 2006
    Posts
    6
    >What's ls?
    erm... Sorry about that.

    >You don't need these tests. erase will simply return 0 if the item doesn't exist.
    Thanks for that, it was left over from an old version.

    >If sp is null or invalid, then the crash could easily happen in the call to erase.
    I do not think so, as by printing the contents of it before the crash turns out fine.

    Edit:
    An interesting thing of possible relevance is that when I reformat it to use the remove() algorithm, I get the following compile-time error(s):

    C:\Dev-Cpp\include\c++\3.4.2\bits\stl_algo.h In function `_OutputIterator std::remove_copy(_InputIterator, _InputIterator, _OutputIterator, const _Tp&) [with _InputIterator = std::_Rb_tree_const_iterator<int>, _OutputIterator = std::_Rb_tree_const_iterator<int>, _Tp = int]':

    1114 C:\Dev-Cpp\include\c++\3.4.2\bits\stl_algo.h instantiated from `_ForwardIterator std::remove(_ForwardIterator, _ForwardIterator, const _Tp&) [with _ForwardIterator = std::_Rb_tree_const_iterator<int>, _Tp = int]'

    238 C:\Documents and Settings\Ben\My Documents\cpp\New Folder (2)\sudoku.cpp instantiated from here

    1039 C:\Dev-Cpp\include\c++\3.4.2\bits\stl_algo.h assignment of read-only location
    Last edited by cyanfish; 11-18-2006 at 11:47 AM.

  5. #5
    Registered User
    Join Date
    Jan 2005
    Posts
    7,340
    >> I do not think so, as by printing the contents of it before the crash turns out fine.
    When you mess up your memory and try to use an invalid pointer, or other code overwrites memory that doesn't belong to it, anything can happen. It is quite possible (and common) when this happens for some operations to appear to work and others not to. For example, perhaps read-only operations like outputting or calling count will not crash, but an attempt to change the data with erase will.

    It is very unlikely that the crash is because of your call to erase specifically. You are doing something wrong with your memory somewhere else in the program.

  6. #6
    Registered User
    Join Date
    Nov 2006
    Posts
    6
    Thank you, it appears you were right. I stopped using pointers and it worked fine - the only problem now is the logic, but that's my problem.

  7. #7
    Registered User
    Join Date
    Jan 2005
    Posts
    7,340
    >> LinePtr l = getMyl();
    If you do stop using pointers, be aware of this line and others like it as that is probably copying the entire vector of int/set<int> pairs. A reference would probably be better (assuming getMyl() returns a reference as well).

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Runtime formation and execution at runtime
    By Soham in forum C Programming
    Replies: 17
    Last Post: 08-27-2008, 08:45 AM
  2. link with C runtime library
    By George2 in forum C++ Programming
    Replies: 26
    Last Post: 02-05-2008, 12:56 AM
  3. Visual Studio and .Net Runtime Framework dependency
    By George2 in forum C# Programming
    Replies: 1
    Last Post: 08-08-2007, 07:52 AM
  4. FILES in WinAPI
    By Garfield in forum Windows Programming
    Replies: 46
    Last Post: 10-02-2003, 06:51 PM
  5. Runtime error! Please help
    By Garfield in forum C Programming
    Replies: 7
    Last Post: 10-10-2001, 06:56 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21