Sweat
Conserver: Xioax Recipient: Hou Jie Chuan Date: January 22, 2002 AM 09:36 Total: About MfClite's problems! Teacher: Hello, I am a student who has just graduated from Zhejiang University and is also your faithful readers. Recently I read your MFClite and discover some questions, listed below (if there is something wrong, please give pointers):
1, object persistence. Due to two years ago, I have carefully studied Turbo Vision's persistence and is more familiar with this issue. So I found out that there was a problem existing in your code. Here is my test program (partial), and the content of the output file: ... csquare * psqr1 = new csquare (); csquare * psqr2 = Psqr1; // psqr1 and psqr2 points == psqr2; {? cfile write ("test.tmp", cfile :: modewrite;? carchive store (& write, carchive :: store);?
void CMultiDocTemplate :: RemoveDocument (CDocument * pDoc) {CDocTemplate :: RemoveDocument (pDoc); // m_docList.RemoveAt (m_docList.Find (pDoc)); // remove the node doc <- there are problems crash.!} 3 ﹑ CDocument :: OnOpenDocument and CDocument :: OnSaveDocument a memory leak:? BOOL CDocument :: OnOpenDocument (const string & strFileName) {CFile * pFile = new CFile (strFileName.c_str (), CFile :: modeRead) ;? CArchive loadArchive (pFile, CARCHIVE :: Load) ;? serialize (loading);? Loadingarchive.close () ;? pfile-> close () ;? // shop delete pfile? Delete pfile; ion true;} Bool CDocument :: OnSaveDocument (Const String & strFileName) {? CFile * pFile = new CFile (strFileName.c_str (), CFile :: modeWrite) ;? CArchive saveArchive (pFile, CArchive :: store) ;? Serialize (saveArchive) ;? saveArchive.Close () ;? pFile -> close () ;? // SHOULD DELETE PFILE? DELETE PFILE;? Return true;} 4, I found that the destructor of COBJECT is not virtual. I think it must be a teacher's negligence. :-) In the face of a few thousand lines of code, who dares to ensure that it is right? !
5, MFClite's new file, open file, and save file simulation; but the closing window, thereby causing the destruction of documents to simulate not enough. In fact, in C , the memory leakage caused by the desctors is often the most common, and it is also the most difficult to exclude bug. I hope to see the corresponding simulation in the new version of MFCLite!
Although MfClite has some shortcomings, I don't hide jade, I think it has a very great help to C and MFC. Every book of the teacher (whether it is translated or a book) is a boutique in the relevant field. All I have bought it in the market, giving me a great help. Now I am eager to wait for the teacher's "STL original code analysis", "generic design and STL", "standard C program library" and other books. I hope that the teacher will pay attention to the body and write better work!
Hi, Xioax, Hello: The following answers some questions and suggestions. > 1, object persistence. Due to two years ago, I have carefully studied Turbo Vision's persistence and is more familiar with this issue. So I found out the problem existed in your code. Here is my test program (partial), and the content of the output file: ...> I think the most important issue is for C objects. : One is how to save related class information, and the other is how to solve the above problem! In your two books "Polymorphic and Virtual", "in-depth light-out MFC" have very incisive discussion, only the latter is not mentioned, can not be said to be a big flaw. It is not very difficult to solve this problem, just implement CMAppTrtoptr and CPTRARRAY, first check MAP when writing, if you have written, write the output serial number, if you don't add the address and output serial number of the object, then Write the data into the file. When reading, encounter a second case, first create an object to read the data, then add the address of the new object to the end of the array, encounter the first case, the output serial number is directly from arrays The object is obtained (as in the order of writing and reading, only the output serial number can be completely solved). ● Houjie replied: What you pointed, it is a head of it. Indeed, I rarely consider what you said (Alias) when simulating Persistence. For your proposal, I have corrected MfClite3 and is open on this page. The MFC (Lite) not only considers the "Alias) situation, but also optimizes the document reading and writing of the document of" affiliates "different Objects. For Class INFORMATION (such as Class Name, and Schema NO), it is a waste of waste-waste space. Therefore, MFC's CARCHIVE uses CMAppTrtoptr as cache, not only used to place COBJECT *, but also used to place cruntimeclass *. When reading the file, the truth is the same, using CPTRARRAY, not only the COBJECT * is also placed in cruntimeclass *. I don't plan to add CMAppTRToptr and CPTRARRAY in MfClite (that I am afraid that there will be more than 1000 lines of code, and CMAppTrtoptr is completed with Hash Table, so that the threshold of reading is higher), I am already in the new version In MfClite 3.0, the MAP and Vector of the C standard program library are replaced.
The bigger reading threshold of MfClite is more and more high, and people who have deep skills can be difficult to readers who are still shallow. For me, I have become a difficult thing.
I retain and expand your test, put in the cmywinapp :: InitInstance () of MfClite Application (mfclapp.cpp). A program execution will display this test results on the screen and display Storemap and • LoadArray, and then begin generally normal execution processes. Your Hint from Persistence gives me a fun, forcing me to complete the "deep-in-depth MFC" Chapter 8 about Tags in Document Format (Figure 8-10A, Figure 8-10B) FFFF, 8001, 8003 ... There is a deep experience of Tags such as 0002, 0005 ...) of the figure.
> 2, cptrlist's implementation has memory leaks, below is the relevant code and my modification (red): ... ● Houjie replied: Modified. I didn't use your way, but used MFC's way. When the MFClite was actually, I wanted to simplify some things, I didn't want to cause Memory Leak without conscious. Conduct. My forehead began to sweat. > I think it is not necessary to implement some advanced memory management skills as much as MFC is exactly the purpose of MFC. Because one of these memory management is completely related to the MFC application architecture, two to increase readers' reading difficulties, three to increase MFCLite's error chance. If cptrlist uses Coblist's implementation method, there is not so much problem! ● Houjie replied: Cptrlist's exquisite design, very independent with Application Framework. Although it is more complicated, it should not be confusing readers to learn about Application Framework. Keep such a complex list, two intentions, (1) CPtrlist is a large amount of Data Structure, which is used in internal self-maintenance management, so it is very independent of efficiency (space and time). , More complexity is not to confuse readers to learn about Application Framework, then show this nice design, full. > In addition, you said in the code below, deleting element programs in cptrlist crash, I don't know if it is the reason? ● Houjie reply: not. The reason is already found, because I put all the Documents' delete action to the wrong position. These actions should be triggered by cframewnd :: onClose () among the MFC (current MFClite has not been placed), but I put them in CMULTIDOCTEMPLATE :: ~ cmultidoCtemplate (). The following is a MFCLite CallStack: CMultiDocTemplate :: RemoveDocument () // (B) CDocument :: ~ CDocument () CMultiDocTemplate :: ~ CMultiDocTemplate () // (A) CDocManager :: ~ CDocManager () CWinApp :: ~ CWinApp () (A) has been called M_Doclist.removeat (), and (b) is also for PDOC call m_doclist.removeat (), but PDOC is not in m_doclist, Find () is back null, removeat (null) of course hangs . The treatment of the cure is analog MFC. Developing Window Close System (that is, your fifth question), the way to govern the standard is in cptrlist :: removeat (), determine whether the delete position is null, if it returns immediately. > 3, cdocument :: onopendocument and cdocument :: onsavedocument have memory leaks: ● Houjie reply: It should be said to be resource leak. It has all been completed. I started sweating on my body. Try the safety test work in CFILE :: ~ cfile () and cfile :: close () while patching this problem. > 4, I found that the destructive function of COBJECT is not virtual. I think it must be a teacher's negligence. :-) In the face of a few thousand lines of code, who dares to ensure that it is right? ! ● Houjie reply: all complement. I am sweating. > 5, MfClite's simulation of new files, open files, and save files; but to close the window, thereby causing the destruction of documents to simulate enough.
In fact, in C , the memory leakage caused by the desctors is often the most common, and it is also the most difficult to exclude bug. I hope to see the corresponding simulation in the new version of MFCLite! ● Houjie replied: Under the rain. For the questions you mention, I originally simulated some, and I feel a little annoying, I will put it down within the spindle of my most concerned. For your proposal, I may be implemented in MFCLite 3.0, or it may describe these issues in the book, and leave the reader to implement. > Although there is some shortcomings in MfClite, I don't hide jade, I think it has a very great help of C and MFC. Every book of the teacher (whether it is translated or a book) is a boutique in the relevant field. All I have bought it in the market, giving me a great help. Now I am eager to wait for the teacher's "STL original code analysis", "generic design and STL", "standard C program library" and other books. I hope that the teacher will pay attention to the body and write better work! ● Houjie replied: You are very good, basic work is very good. Zhejiang University Electronic Engineering Department is really a look at me. "STL source profile" and "C standard program" simplified version of you give you a book, express me, thank you, and the expectations of you. "The generic program design and STL" Houjie translation only, together with the "C Primer 3E" Hou Giejie transcript (only the traditional version) recently sent to you. Please tell me your mailing address. I can only send the sea (about 25 days of time), the air is too expensive :) ?? You have a very good code tracking ability, like a hound of nose :). I think you certainly track the MFC source code with your heart. Appreciate the famous manner, it is an important manner that pulls himself to the high point, and the master is impeded. After I left the first line of programming, I took this way and pioneered myself. I am very curious about you, a young man who has just graduated. (How do you know your first solution? Do you read the MFC source code? Is it true? Thank you for giving me such a rich message. MfClite is very complicated and can understand that it also points out the problem, cut the principle, and even propose solution, it is not easy. There is currently no reader to give me a message about MFCLite. I heard that the computer level of Zhejiang University is very high, from your letter to some prove :)
