Remember that tmp is an automatic variable. When you exit the HelloClass constructor, the storage for tmp is released and may (or let's say will be) used in another function. Automatic variables are fundamental to C and C++. Any variable you define within the scope of a function that does not have the static keyword is an automatic variable, and has block scope. Pointers are very simple, they are simply data types that hold a memory address. char *s = "abc"; s will contain the address of a 4 byte chunk of memory containing 'a' 'b' 'c' '\0' string *str = new string("abc"); Similarly, str will contain the address of a string class that you have allocated with the new operator. Note that "string" is a C++ class, and has overhead, such as constructors, destructors, manipulation functions, and several variables as well as a pointer to the actual data. Let's get back to pointers. In the above example, str points to a string class. Now, let's change it a bit. str = new string("def"); In this case, we have replaced the existing pointer value with a new one, thus causing a memory leak. That is because we did not delete the space for the old value. Unlike Java, neither C nor C++ will automatically reclaim unused allocated memory. Java has a builtin garbage collection system. So, as a C or C++ programmer, you need to make sure that memory you allocate is reclaimed. Within a class, that may be done in a destructor or in your case, HelloClass::setMessagePtr should check this->messagePtr to see if it already contains a pointer. Also, you do not need to use this-> in a class member function, it is assumed. I hope that the above information has been useful.

On Monday 31 March 2003 10:08 am, Steven T. Hatton wrote:

...

I hope that the above information has been useful.

Indeed. I guess the most important thing I got out of it is that pointers don't control the memory they point to. I guess I knew that at one point, I just got used to Java's way of keeping track of references. The same can be done in C++, but we have to do it ourselves. If I want to keep the data in a variable from getting zapped, I have to keep the variable alive(in scope, or static). Is that pretty much a correct statement?

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.

STH

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. I suggest that when you are learning C++, start by writing your own classes. Then, once you understand the language, then start using the STL and other class libraries. The STL has a large number of container types, such as vector, link lists, trees et. al. But, while these are great to use, the details of the implementation are hidden. That's not a bad thing, but when you are learning a language you are not learning some of the finer points of that language. For instance, a person who does not know Java can pick up JBuilder and build some programs, but not lean how to write Java code. In C++, you should first lean the basics of

On Mon, 31 Mar 2003 10:48:43 -0500 "Steven T. Hatton" wrote: the language, then move up to writing some classes. Then learn multiple inheritance and templates. The problem is the time tradeoff. Most of us want to be productive and get something out the door, or use the skills on the job. -- -- Gerald Feldman Boston Computer Solutions and Consulting ICQ#156300 PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

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. I suggest that when you are learning C++, start by writing your own classes. Then, once you understand the language, then start using the STL and other class libraries. The STL has a large number of container types, such as vector, link lists, trees et. al. But, while these are great to use, the details of the implementation are hidden. That's not a bad thing, but when you are learning a language you are not learning some of the finer points of that language. For instance, a person who does not know Java can pick up JBuilder and build some programs, but not lean how to write Java code.

This is true to some extent, but I've found the GUI builders, and other wizards are often more trouble than they're worth. I tend to use them to generate samples that I look at to figure out how to accomplish what I really want. The one place were JBuilder did prove really helpful was in getting me started with servlets. The Apache Tomcat is configured and ready to run out of the box. I was able to click on new servlet, build, run, and I had a working servlet. But that doesn't do much on its own. The biggest advantage in using something like JBuilder is that it helps organize the project, and provides quick access to resources such as class browsers, code completion, on-line documentation, etc. But the Java world in general is oriented that way.

In C++, you should first lean the basics of the language, then move up to writing some classes.

Part of the problem is I'm re-learning. There was a time I knew C fairly well. Not to say I was a good C programmer, I just had a pretty complete understanding of the basics of the language. I do need to continue reading up on C++. Unfortunately, I don't know of anything for C++ equivalent to K&R, Cooper's Pascal book, Arnold, Gosling, and Holmes's Java book, or Flanagan's JavaScript book. Then again, I haven't been looking. I'm kind of limited in what I can buy right now. I also haven't been able to focus on the language as much as I would like due to the problems I've been having with my KDevelop setup. Hopefully I have that stabilized, and won't need to mess with it for a while. I'll have to go back and forth between using KDevelop and XEmacs while learning C++. KDevelop and the QT Designer do provide a useful framework. But as you've pointed out, they don't teach the language. That's why I cracked open XEmacs and tried to write a hello world. When I got the deprication messages I tried to find out how I should be writing a hello world. The books I have were no help. I was using the example code from these books. That's when I came on this list. There has to be a better way of getting started than this. Are there any good books that teach C++ using these new standard libraries? I.e., a book that starts with the kind of hello world I ended up with after a few iterations?

Then learn multiple inheritance and templates. The problem is the time tradeoff. Most of us want to be productive and get something out the door, or use the skills on the job.

That can be quite frustrating. It's not like the good old days when someone could ask you how long it will take you to plough the field. You could go ask your grand dad how long it should take. Now people want to know how long it will take you to do something that no one knows how to do, or at least you don't know how to do it. If you knew, it would be done! And then there's doing things correctly. That's where really knowing the language, and all the nuances comes in.

-- -- Gerald Feldman Boston Computer Solutions and Consulting ICQ#156300 PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

<massive snip>

There has to be a better way of getting started than this. Are there any good books that teach C++ using these new standard libraries? I.e., a book that starts with the kind of hello world I ended up with after a few iterations?

<massive snip> I've been happy with these two C++ textbooks: Deitel's "C++ How to Program" and Bruce Eckel's "Thinking in C++" Here's Bruce Eckel's page from which you can download free books: http://www.mindview.net/Books The Classroom CDROMs are a good way to learn as well. Cheers

I am looking for a self-contained presentation of the language that introduces the components of the language in a mathematical spirit.

Appendix A of the Stroustrup book contains a complete grammar of the language. If you consider that to be a useful tool for learning a language, you go right ahead and digest it!

I'm wondering if this would be a good choice: "C++ Programming Language, The: Special Edition , Third Edition" http://www.awprofessional.com/catalog/product.asp?product_id={DD9AAB03-6085 -4008-A260-09D1F7592386} If it's similar to Ellis & Stroustrup's Book, it's not what I'm looking for.

I've not been following the thread, so I thought this book had been discussed. It's the definitive tome, the K&R of C++. It's the book I mention above, with the grammar in Appendix A. I have the paperback version which has a different cover and ISBN number, but the table of contents is identical to my copy. It's a pig to read - very heavy going - but if you're after the definitive work on the language with every single feature[*] guaranteed to be covered, that's the book to have. [*] GNU GCC extensions not included. :o) -- "...our desktop is falling behind stability-wise and feature wise to KDE ...when I went to Mexico in December to the facility where we launched gnome, they had all switched to KDE3." - Miguel de Icaza, March 2003

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

