Archived

This topic is now archived and is closed to further replies.

zip7000

error during the executing time

Recommended Posts

hi, the compilation of my program is ok. But when the program is running I get an error.("the memory cannot be read) I can''t understand the following behaviour. here is a function in a class called Ant bool Ant::FindSpatialObject(Garden* g) { int i; int nbNest=Nest::NestCounter; for (i=0; iCompare(g->GetVector())) != SEPARATE ) return true; } return false; } If I call this method I get an error(not by the compiler) Now if I change the i variable by 0, everything works. I checked the i variable : during the executing time a variable takes only 0 as value. So I can''t understand what''s wrong!!! Any suggestion??? ps : ''GetVector()'' return a std::vector ''Compare()'' function needs two SpatialObjects. Ant and Nest are SpatialObjects zip7000

Share this post


Link to post
Share on other sites
Use [ source ] and [ /source ] (without the spaces) tags, or your code will be difficult to read.



Don''t listen to me. I''ve had too much coffee.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
why do you have that for loop in there??

Share this post


Link to post
Share on other sites
Here's the actual code:

bool Ant::FindSpatialObject(Garden* g)
{
int i;
int nbNest=Nest::NestCounter;
for (i=0; i< nbNest; i++)
{
if ( (this->Compare(g->GetVector()[i ])) != SEPARATE )
return true;
}
return false;
}


All I have to say is, LHTD.

Later,
ZE.

//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links


[edited by - zealouselixir on August 15, 2002 5:28:59 PM]

[edited by - zealouselixir on August 15, 2002 7:22:53 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Zipster
It''s bad practice to defer a pointer if you haven''t checked if it is 0. It could be that the ''g'' passed is NULL, in which case that function would crash.

I disagree with that. I believe that if you always check your pointers if they are NULL before using them that leads to more errors. You should only check if the pointer is NULL if you know that it is either (1.) NULL or (2.) a valid pointer.

Suppose you have a piece of code where you always expect a certain pointer to point to some object. Then there''s a bug that randomly sets that pointer to NULL. Your code would then happily continue to execute, although there''s a bug. Thus you risk to hide bugs and make bugs harder to find.

I don''t want to start a war about this, but it''s worth considering both opinions.


That said, you might still be right that the problem is that the ''g'' is NULL and the code tries to defer it.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
hi,

I found. It was a very stupid mistake. I called the function in a loop. So I created lot of objects.

sorry about that!!!

Share this post


Link to post
Share on other sites
hi,

I found. It was a very stupid mistake. I called the function in a loop. So I created lot of objects.

sorry about that!!!

Share this post


Link to post
Share on other sites
quote:
Suppose you have a piece of code where you always expect a certain pointer to point to some object. Then there''s a bug that randomly sets that pointer to NULL. Your code would then happily continue to execute, although there''s a bug. Thus you risk to hide bugs and make bugs harder to find.


Actually, if I assumed it would always point to a valid object, then there wouldn''t be a NULL-check, the program would crash, and I''d find the error.

I understand your point, and I should clarify what I said. I don''t mean to put a NULL-check every time you defer a pointer - that''s dumb. Was I meant to say was that you only do the check where there''s a possibility the value could be NULL, which in this case, it could be if there was a bug in the code outside the scope of the function that passed it a NULL value. I''m sorry, I thought that was just something understood

Share this post


Link to post
Share on other sites
quote:
Original post by daerid
Guys, come on.


void some_fun(some_class* p)
{
assert(p!=0);
// do stuff with p
}


Hello?



Guys, come on.

void some_fun(some_class& c)
{
// do stuff with c
}


i don''t need pointers at 99% of the gamecode, just for some baseclasses wich encapsulate some data.. (and even there i don''t rely on normal pointers..)



"take a look around" - limp bizkit
www.google.com

Share this post


Link to post
Share on other sites