6th Dec 2004


9th Dec 2004

  • In a pre-emptive multitasking environment, it is possible for some other thread to change the access of the process to memory being tested. Even when the function indicates that the process has write access to the specified memory, you should use structured exception handling when attempting to access the memory. Use of structured exception handling enables the system to notify the process if an access violation exception occurs, giving the process an opportunity to handle the exception. – From “Embedded Visual C++” help file

  • Get more familiar and confident with use of __try, __except structure.


10th Dec 2004



13th Dec 2004

  • A good debugging and testing environment is required, especially for unit and functional test for each module.


16th Dec 2004

  • De facto, the ways of work are different from the way study. I got this point after reading some colleagues’ code and Microsoft’s sample code. They have different aims.



21st Dec 2004

  • (Ta shan zhi shi ke yi gong yu) find ways to use all resources, including others’ work (if allowed), references, and so on.


24th Dec 2004

  • I took so many days for debugging; I found that utilizing serial debugging tools and methods is quite important and effective.

  • It needs to pay much more for not well organized and understood design during debugging and testing.

  • It is a good idea to put all the include file (header file) into one directory – always helpful for remote development and portable reuse.

  • It is near Christmas and New Year, a small gift is always a good idea during the “gifting” season for colleagues and friends.

  • A get-together dinner at the end of a year/a period is necessary.

  • What is less for a young project leader to manage a team?


28th Dec 2004

  • There are always some non-work-related stuffs during the work those I should take note.

  • First Rule of Compiler Errors:

The first listed compiler error is always a true error; however, later errors may not be true errors.

  • Second Rule of Complier Errors

A compiler error may be caused by any source code line above the line referred to by the compiler; however, it can not be caused by a line below.



  • The Seven Principles: The 'bug' is your prey. You must learn its habits by careful observation, then hunt it down and capture it.

  • Choose your battleground. Define and control your own test and debug setting.

  • Discard everything that is unnecessary. Simplify the system under test.

  • Commit yourself to solving the problem. "No" is not the right answer. Leaving bugs in a product should be unthinkable for an engineer. Only management and marketing should make decisions to release products with known bugs.

  • Relax and abandon yourself. Let go of all preferences. Your attachments to specific design implementations will hinder your progress.

  • When all looks hopeless...take a coffee break. Take a break and let go of your personal interests. Turning your mind off for awhile will renew your energy.

  • Compress time. Let your mind work outside of time. Discover ways to shorten the time between failures by modifying the test software or other system parameters.

  • Never push yourself to the front. Don't jump to conclusions and then publicize them.



  • The Three Personal Attributes: The success of the debug process lies with you. Your temperament and impeccability is all that stands between you and the task. These three personal attributes are the most important factors that you have direct and complete control over within yourself.

  • Never take yourself seriously. Taking yourself seriously is the surest way to be misled. Your own ego will lead you to assumptions such as: "It can't be my fault so I'll look elsewhere." or "I know this must be the problem so there is no need to verify it." Have no points to defend. This will make you flexible and open-minded.

  • Have endless patience. Loosing your patience and often your temper cloud the sobriety you need to tackle the problem. Occasionally you will fall upon the problem quickly without effort but you should always be prepared to go about the methodical and sometimes time consuming way. Quitting, taking short cuts, or making unwarranted assumptions are the most common consequences of impatience.

  • Have an endless capacity to improvise. This maneuver is one of the most important. You are setting a trap for the bug. If it eludes your trap you must improvise another cleverer one. Very often you will be required to set these traps with inadequate tools. Do not, however, allow your improvisation to become the project! ” – “Mastering the Art of Test & Debug”



30th Dec 2004

  • From the memory’s point of view, the sealed access (which is one of the main features of OOP Concept) just the right next-step.

3rd Jan 2005

  • Recently, I felt not so excited about work maybe because of the past many holidays.

  • New year, new beginning; best wishes with best plans.

  • Write real-time development log for analysis and daily remark for concentration .

  • Try to remember content with good catalog while reading.

  • I think most developers have the experience of sudden realization.

4th Jan 2005

  • Pay attention to the reasons cause bugs!

6th January

  • The progress goes much slower when there are some misunderstanding during programming.

7th January

  • After entering professional area, there are much more opportunities for my future, and absolutely open for my personal plan. Be careful about my planning.

  • I feel I've got bottle neck for my work, -- this should be serious for me.

  • Apply scientific attitude as a principle of my life: (zhun que), experimental, critical, sensitive,

10th January

  • If a temporary object is passed to a function that takes a reference to an object as a parameter, that reference must be a const reference.

11th January

  • Give each piece of information a unified sequence number in the log file, such as yy_mm_dd_sn.

14th January

  • Move from variable views to structure views.