Initializer list makes variable uninitialized?

Question

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 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.

Answer 1

Could 15.f be the problem?

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.