Steven T. Hatton wrote:

...

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.

Yes, but you should always keep a pointer to an object until it is deleted. It is possible to create an anonymous object (just use new X(); without an assignment) or to throw away a pointer (just create an object with new in a function and don't pass the pointer value when the function finishes), but these are bad practices. Unfortunately C++ doesn't have any garbage collection like java does, though you could look at the auto_ptr class. Distinguish between 'anonymous object', which is not used as a term in C++ AFAIK, and 'anonymous class', which is. For example, below, ratio is an object of an anonymous class, used together with operator overloading to create a local object that behaves like a function. This technique is a bit obscure, but becomes useful in the Standard Template Library. #include<iostream> using namespace std; int main(){ struct { double operator()( double x, double y ){ return x / y; } } ratio; double d = ratio( 1, 2 ); cout << d << endl; cout << 1 / 2 << endl; exit( 0 ); }

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?

Yes, which is why you should handle this carefully. For example, you could use a class to handle the linked list, with a member function for adding/removing elements. Then the member function is responsible for tidying up the heap. Here, I would use the STL or Qt version of the linked list, which already handles such things safely.

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.

The separation between class declaration and class definition affects compiling rather than where a class is defined. In fact, you can't define a class on the heap, only objects of the class. Your code may contain more than one copy of a class member function definition, but only as an accident of the way it was compiled. If you separate the declaration from the definition by using a header file, you don't get copies of member functions in the object code.

My understanding is that member variables cannot be initialized within the class definiton.

At least, not within the class declaration. This wouldn't make sense except for static member variables because they take different values for different classes. Static member variables can be initialised outside the class declaration with a statement like double A::pi = 3.1415926536 I think you can initialise ints withing the declaration. Usually, you would only initialise static consts and not in the header file (otherwise you'll get an error if you read the header twice). Functions can, however, be completely defined within the

class definition.

