I have a class with the only constructor like this:
IntroScreen::IntroScreen(Game *game) :
View(game), counter(0.0f), message(-1), continueAlpha(255),
continueVisible(false), screenAlpha(255), fadeIn(false), fadeOut(false)
{
}
And somewhere in a method I have this if-statement
if (counter > 10.0f)
And Valgrind says for that line:
Conditional jump or move depends on uninitialised value(s)
But I initialized it in my initializer list! And I think I believe Valgrind. Because, sometimes everything goes correct and sometimes nothing happens.... So, maybe counter
gets a wrong value and so it takes long until the counter reaches 10.
I already check my code where I use counter for some errors. But I think you can't "un-initialize a value" with a C++ statement...
These are ALL the lines (except in the initializer list) where I use counter
:
counter += speed;
counter = 20.0f;
counter += game->getSpeedFactor();
if (counter >= 15.f)
counter = 15.f;
if (counter > 10.0f)
Valgrind gives the same output for screenAlpha
.
Both variables are private
and I have no friend
classes....
So, what is going on? What the problem could be?
Edit:
I printed the value out:
In the constructor, it was correnct:0
In my method, it was rubbish. It prited random values like:
-97298.8...
-106542.2...
The print statement开发者_StackOverflow社区 is the first line of the method where all assignments to counter
are in.
Second Edit:
Can this be the problem!!??
In my Game
class, I initialize that IntroScreen
like this:
Game::Game() : /* Some other stuff .... */ , view(new IntroScreen(this))`
{}
view
is here a pointer to an abstract super-type of IntroScreen
called View
.
Did you accidentally shadow counter
with a local variable that's uninitialized?
Otherwise, it's possible that valgrind is mid-diagnosing this in an object that was already deleted (using sentry values perhaps).
Or valgrind could just be wrong.
Not enough code to reproduce problem.
Generic SO / developer forum advice:
Do provide a minimal code snippet reproducing the problem.
Quite often (about 85% of all cases in my experience) the process of reducing the code snippet already uncovers the bug for you.
Edit: Your addition still doesn't give a compilable example of your problem, but enough information at least to identify then problem - or, at least, one of them:
Game::Game() : /* Some other stuff .... */ , view(new IntroScreen(this))`
{}
I am not sure whether a new()
call is even legal in an initializer list. But I am sure that you do not have a fully initialized this
at this point, so chances are your IntroScreen
constructor does bogus things.
I found it:
getSpeedFactor()
returns only the first time I call it a complete wrong number because of time-functions like gettimeofday()
. The start value (to time how long it took to update the game) is set initialized to zero and the stop value is micros of the day: which gives a time of the whole day instead of the update time. Once the game loop ran once, the wrong value is corrected (because of the start value gets assigned). But the first time the game-logic was executed, I used getSpeedFactor()
to assign counter
, so that way counter
get a value of -10000...
Thanks all.
Off the top of my head, you may need to define private default and copy constructors that have proper initializers. Haven't used valgrind, but it's a common thing to forget to do.
Just add a debugging printf statement or equivalent, if you have doubts. But I would not believe Valgrind this time.
BTW: delete does not "un-initliase" a value. It deletes object, but the pointer still points to that memory location — it does have a value.
精彩评论