Archived

This topic is now archived and is closed to further replies.

MFC pointer question

This topic is 5887 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

i have four classes, the app object, framewnd object, a treeview object, and a listview object, and i need my two view objects to communicate with eachother. so what i did was put CWnd pointer member variables in each of them, and then set them to the other view. so that way one view can call the public members of the other view. this works fine, but i was wondering, since windows moves memory around so much, would there maybe be a problem here? i mean, isnt that the point of using handles instead of pointers? does the framework take this into consideration, and a CWnd pointer is really more like a handle? should i worry about this? is there a better way for them to communicate? i am not using doc/view, because the program doesnt need a document at all. any help would be appreciated. thanks

Share this post


Link to post
Share on other sites
quote:

since windows moves memory around so much, would there maybe be a problem here?


A pointer, even to a CWnd, is just 4 bytes on a 32-bit machine.

quote:

i mean, isnt that the point of using handles instead of pointers?


Nope. A handle is a pointer (void *). The purpose of handles was to try to put some type safety into C by faking the compiler into thinking these handle things were actually different than pointers. They''re not.

quote:

does the framework take this into consideration, and a CWnd pointer is really more like a handle?


The CWnd pointer has a handle: m_hWnd.

quote:

should i worry about this?


That''s a deeply philosophical question. Sharing the handles between two view objects will not cause any memory copies or anything like that, so if that''s all you''re worried about: don''t worry.

quote:

is there a better way for them to communicate?


Yup. Using the doc/view architecture, each view is completely oblivious to all other views, and the document itself knows nothing about which views are attached. You currently have a circular dependency, meaning that each time you change one view class (at least the public interface), the other must recompile.

In proper doc/view architecture, each view has a pointer to the document, so there''s a dependency of each view on the document. However, when each view is created it registers itself in a list that the document keeps (this is all framework stuff here) as CView*, regardless of what kind of view you have. Therefore, the document is completely insulated from your specialized views (i.e. classes derived from CView).

Communication from the views to the document occurs through the public interface of the document. Communication from the document to the views occurs through hint objects using UpdateAllViews. The views are not allowed to talk to each other; instead, a view would call a public function of the document, which would then UpdateAllViews reflecting that information. This means that the document can have views added and removed without having to recompile it at all. It''s really rather neat, once you get the hang of it.

quote:

i am not using doc/view, because the program doesnt need a document at all.


Bummer.

Share this post


Link to post
Share on other sites
thanks for the reply. i know that a handle is really a pointer, but isnt it a pointer to a pointer? i read in the programming windows book by petzold that handles are used so windows can change the address that the handle points to so it can move around memory in the system without your program having to even care about that. i dont know, but thanks for pointing out about the hwnd inside the cwnd class, i looked and found all the functions to get at it and how to get a cwnd pointer from it. thanks.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You should read one of Petzold''s newer books. That was probably for the Win16 architecture, in which the memory management was pretty sucky. Windows had to be able to move stuff around in the logical memory space. Nowadays the moving of memory happens at a much lower level (paging) and is completely transparent to the application, so it''s nothing you need worry about.

Share this post


Link to post
Share on other sites