Yes, but their local variables are not defined until the member function is called and each object gets it's own copy of a nonstatic member function's variables. 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.

Yes: MyMember is an object but MyClass is a class.

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.

It's probably not useful to think about stack and heap unless you're writing your own compiler. Think instead that anything created with new must be destroyed by delete; otherwise the thing gets destroyed when it is out of scope.

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++.

ptr++ will be incremented by the size of the type to which ptr is a pointer.

Are these notions about pointer size and pointer incrementation easy to explain?

Relatively. The compiler knows the size of an object of any given type and know the type of any given pointer; so given that ptr has type *my_type, ptr++ will add sizeof( my_type ) to ptr. This fact is only useful, of course, if you know that an array or my_type occupies a contiguous area of memory in which each my_type object occupies sizeof(my_type).

STH

-- JDL

On Sunday 06 April 2003 01:54 pm, Jerry Feldman wrote:

On Sun, 6 Apr 2003 10:09:41 -0500

"Steven T. Hatton" wrote:

A class definition does not take up any memory, just as a structure definition does not. It is the instance of a class that allocates memory.

Yes, my statement doesn't really make a lot of sense now that I think about it. What matters is not how the class is defined, but rather how objects of that type are instantiated.

If you allocate a class as an automatic variable, that instance will be allocated in the stack.

I'm still fumbling about with some of these notions. The /new/ operator returns a pointer to an object of the class upon which it was called. If I simply declare a variable of that type, it seems to be created, and the default constructor seems to be called to initialize its members. But it would seem this is not synonymous with an implicit invocation of new. For one thing, the object is accessible through a variable name rather than a pointer reference. Now if I do something like void doThis() { MyClass mc; mc.myMethod(); } I implicitly create an instance of MyClass and set the variable mc to hold that object. If, in turn, MyClass has a member variable of some object type, that is created in a similar manner. I assume this member object is destroyed when its owner is destroyed. Correct? Would it also be correct to assume these are created on the stack rather than the heap?

If you use the new operator, it will be allocated on the heap. remember, that all objects allocated on the stack are implicitly destroyed when the function returns to the caller.

