不得不說，c/c++強大的功能和靈活的操縱性，一直是我的至愛。哲人說過，任何事物都有其矛盾的兩面性，此話誠不欺我也！c++，你把偉大的記憶體管理工作交給了我們，而我們卻經常用不好你。
關於物件記憶體管理，最常見的問題就是：
1. 記憶體訪問衝突，具體表現就是程式執行時，突然跳出乙個警示框「0xfa012345……該記憶體不能為read。」確定，程式崩潰。
2. 記憶體洩漏，這個一般很少表現出來，因為現在的機器越來越強悍了。但一旦記憶體不足了，問題會很嚴重，梨叔會很生氣。
引起記憶體訪問衝突的**有以下幾類：
1. 記憶體越界訪問，如乙個陣列過界操作
2. 物件指標沒有正確指向到有效物件，仍訪問其成員（讀寫成員變數、呼叫成員函式、delete物件本身）。具體情況有：
a. 物件指標為null時，仍然訪問其成員
b. 物件指標沒正確指定物件時，仍然訪問其成員。如未初始化，造成隨機指向到系統記憶體；或者物件已經析構過，但沒有通知到該指標。
引起記憶體洩漏，最根本原因就是記憶體有分配（new）沒釋放（delete）。
我最常患的乙個錯誤就是，為了防止記憶體洩漏，經常過多地使用了delete操作符，結果又造成記憶體訪問衝突，因為物件delete後再delete了。當然，第一次delete操作是在其它模組中，我甚至無法**它是在什麼時候被delete的。
系統（程式）稍微複雜一些，就得用各種容器儲存物件（通常是指標或引用），而這些物件一般是共享的，而且建立物件的方式多樣性和位置不確定性，造成了上面提到的物件記憶體管理最常出現的兩個問題。
對於這些「低階」問題，前輩們早就有了應對之道，那就是智慧型指標和引用計數。這些特性，高手們甚至準備把它寫到c++的新標準中。
我卻一直沒有勇氣用它。因為我怕使用智慧型指標和引用計數會大大降低程式的效能，畢竟要多訪問一重嘛。但這仍然是藉口，最根本的原因是，本人懶，懶到懶得用它，想想，**中每一次getobject()後，都要pobj->release()，我有點受不了。還有乙個藉口就是，怕這些高階特性不能被專案組中每一位成員理解，利器用得不當，反而是害了自己。
沒有使用智慧型指標和引用計數，為了避免記憶體管理可能引發的問題和混亂，我只能在類的介面函式中，以注釋和文件的形式註明，傳入或傳出的物件（指標），是由外部客戶**管理其生存期（主要是建立和銷毀），還是由本類自己管理，外部勿需多管閒事。以後，不管是實現介面的具體類，還是使用服務的客戶類，都必須嚴格按照這個約定來行事。
但這種物件記憶體管理的宣告，其作用還是有限的，只不過把它明文化了罷。
尋求更完美的解決方案……
專案管理經驗談
專案攻關時準備工作 1 了解客戶受訪物件的性別，有針對性的安排聲音有吸引力的異性通過 做一些推敲性調查 需扮演第三方的角色 重點要了解客戶的背景，組織結構及目前的業務狀態。需引用專案的真正需求。調查不足時，輔以上網查詢補充。2 根據前期調查資料，針對客戶的情況和需求，做出乙份簡單 突出特點的解決方案...
網路管理經驗談 Novell網維護經驗談
現象1 伺服器啟動正常而有些工作站不能上網。原因 這種情況大多數是網線接頭接觸不良造成的。解決方法 如果是t型頭可用一根極細的微型小銼插入接頭孔內輕輕銼一下或者用一根針尖略彎的醫用鋼針刮一下即可，或者乾脆換個新的 如是rj 45頭，大多數情況是網絡卡上接頭孔中的鋼絲彈性不足，可用鑷子挾住輕輕向上拉拉...
配置管理經驗談
1.配置項是橫向的,版本管理和變更管理是縱向的 2.利用我們手中的工具來實現我們的一些軟體工程的思想，一些管理思想，一些潛移默化的流程給固定下來，形成一種習慣，一種制度。3.多發現工具，寫些自動化指令碼，較少重複的工作，花更多的時間研究cmmi和一些關於流程體系的東西 4.思想是人才有的，讓機械重複...