(07-18-2023, 05:04 PM)SMcNeill Wrote:(07-18-2023, 04:49 PM)SagaraS Wrote: The output shows you the memory addresses that are reserved for the variables.This isn't guaranteed. It's up to the OS to decide where your variables go. If it's a clean run of a program, things might fall into a pattern of being one after the other, but that's not guaranteed. Once you get to the point that you're starting to free memory and reuse memory and redimension memory and all that, the position of where variables and such all fall in memory gets shuffled into unpredictable order. You really can't count it variable2 being 4 bytes after variable 1 and 4 bytes before variable3, or any such thing as that. If you want to know where a variable is stored in memory, use _OFFSET to get that value back for yourself, or else you might end up changing things you don't intend to.
Since they all follow each other in memory, you can view the addresses in a memory viewer.
I double this comment especially in 32-bit introducing multitasking and threads, and 64-bit introducing multi-processing. A memory allocator that "consecutively" allocates blocks is not desireable if it were possible.
Quote:If it's a clean run of a program, things might fall into a pattern of being one after the other, but that's not guaranteed.
This has to be emphasized even more because it applies only to the same run of the same executable file state. Once one change, however minor is made to the program that is compiled to that executable, things are thrown out of whack. This was easily shown by old "DEBUG" program in MS-DOS while trying to step through a dot-COM file.