On Monday 31 March 2003 01:03 pm, Jerry Feldman wrote:
On Mon, 31 Mar 2003 10:48:43 -0500
"Steven T. Hatton"
wrote: Let me refine this. Upon reflection, I realized what I said is only accurate regarding fundamental types. Objects are the other way around. I have to tell them to go away explicitly, or they just sit there and take space. And if I don't to that before I remove the last pointer to the object, then I have not way to access the destructor.
When a variable goes out of scope, a destructor is called.
That is a variable. What about anonymous objects? I believe such a concept is meaningful in C++, e.g., the elements of a linked list. If I start removing elements form such a list without explicitly destroying them, I could end up with object occupying memory, yet having no reference to them withing my program. Is this not true? If you've been following any of the saga of my KDE/QT/KDevelop woes, you will understand that I haven't had a lot of time to follow up on these topics. I did get to thinking about your comments regarding defining a class in the header, and it's methods in the 'source' file. There are a few things I'm not sure of regarding classes. With time, and further reading, I suspect these will become clear, but it probably doesn't hurt to mention them. As I understand things, the class definion itself is in a favored position to go on the stack rather than the heap. This could mean different things depending on the details. I assume the static members would only appear once in the run-time image. If we say a method gets put on the stack, what we really mean is it's local variables and return pointer are placed on the stack. Methods defined within the body of the class definions are default /inline/ meaning they 'should' go on the stack. My understanding is that member variables cannot be initialized within the class definiton. Functions can, however, be completely defined within the class definition. And here again, is a point of some confusion. Experimentation indicates to me that classes *are* initialized by their default constructor when declared in the body of the class declaration. So class MyClass { private: MyMember mm; int myInt; } If MyMember has an initializer in its constructor, its variables can be initialized by the implicit invocation of the constructor resulting from the declaration. myInt, however will not be initialized, and cannot be initialized at the point shown above. Part of what I'm trying to get a handle on is the way a class instance and it's members will be represented in memory. It seems possible, if not likely, some parts may go on the stack while other perts go in the heap. In particular, it seems member variables might go on the heap. The original question that started me down this road has to do with the actual size of a pointer to an object of a given type, and also the amount by which such a pointer will be incremented with, for example ptr++. Are these notions about pointer size and pointer incrementation easy to explain?
Gerald Feldman
STH