Jump to content
  • Advertisement

Archived

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

Nervo

Win32 question

This topic is 5279 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

In Petzolds book, he has a statement that says
quote:
char a[] = "hello"; if you define this array as a local variable to a function, it must be defined as a static variable as follows: static char a[] = "hello";
Well, I do understand what a static is of course, but what puzzles me if why does it have to be static? What could happen if I just declared it on the stack? The book gives no explanation and neither does my searches through google.

Share this post


Link to post
Share on other sites
Advertisement
That quote is awfully short on context. How does he use that a[] variable? It could be that it needs to outlive the stack frame that the function call lives in.

Share this post


Link to post
Share on other sites
I'm just speaking of chapter 2 on page 27 here. There is specific context he's speaking of[EDIT: Well actually there isn't]. The section its in is just titled "The char data type"


He's saying that a char array, if global, does not need a static declaration so char a[] = "blah" is fine

[edited by - nervo on February 8, 2004 3:44:16 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Ademan555
It doesn''t, hes speaking about inside the WndProc because tahts a separate thread...


WndProc isn''t even discussed until chapter 3. Well, I just don''t know what he''s talking about but obviously a static declaration does not seem to be needed in all cases. ugh.

Share this post


Link to post
Share on other sites
If you try to return the variable and its not static, then its declared on the stack (as you said). When the function returns, the stack pointer gets shifted, and whatever was in the stack frame for the function gets lost (well, it doesn''t immediately, but it gets marked as free). So, the string will get corrupted.
Actually, constant strings are stored inside the exe file, and when you return one from a function you get the address of the string in the processes address space. To see what i mean, try this:

const char* foo() {return "Hello World!";}
int main(int argc char** argv)
{
printf("0x%08X\n",foo());
}

You should get some value thats just over 0x00400000

Share this post


Link to post
Share on other sites
quote:
Original post by Evil Steve
If you try to return the variable and its not static, then its declared on the stack (as you said). When the function returns, the stack pointer gets shifted, and whatever was in the stack frame for the function gets lost (well, it doesn't immediately, but it gets marked as free). So, the string will get corrupted.
Actually, constant strings are stored inside the exe file, and when you return one from a function you get the address of the string in the processes address space. To see what i mean, try this:

const char* foo() {return "Hello World!";}
int main(int argc char** argv)
{
printf("0x%08X\n",foo());
}

You should get some value thats just over 0x00400000




I do get the fact of non-static being popped off the stack. I guess I just need to work with more win32 examples where persistence of a char array would be critical. Its just that that the book just shoved it in my face without giving me specific win32 example where something might bomb without it. (I generally hate accepting something just because the author said so)

So with that said then, I suppose that now I should just declare all char arrays as static inside a function or just do a char* x = "whatever";

EDIT: Perhaps what the author might have implied was that if I want a variable to have persistence I could declare it global, or if local to a function, then do a static char....I'm going with that one. >_<

[edited by - nervo on February 8, 2004 4:19:58 PM]

Share this post


Link to post
Share on other sites

  • 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!