Importance of document Description

Use the following two examples to illustrate the importance of the official documentation instructions. One is the instructions given on MSDN, and one is the official description given by the GDIView GDI leak detection tool. With these official instructions as clues, we can find out where our program is going wrong and solve the problem.

1 , chat server time local time zone and summer season problem

(1) TL Chat time using server time, TL the underlying XMPP client needs to synchronize with the server time, and then get the server time, for the time stamp of chat information. The server passes over the utc+0 time, which is the string format of the month-day time, not the integer time. The XMPP client uses the time difference bias, mktime, and localtime to convert the string to a utc+0 integer, and when the message is sent, the integer time is converted to a string of date and time, sent to the peer. When a message is received by the receiving side, the string is converted into an integer time, which is populated in the message structure for use by the upper layer.

(2) When a response to a server time request is received, the received string is converted into an integer time, as follows:

It was later confirmed that the conversion process took more than 1 hours. The test environment at that time was: the sending side set the time zone of UTC+10 with the summer season, as follows:

Send side: Send the end of the message, received the terminal layer of the message sent in the RSP,RSP to carry the server time, the display box is the return of the server time, more than the local time of one hours,

Receive end: The receiving end receives the message, the message carries the time that sends the server, the receiving side translates the local time also to have one hours, according to the receiving end receives the message also uses the mktime, should be more two hours only then? Haha, the receiver was set at the time of the utc+8 Beijing time zone, there is no summer adjustment, so the receiving end only more than one hours.

(3) When sending a message, the utc+0 string is constructed to date and time, as follows:

When the receiving side receives the message, the utc+0 string is converted to an integer time, as follows:

(4) to locate the problem, see the implementation of the Mktime function:

So how does Dstbias get here in real time? Because the user may change the time zone halfway, involving the summer season, Dstbias is not the default-3600, the relevant code is as follows:

The above code shows that the __tzset internal call gettimezoneinfomation, real-time calculation of the value of Dstbias, but after the program starts, then change the time zone, is not real-time update dstbias equivalent, That is, only the first call to Mktime after the start of the call gettimezoneinfomation, real-time get dstbias equivalent.

(5) The description of the struct TM is found in the Asctime function description, as follows:

(6) more than one hours to locate the problem:

After debugging found, after setting the time zone below, Dstbias is-3600, exactly one hours

The problem with the following code is the memset problem:

That is, TTIME.TM_ISDST is 0, can not enter the above branch, the extra one hours did not lose, so more than one hours.

(7) The description of the Tm_isdst field in VS2008 MSDN is not very clear, as follows:

However, the MSDN on the latest Web page is very clear, as follows: ( so again, When you encounter a problem that is unclear or not understood on VS2008MSDN, you might want to go to MSDN Check out the latest notes on the website, maybe we need help. ）

By looking at the internal implementation of the Mktime, the _localtime64_s and _gmtime64_s functions are called, both of which have the initialization of the struct TM structure initialized with 0xFF,

The TM_ISDST of the TM structure is set to 0xFF, that is, less than 0, it is determined whether the summer season time is dstbias by the runtime library, so the time processing on the XMPP side is no problem. For the CTime class, there is also reference to the constructor of the time parameter passed in the month and day, as follows, whether the final consideration of summer season is also the negative value of the pass:

(8) Description of the time-processing functions mktime, localtime, gmtime functions, and CTime classes:
Mktime: Converts the TM structure time into an integer time, minus the bias absolute value of the utc+0.

LocalTime: Converts an integer time into a TM structure time, and adds the bias absolute value to the utc+0.

Gmtime: Convert integer time to TM structure time, not to deal with jet lag;

CTime class:

The integer value passed in is an integral time of utc+0.

The code in (7) learns that if the time of month and day of the incoming local time zone is passed mktime, it is converted to utc+0 integer time.

CTime multiple methods are mktime, localtime encapsulation, reference to the conversion of these functions.

2 , the problem of GDI resource leaking

( 1 ) After opening some windows in the new TL, the number of GDI handles increases by 6 each time, that is, there is a GDI resource leak. It is strange that GDI-related resources will be destroyed when the opened window is destroyed. Since some of the windows have not leaked after opening the closed, compared, temporarily consider the Directui Library no leakage problem. with gdiview observation, theGDI Total column does not grow, andallGDI columns grow every time. This is more strange, generally our resource leakage is mainly pen, bitmap, and so on, the results of these regular GDI objects are not leaking, feeling can not be looked up.

(2) so try to GDIView on the official website to see, the results found the corresponding instructions, as follows:

Official website:http://www.nirsoft.net/utils/gdi_handles.html

As noted above, there is no growth in GDI Total column, all GDI column growth may be caused by the icon resource or the cursor resource is not released after creation. so I thought, some of the windows are closed after the GDI handle rise, think carefully, these windows do not have a taskbar window, do not set the icon.

(3) then find the code to set the icon, as follows:

This function only uses the LoadImage, on MSDN to view the description of LoadImage, found that there may be an icon resource leakage, as follows:

that is, if you do not set the lr_shared tag when using LoadImage, you will need to destroy these resources manually, otherwise it can cause a leak . The lr_shared tag is added and the modified code is as follows:

Finally, with GDIView view, there is no GDI resource leaks.

Importance of document Description