Jump to content
  • Advertisement
Sign in to follow this  
xSKOTTIEx

static const gone crazy

This topic is 4863 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

On the top of a cpp file, i make a declaration like this: static const float SCALE_SPEED = 0.5f; I use this when scaling my sprites for my weapon selector, thusly: (psuedo code) sprite->SetScale( sprite->GetScale() + SCALE_SPEED * timeDelta ); or something to that effect. (actually the sprite doesnt have a scale memeber, im just doing it that way for simplicity ). either way, the sprite instantly reaches its scale cap (1.25, it started at 1). Logic suggests this should take only half a second, not an instant. Through some debugging, I found that SCALE_SPEED, during runtime, is probably closer to 12030923498.000000 then it is 0.5.. it works when i replace the const with an integer. How is my const going crazy? It looks like a memory issue, but I cant track it down.

Share this post


Link to post
Share on other sites
Advertisement
Well that sounds mighty odd to me, what compiler are you using? have you tried making a complete fresh build?

On a side note in C++ using the keyword static to create an internal linkage is deprecated to obtain the same effect you should use anonymous namespaces. Also constant don't typically consume memory except under certain conditions such as; in debug mode, taking the address of a named constant etc.

Share this post


Link to post
Share on other sites
is the static const variable being used by another static object? if so, the initialization may be occuring in a different order than you expect:

From the C++ FAQ Lite
Quote:

[10.12] What's the "static initialization order fiasco"?
A subtle way to crash your program.

The static initialization order fiasco is a very subtle and commonly misunderstood aspect of C++. Unfortunately it's very hard to detect — the errors occur before main() begins.

In short, suppose you have two static objects x and y which exist in separate source files, say x.cpp and y.cpp. Suppose further that the initialization for the y object (typically the y object's constructor) calls some method on the x object.

That's it. It's that simple.

The tragedy is that you have a 50%-50% chance of dying. If the compilation unit for x.cpp happens to get initialized first, all is well. But if the compilation unit for y.cpp get initialized first, then y's initialization will get run before x's initialization, and you're toast. E.g., y's constructor could call a method on the x object, yet the x object hasn't yet been constructed.

I hear they're hiring down at McDonalds. Enjoy your new job flipping burgers.

If you think it's "exciting" to play Russian Roulette with live rounds in half the chambers, you can stop reading here. On the other hand if you like to improve your chances of survival by preventing disasters in a systematic way, you probably want to read the next FAQ.

Note: The static initialization order fiasco can also, in some cases, apply to built-in/intrinsic types.


right now, thats all i can think of that could be happening.

Share this post


Link to post
Share on other sites
Fundamental types aren't affected by the static initialization order problem since the value is compiled right into the executable. There is no initialization happening with fundamental types like ints and floats. In this case it's a static const so generally the value won't even exist in memory at all - it's treated much like a type safe #define by the compiler. Storage will probably not even be allocated unless you take it's address.

Share this post


Link to post
Share on other sites
right, i didn't think so either, but that faq does say it can apply to builtin types in some instances (though i've never seen it happen, personally) and i'm pretty much at a loss at explaining it otherwise. its a wierd problem. i wonder what would happen if the static const was replaced with a #define, just as a test.

Share this post


Link to post
Share on other sites
Quote:
Original post by workingclass77
right, i didn't think so either, but that faq does say it can apply to builtin types in some instances (though i've never seen it happen, personally) and i'm pretty much at a loss at explaining it otherwise. its a wierd problem. i wonder what would happen if the static const was replaced with a #define, just as a test.


When i get home from work, ill try to make it a define. a co-worker of mine suggested the same thing.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!