|
Christian Flutcher wrote: 1 - Person anotherPerson is declared but not initialized. But still calls to anotherPerson.GetName() worked. How this is happening?
The compiler provides a default constructor for the class. So when you create an object for the class the default constructor gets invoked and the object is initialized.
Christian Flutcher wrote: 2 - Is there any difference when allocating memory for *person and anotherPerson?
Yes. The memory is allocated from heap in case you use new (ie *person), otherwise it is allocated from stack.
Christian Flutcher wrote: 3 - I know we should delete the pointer variables to claim memory. But AFAIK, there is no need to delete the anotherPerson variable. How it gets removed from memory?
The memory allocated is returned to the stack once the object goes out of scope
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
modified on Friday, September 5, 2008 1:33 AM
|
|
|
|
|
Thanks 
_AnShUmAn_ wrote: Yes. The memory is allocated from heap in case you use new (ie *person), otherwise it is allocated from stack.
Well, so which one is the recommended practice? use pointer variables always and delete after usage or use the normal one which goes to stack?
|
|
|
|
|
Depends really of the situation, sometimes you will need to use pointers so you don't have a choice. I tend to prefer using variables on the stack rather than on the heap when I can. Allocating/deallocating a lot of variables on the heap can lead to memory fragmentation which can be an issue if you tend to do it a lot. Furthermore, the cost (in time) of creating an object on the heap is a bit higher than creating an object on the stack.
|
|
|
|
|
Cedric Moonen wrote: Allocating/deallocating a lot of variables on the heap can lead to memory fragmentation which can be an issue if you tend to do it a lot
Are there any rules which should be considered when instantiating objects? How do you decide where the object should go? I am bit confused 
|
|
|
|
|
No, there's no rule for this but in most of the cases, it's not a big problem if you allocate a variable on the heap or on the stack. One point to remember is that variables on the stack will be destroyed when they go out of scope. So, if you have a variable which is local to a function, this variable will be destroyed when the function exits.
Or if you want a simple rule: try to allocate variables on the stack when you can.
|
|
|
|
|
Thanks Cedric. Your help is much appreciated.
|
|
|
|
|
The stack is where memory is allocated for automatic variables within functions. The memory allocated in the stack area is used and reused during program execution. It should be clear that memory allocated in this area will contain garbage values left over from previous usage.
The heap segment provides more stable storage of data for a program; memory allocated in the heap remains in existence for the duration of a program. Therefore, global variables (storage class external), and static variables are allocated on the heap. The memory allocated in the heap area, if initialized to zero at program start, remains zero until the program makes use of it. Thus, the heap area need not contain garbage.
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
_AnShUmAn_ wrote: It should be clear that memory allocated in this area will contain garbage values left over from previous usage.
Correct me if I'm wrong, this may be true in case of Windows, but not for all other OS. That was my experience with Solaris, at least.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
I have never worked on Solaris platform but as for as windows is concerned this is correct
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
_AnShUmAn_ wrote: Therefore, global variables (storage class external), and static variables are allocated on the heap
A small correction. They are actually store in the .data section or .rdata section of the applications.
|
|
|
|
|
Christian Flutcher wrote: Well, so which one is the recommended practice? use pointer variables always and delete after usage or use the normal one which goes to stack?
Generally, it is advisable to use the stack as much as possible. At the same time, you should also know that the stack would not have very large and if you go on "pushing" data into the stack, that might result in a Stack overflow[^], which would kill your program.
The heap, on the other hand is comparatively large and can be used to store huge variables, can be used when the memory allocated should not be cleaned up even if the variable goes out of scope (you will need to clean it up). You don't clean it up and the memory can go fragmented over a period of time. If this happens, your program will suffer from a serious performance degradation.
There is way much more for typing in a message, Google for "Stack vs Heap" and you'll get to read loads of interesting stuff. 
See here as well: http://www.gotw.ca/gotw/009.htm[^]
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
Rajesh,
Nice to see your reply. As you said all pointers are created on heap and others are on stack. Consider the following one
Person person;
Person *personPointer = &person;
|
|
|
|
|
The pointer itself is on the stack but it contains the address of another variable. This address can either be in stack or in heap (it depends where you allocated it).
Don't forget that pointers are variables too (they simply contain an address).
|
|
|
|
|
Christian Flutcher wrote: As you said all pointers are created on heap and others are on stack
Please, don't accuse me of saying such a thing. I never said it.
Heap memory will be allocated whenever you use the new operator for allocating memory or whenever you use dynamic memory allocation functions like malloc(), calloc(), etc., 
Christian Flutcher wrote: Person *personPointer = &person; // Where this will go?
Will be on the stack.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
Oops It was not you. My appologies.
|
|
|
|
|
No need to apologize, I was just kidding.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
Hi,
1. In Person anotherPerson, nothing is initialized then it will get Person::Person() constructor. So 'Unknown' will be the name and '0' will be the age.
2. you may be knowing about the difference between *person and anotherPerson is References vs. Pointers.
The price of anything is the amount of life you exchange for it.
Thanks and Regards.
SANTHOSH V
|
|
|
|
|
Thank you santhosh. Your help is much appreciated.
|
|
|
|
|
using innosetup while adding different folders (i.e "database" folder name )
i m using static path C:\database as destination folder so that during run time application gets files from database folder but if user or client machine has no directory such as C:\ or with different name then how it could be handled........
|
|
|
|
|
Hi,
Don`t ever give absolute path for files and database.
Always use relative path, then only your application can be safe if you are transferring it into client machine..
Use like this
CString path = "Database/data.mdb";
The price of anything is the amount of life you exchange for it.
Thanks and Regards.
SANTHOSH V
|
|
|
|
|
if i used path like this
CString path = "Database/data.mdb";
and i create exe and when install on other mashine and user run application from desktop then my application became unable to fine Database folder
error occurs
there is invalid path "C:\documents and settings\users\abc\desktop\database\data.mdb"
|
|
|
|
|
Hi,
You may not given the database file in the setup..
In the Setup file you need to add the database file.
you need to create a folder Database and add the database file in the folder.
The price of anything is the amount of life you exchange for it.
Thanks and Regards.
SANTHOSH V
|
|
|
|
|
You should use relative path.
To over come your problem you can use
GetModuleFileName[^] Function to get the executable path and add the path before "Database/data.mdb"
I hope that makes sense.
Regards,
Sandip.
|
|
|
|
|
in have created a struct info in my exe and i have set a value for cstringi.e. struct info{
CString name}.and i have set value for it in exe itself . Now i want to show that vale for name in my name editbox which is in DLL...
can any one tell how to call struct of exe into dll which show value of it(exe) in DLL..
|
|
|
|
|
Shared Memory[^]
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
