With ACE, there is also a 1 year. From the beginning of the ACE, the active learning ACE is boldly introduced into the project, and now I am a complex mood, I really don't spit.
I am developing under Windows, because the project is involved in many interface operations, the basic class library of MFC is still used. Perhaps ACE is born with MFC, and I have encountered problems at the beginning - memory leakage! For this problem, I was on the ACE website, and the two ACE discussion groups of Yahoo were carefully searching at the Xiaofei Forum at the time, and some people did not find the same problem. So I put this question to 9CBS. Soon, I got the result - how to solve this problem, but many people doubt about this problem itself - Many people think that ACE is the test of industrial strength, it is impossible to have memory leaks, even Yes, it should be my own problem, not the problem of ACE. Some friends have put forward some feasible recommendations, but there is no one that can really solve the problems I have encountered. I don't know that there are several projects listed on the ACE website, there are several projects that are mixed with ACE and MFC. Anyway, I have never solved this problem. However, because the leakage caused, the leak is quite slight, so this problem has only been temporarily restoed.
As the project is, the more you need to maintain, more and more, I have to start considering the problem of module division. In fact, from the beginning, I have fully considered modular problems. DLL I didn't plan to adopt (I don't want to fall into the DLL Hell), from the Windows platform, except for .NET, the best way to modularize large engineering, should be considered COM component technology. However, in view of the level of the overall development team's mastery of COM technology, and the complexity of COM technology itself and certain defects, I also gave up the idea of introducing COM technology in the initial stage of the project. So we use simple Namespace to divide the source code. This directly leads to the post-compilation speed giant slow and the source code difficult to maintain and control. In order to solve this problem, I started to try to start from the key module and build the corresponding COM component by the core team. From the entire project, the core thing is the network layer. It seems that the code to encapsulate the entire network layer into a COM component, it seems not to be so difficult. So we started confident that the code transplantation work, but soon, we encountered a difficult obstacle. For some considerations, from the beginning, all the code written in the network layer, there is no MFC, but written in standard C , which also provides us with code transplantation work: we can put these The code is completely separated from the MFC, we can write COM components using ATL, which may solve the match between ACE and MFC! But unfortunately, we did not expect cooperation between ACE and ATL, there is still a problem! When using ACE_TP_REACTOR or ACE_SELECT_RACTOR, the written COM component will definitely report, and it is difficult to locate it! Ironically, there will be this problem in the COM components prepared by MFC technology! Perhaps we can endure a little memory leak brought by "small friction" between ACE and MFC, but the facts prove how naive of our next idea! In the COM component written in MFC technology, when using the ACE_TASK framework, it will also encounter an incorrect that is difficult to position! Then we tried the COM components written in standard C , and also encountered a variety of questions. At this point, we use ACE as a network layer code written as the underlying infrastructure to the COM component attempt to fail. In fact, during this period, it was curious about the underlying mechanism of the ACE. He also looked at POSAII. I feel that many of the components inside the ACE do design precision, and many places reflect superb design ideas. However, from the perspective of real-world applications, ACE is too large, and there is no clear and meticulous classification. The corresponding support documents are too thin. It is likely to encounter a lot of difficult problems in practical engineering applications. Perhaps, in the next project, I should resist the temptation of all the commitments made by ACE, and choose ACE is no longer used as a network infrastructure component.
