OT: Stupid c++ (Roguelike development)

[narf poit chez BOOM]

Thanks.

Somehow, my pointer item vector is getting messed up between its setup and the function to display it.

The thing is, those are the only two points which have anything to do with items at all.

How is this modifying a vector?!?!

void text ( std:ring tstring, int x, int y, short int Colour ) {
COORD Position; Position.X = x; Position.Y = y;
SetConsoleTextAttribute( hOut, Colour );
SetConsoleCursorPosition( hOut, Position );
std::cout << tstring;
};

Apparently, inputting too large of a block of characters (Between twenty and thirty) somehow affects the vector. Help, anyone?

[narf poit chez BOOM]

Can anybody see a problem with this:

void setupItems () {
srand ( time(NULL) );
// NewWeapon.initialize (); NewPotion.initialize ();
// WeaponList.push_back ( NewWeapon ); PotionList.push_back ( NewPotion );
for ( t = 0; t < 40; ++t ) {
t2 = rand () % 2;
if ( t2 = 0 ) {
NewWeapon.initialize (); WeaponList.push_back ( NewWeapon );
WeaponList[WeaponList.size () - 1].initialize ();
ItemList.push_back ( &WeaponList [WeaponList.size () - 1] );
};
if ( t2 = 1 ) {
NewPotion.initialize (); PotionList.push_back ( NewPotion );
PotionList[PotionList.size () - 1].initialize ();
ItemList.push_back ( &PotionList [PotionList.size () - 1] );
};
};
for ( t = 0; t < ItemList.size (); ++t ) {
ItemList[t]->initialize ();
std::cout << t << " " << ItemList [t]->XPos << " " << ItemList [t]->YPos << " " << ItemList[t]->Colour << " ";
};
std::cin >> wait;
};

It doesn't seem to work right - It seems like all the slots still reference as the base Item class.

[AngleWyrm]

Bug: if(t2 = 0) // assign zero to t2, return true (successful assignment)
You probably meant: if(t2==0) // test for equality

Happens so often that some compilers even have a warning for it.

[narf poit chez BOOM]

Thanks. We're whacking it into shape on IRC.

[PvK]

Classes should define a destructor if something needs to happen every time one gets destroyed (either by delete or by a non-static member going out of scope). It is important to prevent memory leaks if the class has any heap-allocated memory that it maintains the only pointer to and should remove when it dies.

If an object has no heap-allocated memory (i.e. it doesn't create anything with "new" or "malloc"), and if nothing needs to happen when it gets deleted, then it doesn't need a destructor.

However, I really doubt any worthwhile C++ compiler is going to have a fundamental problem with destructors or with delete. If it did, it would be seriously crippled. I expect probably you are seeing some other bug.

What are you deleting when you see problems? Objects with destructors that do things like use objects that are already destroyed?

[narf poit chez BOOM]

Huh?

No, I use data types like 'int' and 'char'. Never new.

I just had a vague memory of someone saying the 'delete' command was unreliable.

Not using delete. I have, in fact, no destructors at all and a vague feeling that this might be bad.

[PvK]

Destructors are simply functions that get called when an object is deleted. If you never use new or malloc, then you probably never use delete nor free either, and your objects will only be deleted automatically - i.e. if they are local to a function and that function exits, or when the program exits. In other words, it sounds like you probably don't need to worry about destructors at all.

What are you going to do about creating new things during play, though, like new monsters, items, levels, etc.? Are you using STL lists of objects (not of pointers to objects) and just adding them and removing them from those? If so, then imagining how your code probably looks, STL should be doing the cleanup for you, and you shouldn't need to define destructors...

... well, ok, as long as you don't start using pointers or references to items in those lists, and expecting them to always be there after other events have happened that might have removed them from the lists. That could lead to a nice invalid pointer or reference and crash.

Example:

Say you have a list of all monsters in the world called MonsterList. Then say you have a Quest object to slay a particular monster, which when it gets launched, adds a monster to MonsterList and then keeps a pointer or reference to that monster object, to refer to the monster to slay. Now, if something in the game can remove the monster from MonsterList, causing its object to be automatically deleted by STL, then referring to a reference or pointer to it will be an access violation and boom. So if you want to avoid that, you could give monsters also a unique ID, and when you refer to them, always go search the list.

Of course, that's a fairly slow operation, but you probably don't care too much until you have thousands of things going on at once in your gameworld. To be faster, you could have a destructor that announces when something gets deleted, and causes everything that might refer to it to drop their pointers and references to it. Sounds like you'd probably be better off keeping things simple and reliable for now, though.

[narf poit chez BOOM]

Currently I'm using vectors for items and an array for the map.

I'm using pointers for characters, but that's the next thing I'm going to replace. In the meantime, the number of characters never changes; dead characters are simply re-randomized.

Thanks.

[narf poit chez BOOM]

Update: Simple Roguelike v0.1.4

It's been extensivly tested for all of two or three minutes, but everything should work. No cosmetic changes, but a lot of code was fixed so as to result in less heart attacks on IRC. Also, it's nearly 2MB, so I stuck it in a .rar

[narf poit chez BOOM]

Readme's are good. I added one, just in case people hadn't found the help key.