By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,194 Members | 796 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,194 IT Pros & Developers. It's quick & easy.

Nasty Bug: First exception error.

P: n/a
I have a class that has a std::list of ints as a member. Let's say its
this:

std::list<int> MyInts;

Frequently, another list of ints is assigned to MyInts

MyInts = MyOtherInts;

This occasionally gives me a "First-chance exception" error. I haven't
a clue what this is or why it is happening. The problem is in the
following lines of STL code:

_Myt& operator=(const _Myt& _X)
{if (this != &_X)
{iterator _F1 = begin();
iterator _L1 = end();
const_iterator _F2 = _X.begin();
const_iterator _L2 = _X.end();
for (; _F1 != _L1 && _F2 != _L2; ++_F1, ++_F2)
//here---> *_F1 = *_F2;
erase(_F1, _L1);
insert(_L1, _F2, _L2); }

This is the worst bug I've ever had and i just don't know where to
start with fixing it. I would appreciate any advice you guys have to
offer.
Jul 22 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
On Tue, 16 Dec 2003 19:09:26 +0530, tarmat <ta****@btopenworld.com> wrote:
I have a class that has a std::list of ints as a member. Let's say its
this:

std::list<int> MyInts;

Frequently, another list of ints is assigned to MyInts

MyInts = MyOtherInts;

This occasionally gives me a "First-chance exception" error. I haven't
a clue what this is or why it is happening. The problem is in the
following lines of STL code:

_Myt& operator=(const _Myt& _X)
{if (this != &_X)
{iterator _F1 = begin();
iterator _L1 = end();
const_iterator _F2 = _X.begin();
const_iterator _L2 = _X.end();
for (; _F1 != _L1 && _F2 != _L2; ++_F1, ++_F2)
//here---> *_F1 = *_F2;
erase(_F1, _L1);
insert(_L1, _F2, _L2); }

This is the worst bug I've ever had and i just don't know where to
start with fixing it. I would appreciate any advice you guys have to
offer.


Generally a "first-chance" exception is benign; you'll get that wherever
an exception is thrown.

However you shouldn't get any exception from the assignment shown.

Best advice: post a _small_, complete program that exhibits the problem.

Jul 22 '05 #2

P: n/a
> _Myt& operator=(const _Myt& _X)
{if (this != &_X)
{iterator _F1 = begin();
iterator _L1 = end();
const_iterator _F2 = _X.begin();
const_iterator _L2 = _X.end();
for (; _F1 != _L1 && _F2 != _L2; ++_F1, ++_F2)
//here---> *_F1 = *_F2;
erase(_F1, _L1);
insert(_L1, _F2, _L2); }


Maybe not && but ||. It seems that F2 reaches end, but F1 does not.

for (; _F1 != _L1 || _F2 != _L2; ++_F1, ++_F2)

I'm not sure about this.
Jul 22 '05 #3

P: n/a
In article <t1********************************@4ax.com>,
ta****@btopenworld.com says...
I have a class that has a std::list of ints as a member. Let's say its
this:

std::list<int> MyInts;

Frequently, another list of ints is assigned to MyInts

MyInts = MyOtherInts;

This occasionally gives me a "First-chance exception" error.


A first-chance exception is NOT an error. If you don't see a second-
chance exception, it means that the exception has been handled, and it's
not an error at all.

It looks like in this case the system has paged out some of the memory
in your list. When you try to read from or write to the memory that's
not present in physical memory, the CPU raises an exception. The OS
then handles that by reading the correct data into memory.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 22 '05 #4

P: n/a
Marko Becirevic wrote:
_Myt& operator=(const _Myt& _X)
{if (this != &_X)
{iterator _F1 = begin();
iterator _L1 = end();
const_iterator _F2 = _X.begin();
const_iterator _L2 = _X.end();
for (; _F1 != _L1 && _F2 != _L2; ++_F1, ++_F2)
//here---> *_F1 = *_F2;
erase(_F1, _L1);
insert(_L1, _F2, _L2); }


Maybe not && but ||. It seems that F2 reaches end, but F1 does not.

for (; _F1 != _L1 || _F2 != _L2; ++_F1, ++_F2)

I'm not sure about this.


&& is correct. The symptoms of memory-related errors often occur far
from the code that actually caused the problem. They're only rarely
caused by code in the standard library.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 22 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.