|
when we declare a varible, where does it get stored at?
i know there is heap, stack, and etc.
Can you give me some details on how data structure variables get stored and accessed?
|
|
|
|
|
In a computer there is only one variable storage area, the main computer RAM. But, for the purpose of organization and performance, it is divided into several areas.
When you C/C++ program is started, memory is requested to the operating system to create the heap and the stack. Some may argue that your global variables need a third memory area, but this is not important for this discussion.
The heap is then managed by the C library if you are using C functions, like malloc or new. When you call malloc or new then a portion of the memory allocated at the start of the program is marked as used and returned to you, or, if this memory has exhausted, a new portion is requested to the operating system. If you are using Windows functions, like GlobalAlloc, then the principle is the same, in a sense that the memory you request will be marked as used and returned to you.
Both these memory areas use what we could call the heap (not the stack). They are accessed by dereferencing pointers, like in the code below:
struct S {
int x;
int y;
int z;
};
int main(void) {
S* var_s;
var_s=new S;
if (!var_s) return __LINE__;
var_s->y=20;
}
In this code, the structure S will have a total of 12 bytes (in Win32), because each integer takes 4 bytes. The new will return some relatively unpredictable address in memory, which is not that important. The only important value to check for is zero, which means the requested memory is not available (that's why the "if" statement is there).
The returned address is not important, but for this discussion let's pretend the value 1000 was returned. This value (1000) will thus be stored in var_s (below I'll tell you about where var_s resides). The line...
var_s->y=20;
... dereferences the pointer var_s, that is, uses it's value to access the memory. The var_s->y is thus translated to "memory address 1004", since address 1000 will contain the first of the 4 bytes of the "x" member, 1004 of the "y", and 1008 of the "z". So, after the translation to address 1004, the 4-byte value 20 will be stored there.
Note that even if you check what the value of var_s is, and find out it is 1000, that doesn't mean that your RAM memory chip that contains byte number 1000 is the one being used to store the data. That is because of virtual memory, which is responsible for allocating physical RAM chip addresses and assigning to logical addresses.
When your program starts, another area of memory is allocated, the stack. This memory is just like any other, but it is considered must more volatile, and besides it is also used to memorize where to go to when functions terminate. The stack is considered to be memory like "remember this for a moment while I do something else, and then I will get back to this". So, the organization is such that when you declare local variables (like var_s) a new 4 byte location is appended to the stack.
For example, when your program is started the stack could have been created at address 5000. The address to where the main function should return to is stored there, so a stack pointer will be used to store the value and advance. For example, suppose the 4 byte address value to where main should return when it finished is 7654. Then the stack pointer (which contains the value 5000) is used to place this address on the stack, and so the 4 bytes 5000, 50001, 50002, and 5003 will contain the 4 bytes of address 7654. The stack pointer is then advanced to position 5004.
When your program reaches the declaration of var_s the stack pointer is just advanced from 5004 to 5008, effectivelly allocating 4 bytes (from 5004 to 5007) for var_s. This is why var_s will contain garbage if you do not assign it a value in the declaration.
This variable, the var_s, and the main return address use normal RAM, like any other thing that should be memorized for fast access during execution, but are located in the organized structure we call stack. This fact has several consequences:
1) The address of the variable var_s is always known by using the stack pointer, which is a physical register of the processor.
2) The stack is very dense. Everything is packed together, and only the memory area after the stack pointer is free. Everything else from the start of the stack up to the stack pointer is densely occupied.
3) All the relative addresses of things stored in the stack are predictable. For example, while inside main, the return address could also be known, independently from where your program came from, by reading memory addresses 5000 to 5003 (4 bytes before the address of var_s). In reality, when main begins there is more stuff added to the stack which makes the var_s ocuppy addresses further from the main return address, but still it is possible to check all variables and function return addresses by navigating through the stack.
4) Although everything is accessible in the stack, by navigating in it, new things can be memorized only after previously memorized things. The stack can contain no holes, and that is the main diference to the heap. So, only the most recent things can be forgotten to release stack memory for new things. This means that you cannot forget the address of contents 5000 and use it for storing other things, unless you forget about var_s (at 5004) first.
(let me just point out that I am explaining the stack using the most natural logic but, in reality, the stack pointer is located first at the end of the stack area and is decremented as the stack becomes filled, i.e., the stack fills up backwards)
So, if I understood your question correctly, the answer is: things stored in the stack will occupy very predictable locations in the logical RAM address space. These things include the return address of functions, and local variables (which include parameters passed to functions, but if they are pointers then just the pointer values, not the memory to where they point to). Things allocated with malloc, new, or GlobalAlloc will occupy highly unpredictable locations in the logical RAM address space.
The logical address space has a highly unpredictable relation with physical address space (RAM chips) due to the translations performed by the virtual memory manager. This can even include transformations where the logical address space is larger than the physical space, and the portion that is missing in the RAM chips is allocated on your hard disk.
I hope this helps,
Rilhas
|
|
|
|
|
I wrote a class derived from CSliderCtrl to use the custom draw to paint the control in a dialog based app. I want to disable the focus rectangle from being drawn, but I cannot at all figure it out. Any help / ideas would be greatly appreciated.
|
|
|
|
|
overide the WM_SETFOCUS message. from that funtion, do not call the base calls function.
eg:-
void MySliderCtrl::OnSetFocus(CWnd* pOldWnd)
{
// CSliderCtrl::OnSetFocus(pOldWnd); this line is removed
}
nave
|
|
|
|
|
Hi, thanks for your response. I just tried that and it does not seem to work. When I use the keyboard to move the slider, the focus rectangle still appears.
|
|
|
|
|
It actually *should* work I believe, just that the control doesn't receive keyboard input since it doesn't have focus (if you think about it, if it never receives focus, it never has to draw the focus rect).
Since you can move the slider using the keyboard, it appears that your slider does actually have focus (unless you happen to be forwarding messages from the parent window).
Here's another method that works even though it has focus which I've used before. Just use custom draw and remove the CDIS_FOCUS bit from uItemState (uItemState &= ~CDIS_FOCUS) during the CDDS_PREPAINT phase.
The user might be confused without the focus rect though. I notice that windows media player 11 puts on the focus rect for a while if the slider actually has focus and receives keyboard input.
|
|
|
|
|
THANK YOU....removing that bit works like a charm. Its weird tho, because i figured the override OnSetFocus would've worked too, but it did not. And you were correct, I am forwarding WM_KEYDOWN messages from the parent window to the slider. I guess thats why. Thanks very much for your help.
|
|
|
|
|
I want to use CxImage (or others) to open multiple types of images (gif,jpg,bmp,ico etc) then transfer image files in memory (not save to disk) in bitmap format which includes BITMAPINFOHEADER and data.
any comments for how to use CxImage (or others) to do that?
|
|
|
|
|
I think you can use CImage by including atlimage.h if you are not using VC6.0
There is no dumb question
<bjay zhu@shanghai,="" china<="" b="">
|
|
|
|
|
Hey, i've used this lib in my app and it's really easy to use.
Read the docs that tell you which libs to include (depending on what image support you want) include them in your project, include the main header somewhere in your source.
bool CxImage::Load ( const TCHAR * filename, <br />
DWORD imagetype = 0 <br />
) [inherited]
Reads from disk the image in a specific format.
If decoding fails using the specified image format, the function will try the automatic file format recognition.
Parameters:
filename: file name
imagetype: file format, see ENUM_CXIMAGE_FORMATS
Returns:
true if everything is ok
bool CxImage::Encode ( BYTE *& buffer, <br />
long & size, <br />
DWORD imagetype <br />
) [inherited]
Saves to memory buffer the image in a specific format.
Parameters:
buffer: output memory buffer pointer. Must be NULL, the function allocates and fill the memory, the application must free the buffer, see also FreeMemory().
size: output memory buffer size.
imagetype: file format, see ENUM_CXIMAGE_FORMATS
use the Get...() functions to fill the header info
|
|
|
|
|
Hi!
I want change Import Table of a pe file.
I want to add api functions, that they aren't in Import Table.
For example if "LoadLibraryA" Function there isn't in listed functions of Import Table,
I want to add it to Import Table of file,
then with software tools, i see this function in listed functions.
Zo.Naderi-Iran
|
|
|
|
|
Hi,
I had created one MFC project without ATL support.
I want to use CImage class in my program.
I tried to put the header file "atlimage.h" & "afxstr.h" in my dialogs
.h file. ( As said in one MSDN article.)
But i got the following error !
"fatal error C1083: Cannot open include file: 'atlimage.h': No such file or directory "
Is it possible to insert ATL/MFC shared classes in VC++ 6?
Is there any other way to do it ?
Thanks in advance....
vinsankar
|
|
|
|
|
|
Hi,
So , I cannot use CImage in VC++ 6.0
Is there any way put a JPEG image to my Dialog background.
I tried to use "CBitmapPicture" class provided with one of the codeproject article.
But It uses a static picture control to display the JPG file.
But when I used it in my project, I got an error.
How will I load a JPG image and fill my dialog background without using static controls?
Can any one help me ?
thanks in advance.....
vinsankar
|
|
|
|
|
u can use the Image class in the GDI+
nave
|
|
|
|
|
You can use OleLoadPicture or GDI+(Graphics and Image::FromFile(...) instead CImage class
|
|
|
|
|
Hi Please make me Done...
I have to connect MS Access database and retrieve data from vc++....
Can any please guide me or provide me link to study , i am new to vc++....
thanks in ADvaNcE
Hai this is fresh programer
|
|
|
|
|
See Here.[^]
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
|
can anyone tell me why i get a compilation error in vs2002 whenever i try to use cimage or cdc?
it says:
error C2065: 'CImage' : undeclared identifier
and
error C2065: 'CDC' : undeclared identifier
ive reinstalled vs and it didnt help.
thanks for the help!
|
|
|
|
|
UnderWing wrote: i try to use cimage or cdc
What type of application are you working on? MFC, SDK
I think that CImage class is provided in VC7.0(.NET 2003)
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
You need to include AtlImage.h
|
|
|
|
|
And for CDC you need to Afxwin.h
|
|
|
|
|
thanks for the replies.
im creating an mfc app.
i can use cimage after including AtlImage.h, but if i include afxwin.h i get:
fatal error C1189: #error : WINDOWS.H already included. MFC apps must not #include <windows.h><br />
any other suggestions? thanks
-- modified at 13:10 Saturday 29th July, 2006
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
