Mystery error. Need help.

[Raknarg]

I'm working on an assignment. Here is the piece of code in question that doesn't work:

c:

void Brig::addPirates(int numPirates) {         cout << "addPirates()" << endl;         for (int i=0; i<numPirates; i++) {                 cout << "\tMaking new Pirate #" << i << endl;                 Pirate* newPirate = new Pirate(); // THIS IS THE NON WORKING STATEMENT                 cout << "\taddPirate() #" << i << endl;                 addPirate(newPirate);                 cout << "\tfinished addPirate() #" << i << endl;         }         cout << "end addPirates()" << endl; }

I have traced the error. The for loop runs once without issue, but the second time it runs, it gets to the aforementioned statement, then gives me this error:

code:

This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.

It doesn't actually go in to the constructor, I checked. Somehow on that call that I mentioned, it crashes right there (I read up about it, apparently this message means abort() or exit(3) was called?). I have no idea how to fix this. Anyone have any ideas?

[Tony]

I would suggest trying this with a different compiler (gcc, clang) to see if you can get a better error message. This being a runtime error, you might need to compile with debug flags turned on.

[Raknarg]

First of all: I think I'll need to be using g++ anyways, that's what the TA's use to mark. But I guess I'll try it just for testing.

second: which debug options should I use? Looking up, there's a lot of options out here

edit: trying out gdb, but I'm either using it wrong or it isn't providing useful information. sigh

[DemonWasp]

With g++, you should probably start with this:

code:

-Wall -Wextra -Werror

Because then it will warn you about any dumb stuff you do (but probably didn't mean to do) and won't let you compile until you've fixed it (it will treat all warnings as errors, which halt compilation).

Can we see the code for Pirate::Pirate() constructor and the Brig::addPirate(Pirate*)?

[Raknarg]

NOTE: I did fix it by adding a static method in my pirate class that generates a new pirate, for some reason the program liked that and gave me no issues.

Here is the constructor:

c:

Pirate::Pirate() {         id = getNextID();         space = randomInt(2, 6); }

But like I said, it didn't even go into the constructor, I tested for that.

The same thing with the addPirate method, it didn't even go into that method, and so I'm assuming it is irrelevant

[DemonWasp]

[quote="Raknarg @ Thu Jan 29, 2015 11:09 am"]The for loop runs once without issue, but the second time it runs [...] gives me this error:

Since those methods executed once, they might have caused the problem. None of the code you've posted looks like it could have caused this kind of problem.

[Raknarg]

Fair enough, there's quite a bit of code though.

The code I showed was in the brig folder. I had made up a main program that was testing the addPirates and printBrig functionality

[DemonWasp]

So I found a few problems.

In your PirateList / CellList, the ::remove() function should have a return true; line at the end that is missing, otherwise control can fall off the end of the function without returning a value.

In your PirateList / CellList destructors, you should use delete [] array; instead of delete array.

In your Cell::Cell() constructor, you should omit the pirates = PirateList(); line. That is not the correct way to initialize that member. Since you declared 'pirates' as a simple member variable, it will be automatically constructed as part of constructing the Cell instance. For more details, see: http://stackoverflow.com/questions/12927169/how-can-i-initialize-c-object-member-variables-in-the-constructor

To debug constructor / destructor calls, it can be very helpful to print out where they occur. In C++, constructors and destructors can be called by a LOT of things you might not expect (such as passing an object to a method, or inserting an object into a list). For example, I put lines like this into your destructors to get more information about when things are being destroyed:

code:

cout << "PirateList::~PirateList() " << this << endl;

This has the advantage of telling you which address is being destroyed at that moment.

[Raknarg]

>In your PirateList / CellList, the ::remove() function should have a return true; line at the end that is missing, otherwise control can fall off the end of the function without returning a value.

Right. I don't actually use it in this assignment but I might in the future, thanks for pointing that out

> In your PirateList / CellList destructors, you should use delete [] array; instead of delete array.

Right. I was not taught that. Why so?

> In your Cell::Cell() constructor, you should omit the pirates = PirateList(); line.

See, I thought that was the case, but I wasn't sure so I did it to be safe. Thank you. Still learning C++ haha

> To debug constructor / destructor calls, it can be very helpful to print out where they occur.

I did have something like that before, I removed it all after I found something that worked though. Putting in 'this' is a good idea though, I'll remember that

[DemonWasp]

> Why use delete[] ?

Because it's required, since 'new' and 'new []' may not behave the same way. See: http://en.wikipedia.org/wiki/Delete_(C%2B%2B)

Although not applicable to your situation, that syntax will also call destructors for all elements of the array, if they are class elements (and not if they are pointers to classes). That is, if the array is MyClass[] foo then delete [] foo will delete all entries before deleting the array itself. However, if the array is MyClass*[] bar then delete [] bar will just delete the array, and not any of the entries it points to.