I believe I have figured out part of the problem I referred to earlier regarding the difference between member variables of derived types and member variables which are pointers to objects of the same type. I failed to realize that /new/ returns a pointer. I was therefore gettng strange results when I attempted things such as this->mm = new MyMember(); But this raises an interesting question. How would I do such a thing? If I have member pointers to objects, then it is incumbent upon me to be sure they are destroyed when they are no longer necessary. If I use member variables, and somehow assign to them within a function call, it would seem these would be destroyed when the function returned, which is very likely not what I would want. This sho' anin't Java. ;-) Here's an example of what I'm talking about. I have a class derived from QTextEdit which I wanted to hold as a member variable of a manager class. I was taking your advice about the overhead of using pointers (though it's probably insignificant in this context.) I was also thinking it would be cleaner to manage in the sense described above. The problem I encountered is that I could not figure out a way to pass /this/ as an argument from within the constructor when instantiating the children. I'm trying to have another go at that, but it's going to take me a bit to reconstruct the exact circumstances where I had the problem. I wanted to post an example, but I've been delaying sending this out for too long already.

...

Are these notions about pointer size and pointer incrementation easy to explain?

non-static and non-constant class members are not initialized in the class, but are normally initialized by the constructor for that class, but they can be initialized with a member initialization list. Using above class: inline MyClass::MyClass():myInt(0) {}

Hmmm. Thanks. I'll have to play with that a bit.

WRT: Pointers: int i[10]; int *p; To use the pointer, p to step through the array: for(p = i;p < &i[10]; p++) { *p = <some expression>; } Note that &i[10] is a constant expression and will be evaluated at compile time. The expression, p++, is a postincrement of p, and on a system with a 32 bit int, the address contained in p will be incremented by 4. However, when you use a modern compiler, subscripts are more efficient than pointers because the compiler can more easily figure out what you are doing and generate some more efficient code.

The bottom line, is that when you are doing pointer arithmetic, the size of the object that pointer points to is taken into account: So, as above, p + 1 effectively adds 4 to p.

I wasn't sure about the 'p + 1' part, but I did recall the part about incrementing by the 'size' of the object. My curiosity lies with the true meaning of 'size of the object'. This relates back to my awkward errant attempt to explain how memory is allocated for a class. I recall a frient of mine - who is pretty well versed in C - stated that the data in an array goes on the stack. That would mean 'p + 1' is referring to memory locations of the stack, and not the heap. This further suggests to me that an object with an array as a member would be larger than the array, and thus a pointer ptr to that class would increment by a number potentially much larger than 4. Do you see what I'm getting at?

Gerald Feldman

STH

On Monday 07 April 2003 02:39 am, Anders Johansson wrote:

On Monday 07 April 2003 07:08, Steven T. Hatton wrote:

...

I wasn't sure about the 'p + 1' part, but I did recall the part about incrementing by the 'size' of the object. My curiosity lies with the true meaning of 'size of the object'. This relates back to my awkward errant attempt to explain how memory is allocated for a class. I recall a frient of mine - who is pretty well versed in C - stated that the data in an array goes on the stack. That would mean 'p + 1' is referring to memory locations of the stack, and not the heap.

Jerry seems to know what he's talking about. I am operating on the assumption that these things are implementation details, and what Jerry is explaining is the 'recommended' implementation. Some of my questions are simply academic curiousity. It does help me to try and formulate these questions. It causes me to think about how to express what I'm doing in technically accurate terms.

I think you're looking too closely at details here. The C language doesn't define where things are stored, stack and heap are implementation details of the compiler, not part of the language.

I believe there are a few exceptions to that, but, in general you are correct. What I'm most interested in how to manage memory, and construct runtime object graphs.

If you want to learn the languages quickly, I would suggest you try to take a couple of steps back and focus on the bigger picture. I don't think it's pedagogically right to get bogged down in how gcc implements things.

I really don't want to spend too much time on this topic, but it has its importance. For example, in security, it's important to understand how, when, and where things are loaded into memory. And as I said, it helps me think about what I'm actually doing. That is, what *is* a runtime instance of a class? Where it goes, stack or heap, isn't so important, but the distinctions between pointer, variable, reference, automatic, static, etc., are.

Just a suggestion

I will agree that it's dangerous to try to exploit implementation details of a language which are not specified in defining document. I got bit hard by that when I tried to use an example my Professor gave of how to get the lenght of a string in Pascal by playing with the 0th element. It didn't work on a PC the same way it did on the Vax.

Anders

The question remains. How big is an object? What does sizeof really mean? Also, what's the lifetime of a member variable of derived type when created as a side effect of implicit (automatic?) instantiation in a function call variable declaration? STH

On Monday 07 April 2003 09:34, Steven T. Hatton wrote:

Jerry seems to know what he's talking about.

I don't remember questioning that. I know he knows far more than I about c++

The question remains. How big is an object? What does sizeof really mean?

An object is the size of its members. Plus all objects of a class share the methods of that class. Plus possible padding bytes (don't know about that one, but C sometimes does that for structs and unions, to align the data on word boundaries. I guess c++ does the same, but I don't know). sizeof returns the size of the parameter. I think sizeof for an object returns the dynamic size of that instance. i.e. not counting the methods it shares with other objects of that class.

Also, what's the lifetime of a member variable of derived type when created as a side effect of implicit (automatic?) instantiation in a function call variable declaration?

If I understand the question, I would say from the time the function is called to the time the function returns.

On Monday 07 April 2003 11:09 am, Jerry Feldman wrote:

On Mon, 7 Apr 2003 00:08:54 -0500

"Steven T. Hatton" wrote:

...

Yes, my statement doesn't really make a lot of sense now that I think about it. What matters is not how the class is defined, but rather how objects of that type are instantiated.

A class definition is saved in the compiler's memory space during compilation. Non-inline functions certainly do take up space in your program's text segment (usually). class static variables are generally allocated in the program's data segment. But the rest of the class is simply a template for the compiler to use when the class is instatiated.

Did you really mean 'compiler' here? I'm way out in unfamiliar territory here, but I would guess it is the OS kernel which uses this 'template' for instantiation. I'm trying to recall if the actual instructions of a function get placed on the stack. My guess is, instructions *do* get placed on the stack along with local variables.

As Anders mentioned, there are a lot of implementaiton details. How the compiler actually allocates the storage for the class once instatiated is up to the compiler. In general, automatic variables (eg. those vatiables that exist inside of a function) are allocated on the stack.

I can tell I need to really hit the books if I want to understand this stuff. As I recall from years ago, the compiler does have a lot to do with the runtime behavior of the program. Nonetheless, the compiler has already done its job, and the kernel is the component actually doing the instantiation of classes as objects, and the memory allocation. I'm sure you know this, and are simply using a manner of speaking which implies as much. I'm just pointing out that there is yet more involved than the compiler.

In this case. mc is allocated as a local variable. The compiler may allocate some components of the class on the heap, or it may mmap them. But, they will behave as if they were local variables. When you return from doThis(), the storage for mc will be returned back to the system. void doThis() { MyClass *mc = new MyClass; mc->myMethod(); } In this case, the storage for mc will be allocated in a persistent mannter, classically on the heap, but the compiler may mmap it. When you return from doThis, the variable mc (eg. the pointer) goes out of scope, and you have a memory leak.

Yes. This is the part that really matters to a novice like me.

One of the important things to remember, is that variables within the class must be explicitly initialized, either from within the constructors (by default or explicitly), or explicitly by you.

example: string foo("a string"); // the string, foo is explicitly initialized // by you through the constuctor. string *foo = new string("a string"); // same as above. string foo; // The default initialization will create the default // empty string for the string class.

When you design a class, you should make sure that all the variables in the class are initialized when the constructor is called. Otherwise, you could have some difficulties later.

However, from my observations, if I simply declare a variable of derived type, and never explicitly initialize that variable, the constructor of that class *is* invoked, and the member variables of that object *are* initialized. I'm trying to put together an example complex enough to demonstrate some of the issues which had me confused, and yet simple enough to present on this list. Part of that example involves the chaining of constructors. That is, the instantiation of objects within the constructor. This happens when I am writing GUI code. I want the main window to have 'children' which in turn may have children. I found I could do this if the children were referenced by pointers from the parent object, but not if the children were members of the parent objects. By looking over the QT example code, the Trolls typically use pointers in such cases. STH

On Monday 07 April 2003 11:38 am, Anders Johansson wrote:

On Monday 07 April 2003 09:34, Steven T. Hatton wrote:

...

The question remains. How big is an object? What does sizeof really mean?

An object is the size of its members. Plus all objects of a class share the methods of that class. Plus possible padding bytes (don't know about that one, but C sometimes does that for structs and unions, to align the data on word boundaries. I guess c++ does the same, but I don't know).

sizeof returns the size of the parameter. I think sizeof for an object returns the dynamic size of that instance. i.e. not counting the methods it shares with other objects of that class.

The reason I asked the question is that I'm not sure that every instance of a class will have the same size. If they don't, then how would the result of incrementing a pointer (ptr++ ) be calculated?

...

Also, what's the lifetime of a member variable of derived type when created as a side effect of implicit (automatic?) instantiation in a function call variable declaration?

If I understand the question, I would say from the time the function is called to the time the function returns.

The following code is kind of messy. It's intended to illustrate some of the pointer issuees I'm dealing with. Notice that I never explicitly instantiate tc.mc, neither in the constructor nor in any function. Nonetheless, I can call mc.output(), thereby demonstrating the constructor had been called. I intentionally omitted the initialization of int someNum to demonstrate that it is not automatically initialized. I do, however, initialize tc.mcPtr using: this->mcPtr = new MemberClass(this); That is, to demonstrate that I can use /this/ within a constructor. It also demonstrates the design issue I was mulling over when I started posting to the list. I'm not sure there is a way to accomplish a similar instantiation of a member. IOW, I'm not sure I can explicitly call a constructor and pass /this/ as an argument. I am sure that I don't know how to do so. There are five files represented in the following. testclass.h testclass.cpp memberclass.h memberclass.cpp main.cpp Two classes are defined, TestClass and MemberClass. /* testclass.h */ #ifndef TESTCLASS_H #define TESTCLASS_H #include <iostream> #include <string> #include "memberclass.h" using namespace std; class TestClass { public: TestClass(); ~TestClass(); void setOwnerMessage(char * ownerMessage="Owner Message"); void output(); void ownerOutput(); private: string message; string ownerMessage; int someNum; MemberClass mc; MemberClass * mcPtr; }; #endif /********************************/ /* testclass.cpp */ #include <iostream> #include <string> #include "testclass.h" #include "memberclass.h" using namespace std; TestClass::TestClass(){ this->message = "I am of TestClass. Assigned in the constructor"; this->ownerMessage = ""; this->mcPtr = new MemberClass(this); } TestClass::~TestClass(){ } void TestClass::setOwnerMessage(char * ownerMessage) { this->ownerMessage = ownerMessage; } void TestClass::output() { cout << this->message << endl; cout << "TestClass.someNum=" << this->someNum << endl; this->mc.output(); this->mcPtr->output(); } void TestClass::ownerOutput() { cout << "Owner Message=" << this->ownerMessage << endl; } /*******************************/ /* memberclass.h */ #ifndef MEMBERCLASS_H #define MEMBERCLASS_H #include <iostream> #include <string> using namespace std; class TestClass; class MemberClass { public: MemberClass(TestClass * owner = 0); ~MemberClass(); void output(); private: string message; TestClass * owner; }; #endif /********************************/ /* memberclass.cpp */ #include <iostream> #include <string> #include "memberclass.h" #include "testclass.h" using namespace std; MemberClass::MemberClass(TestClass * owner){ this->message = "I am of MemberClass. Assigned in the constructor"; this->owner = owner; } MemberClass::~MemberClass(){ } void MemberClass::output(){ cout << this->message << endl; if(this->owner) { this->owner->setOwnerMessage("I am the owner of a MemberClass"); this->owner->ownerOutput(); } } /***********************************/ /* main.cpp */ #ifdef HAVE_CONFIG_H #include #endif #include <iostream> #include <cstdlib> #include "testclass.h" using namespace std; int main(int argc, char *argv[]) { TestClass tc; tc.output(); return EXIT_SUCCESS; } I don't mean to offend anybody by posing lyrics here, but these seemed apropos to the subject at hand. Watching Me Watching You -- Jethro Tull I sit by the cutting on the Beaconsfield line He's watching me watching the trains go by And they move so fast - Boy, they really fly He's still watching me watching you watching the trains go by And the way he stares - feel like locking my door And pulling my phone from the wall His eyes, like lights from a laser, burn Making my hair stand - making the goose-bumps crawl He's watching me watching you watching him watching me I'm watching you watching him watching me watching Stares At the cocktail party with a Bucks fizz in my hand I feel him watching me watching the girls go by And they move so smooth without even trying He's still watching me watching you watching the trains go by And the crowd thins and he moves up close but he doesn't speak I have to look the other way But curiosity gets the better part of me and I peek Got two drinks in his hand - see his lips move - What the Hell's he trying to say.

On Tuesday 08 April 2003 12:45, Steven T. Hatton wrote:

But, IIRC, one of my professors (the Italian guy who always held his coke as if it were a cocktail glass, and his chalk as if it were a cigarette) told us that RISC compilers will likely forego the assembly language step and directly produce binary instructions.

Discounting macro assemblers, there is a one-to-one correspondence between assembly instructions and binary instructions. The former is just a human readable version of the latter.

Again, my recollection of how the stack works is a bit hazy. What you say makes sense for objects on the heap, but at some point, the instructions need to be placed in the CPU. Either the image of a function invocation goes on the stack as a whole, or it consists of an entry address into the shared program image, and a return address to be loaded in the instruction pointer register when the function completes. Typically we wouldn't have hundreds of images of a function on the stack. Such a situation would only occur in some kind of recursive invocation where a function calls itself and therefore causes another instance of itself to be loaded on the stack.

As far as I know, there are only two times when there is executable code on the stack. One is when you've been cracked. and the cracker uses a buffer overflow to insert the code, and the other is something called trampolines. which you can read about here http://gcc.gnu.org/onlinedocs/gccint/Trampolines.html Generally speaking, the areas of memory used to store data don't store executable code. On some hardware platforms that can be enforced. On the sparc, for example, you can tag a memory area as 'data', and it will trigger an error if the program then tries to go there in its execution.

...

QButton* button1 = new QButton( "Quit" );

There's something I'm not getting here. button1 is a variable being assigned in the constructor. It is not destroyed when the constructor returns. Why should

The variable button1 is destroyed when the constructor exits. The object it refers to is not. Normally in QT, you use the variables like button1 to set other variables, using methods like setMainWidget(). Those methods assign the objects to internal variables in the containers, so when the temporary variable button1 dies (when the constructor exits), they're not forgotten. Anders

...

At *compile time* the compiler will look at your class definition and say "that requires <n> bytes to store one object".

I have some uncertainty here. What you say makes sense, and I really believe this is what happens. However, what about objects such as strings? The compiler cannot know a priori what data will be stored in a string. This suggest to me the data of a string is not 'part' of the object. It is data pointed to by a member of the object.

Spot on. The object will keep track of the memory it allocates, and will tidy up after itself when it's destroyed.

pointer register when the function completes. Typically we wouldn't have hundreds of images of a function on the stack. Such a situation would only occur in some kind of recursive invocation where a function calls itself and therefore causes another instance of itself to be loaded on the stack.

A method call isn't a particularly clever thing. There's a bit of code somewhere in the program text segment which gets called just like any other function. The only difference between it and a bog standard C function is that the compiler generates it's code such that it takes one extra parameter on top of the ones the programmer writes: a pointer to the object it has to work with. This is the 'this' pointer which you can use (implicitly or explicitly) inside the code. Put another way, the compiler ensures that when it sees something like: ObjClass* myObj; myObj->aMethod( x, y, z ); it actually generates code for the call like: ObjClass::aMethod( myObj, x, y, z ); and the method definition is like: ObjClass::aMethod( ObjClass* this, int x, int y, int z ) { ... }

[I'm gonna back off form these implementation details for now.]

Oh. OK. Ignore the bit above!

never help me write code. I suspect, however, many of the people who simply pick up QT and start using the designer will reach a point where everything falls appart, and they don't know what to do to fix it.

Certainly no harm in understanding what's going on! Designer, though, isn't an IDE. It's just a GUI code generator which never takes any real control out of your hands. I guess there are environments where your point is valid though - I don't use them. -- "...our desktop is falling behind stability-wise and feature wise to KDE ...when I went to Mexico in December to the facility where we launched gnome, they had all switched to KDE3." - Miguel de Icaza, March 2003

On Tue, 8 Apr 2003 08:55:57 -0400 "Steven T. Hatton" wrote:

I don't recall the details of the lecture, but I do recall that in the example he used, there was not a one-to-one correspondence between assembly code, and the compiled binary executable. Since I cowrote the assembler no used on Tru64 Unix, I guess I can comment on this. Most modern assemblers have macros. But even those that are not macro assemblers, there are things that may not be entirely primitive. For instance (for the Alpha processor): stq $16, foo Store quad stored in integer register 16 to location foo. This will generate the code to convert foo to an address stored in a register. I havn't worked with Intel assemblers in a few years, so I cannot comment intelligently on that.

-- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On 8 Apr 2003 at 5:47, Steven T. Hatton wrote: From: "Steven T. Hatton" Organization: Global Symmetry To: suse-programming-e@suse.com Date sent: Tue, 8 Apr 2003 05:47:00 -0400 Subject: Re: [suse-programming-e] Pointer strangeness [snip...]

The reason I asked the question is that I'm not sure that every instance of a class will have the same size. If they don't, then how would the result of incrementing a pointer (ptr++ ) be calculated?

Each instance of a class -is- the same size, and the compiler handles the low level details of how to increment a pointer, unless you have a pointer to a void, in which case the increment op doesn't work. If you try to put data into your class definition which does not have a fixed size, the compiler will turn nasty and refuse to compile it :) As far as your other question goes, a class constructor is called in two cases: 1. When a variable of the class type is declared - ie: MyClass my_class1; // calls constructor with no parameters MyClass my_class2(params); // calls constructor with parameters 2. When a object of the class type is created with new - ie: MyClass *my_class_ptr1 = new MyClass; MyClass *my_class_ptr2 = new MyClass(params); The classes destructor is called in the following circumstances: 1. When a variable of the class type goes out of scope - which usually means at the end of the block in which it was declared. For most automatic variables that would be when the function exits, but you could, for instance, declare a variable inside a loop, and that would go out of scope when the loop exits. For static variables this is when the program exits. Note that static variable are created before the program enters main(). You have no control over the order in which statics are constructed and destroyed, except that the standard guarantees that they will be destroyed in the reverse order to which they were constructed! 2. When objects are destroyed using delete. Note that if you created an array of objects eg: MyClass *my_class_ptr = new MyClass[MAX_MYCLASS]; then you must destroy the array with delete [] eg: delete [] my_class_ptr; The purpose of constructors is so that you can write initialisation code for your classes and be sure that it will automatically be called when you create an object of that class. Destructors perform guaranteed clean up when you destroy an object. [lotsa stuff snipped here...] Hope this helps alan -- http://www.ibgames.net/alan Registered Linux user #6822 http://counter.li.org Winding Down - Weekly Tech Newsletter - subscribe at http://www.ibgames.net/alan/winding/mailing.html