Recently, I found that the file management program written in the past is excessively expensive when processing a large quantity file, and the performance is very unstable (suddenly, the estimated and garbage collection mechanism " related). After considering the factors of the program itself, I feel that there is not much optimization, so I can do the key parts of the file processing with C to solve the above problems.
From the above, the goal of its own is as follows:
1, the interface part retains the C # code;
2, the file processing process is rewritten with the C routine and the Windows API;
3. Provide a managed interface for the file processing process to call C #.
Since I have learned the content of Managed C , the beginning of the beginning is very smooth: create a .NET class library, adding a code to the inside.
However, when the program is written to the middle, the various strange problems began to emerge. Some are relatively simple, the compiler tells me that MessageBoxa is wrong, this is the macro in the chaos, but how to solve it? Never I don't want Windows.h? Later, I found the answer with Google Dafa, Microsoft said that #undef messagebox. Sigh! How wonderful solution, I start to understand why C is a second-run language in .NET.
But the most critical problem is that the C run library does not seem to coexist with the management code, otherwise it is easy to see a lot of link failure information. At first, my solution is not to use any C functions, you don't let me new and delete, I assign the memory head in Heapalloc? But later, it is not feasible, because the slightly complex program is still unable to avoid calling C . The roller turned and finally found this article:
Convert C hosted extension project to mix mode from pure intermediate language
http://www.vckbase.com/document/viewdoc/?id=1403
Hey, I have to say that this kind of solution is not elegant in the future, but it is really feasible. Ok, don't worry about it, the way in use can make the program work.
Now, this overwritten program can run normally, and whether it is memory space or operational efficiency, it is indeed much better than it. However, after this setback, I have more new ideas for the hosted program. For .NET, I now I have the most appreciation of it or: In terms of componentization and code reuse, .NET makes these work more convenient, and it is not easier to make an error. But .NET huge resource consumption still can't love it, with a general applet, use MFC to write 2 ~ 5m memory, if the WTL is used, only half of the MFC, but use. If NET is written, the program takes up more than 10 megabytes of space and is more running. Of course, if you look at it, 10 more don't count, but if I want to run multiple large programs at the same time? Microsoft's Longhorn's hardware requires high scary, I think mostly because M $ insists that Longhorn turned to the management environment, otherwise, if you go to Winfs's long-range, there is not much revolutionary thing, and it is really not becoming it. Hardware killer.
Alternative is about hosting C topics. Host C in the world of .NET is a veritable second-class citizen. I have a deep feeling. In the online information about MC, it is simply nine bull, and it is quite better than VB.NET compared to VB.NET. The programmer who used MC seems to have no use of it. It is easy to use (as seen and listened). The MC's grammar is really ugly, but I am not very concerned about it, as long as it works - but I don't want to be tangled often and no salt, so I usually use MC to interface this level, internal implementation try to use pure C . Just this experience can prove that the management code and non-management code are not a relaxed thing, and some compromises must be made in some places. In a sense, this is actually very exercised, but there is no creative work or less than good, the programmer spends the energy in these trivial places and is not worth it. After this toss, I can also understand why Stan Lipman is designed to design the C / CLI, and the introduction of new keywords; C classes and .NET classes are all classes, conceptually the same, but there is such a realization There are many details so that they are not appropriate to comply with the same syntax. I am looking forward to hosting C to have a relatively complete solution in the CLI, but now you see the information you see, let the managed code and the non-hosting code work in the same module or more detailed details. This world is always not perfect - I can say it now.
