How to Write elegant code (5)-different class usage

// ================================================ ====================================
// Title:
// How to Write elegant code (5) -- different class usage
// Author:
// Norains
// Date:
// Tuesday 20-0000l-2010
// Environment:
// Visual C + + 2005
// ================================================ ====================================

 

As a wedge in this article, I raised a question: how to calculate the actual number of calls of an API function when the program is running? Specifically, there is an API function getparent that everyone is familiar with. How do we count the number of times it is called in our code?

 

The simplest way is to declare a global variable, which is automatically added before each call. This method is indeed harmless when the number of function calls is relatively small. But if there are hundreds, are you planning to add an auto-increment statement before these hundreds? What's worse, if the statistics are only used during debugging and need to be removed during official release, what should I do? I guess no one will use the manual deletion method before compilation. It is estimated that everyone will think of macro definitions, such:
# Ifdef _ debug <br/> g_icount ++; <br/> # endif <br/> hwndparent = getparent (hwnd );

 

It seems that the problem has been solved, but in fact there are a lot of troubles introduced: How do we determine that we increase the number of times before each call? -- Especially for the code to be added in the future, the person to be added may be himself or a colleague. How can we ensure that we still remember this irrelevant auto-increment macro before the call?
　　
This is not the most troublesome thing. If we need more than one function to be counted, the above troubles will be doubled for every increase in statistics. I guess no one can accept this.
　　
In fact, the solution is very simple. Isn't c ++ a function overload? Can we just reload the getparent directly? Of course, there is also a small restriction, that is, the Code must be class-based. The method is very simple. We can declare a base class, reload getparent in this class, and the last class is derived from this class.
　　
Based on this idea, we declare a basic class:
　　Class cbasefunc <br/>{< br/> Public: <br/> cbasefunc () {}< br/> virtual ~ Cbasefunc () {}</P> <p> PRIVATE: <br/> static hwnd getparent (hwnd) <br/>{< br/> ++ ms_dwcount; <br/> return: getparent (hwnd); <br/>}</P> <p> PRIVATE: <br/> static DWORD ms_dwcount; <br/> }; </P> <p> DWORD cbasefunc: ms_dwcount = 0; </P> <p>

　　
All other classes inherit from this class:
Class cmonitor: <br/> Public cbasefunc <br/>{< br/> Public: <br/> cmonitor () {}; <br/> virtual ~ Cmonitor () {}; <br/> };
　　
It is so simple that we don't have to worry about adding macros, so we don't have to bother trimming the original code. We only need a base class, an API function call without the prefix.
　　
Statistics are just one of our applications. The benefits of overloading are not limited to this. We can do too much before calling an API function, as long as we don't have the imagination.
　　
For example, closehandle, an API function, we all know that if the same handle is closed repeatedly, it will cause overflow. If we can determine whether the handle has been closed before execution, then we can call closehandle. If we reload the function in the base class, this is not a big problem:
　　Class cbasefunc <br/>{< br/> Public: <br/> cbasefunc () {}< br/> virtual ~ Cbasefunc () {}< br/> <br/> PRIVATE: <br/> static bool closehandle (handle hobject) <br/>{< br/> // isclosebefore is a function defined by us to check the handle. <br/> If (isclosebefore (hobject) = false) <br/>{< br/> return: closehandle (hobject); <br/>}< br/> else <br/>{< br/> return false; <br/>}< br/>}; <br/>

　　
Some people may see this question: Can I directly declare a function with the same name as a parameter without using a class? The answer is no, because the compiler will complain.
　　
Function overloading brings us a lot of surprises in many cases. Many solutions can discard classes completely. However, using classes gives us more convenience. Why should we reject them?