有人說 反射反射，程序員的法寶。這句話一點也沒有錯。如果能夠動態(tài)的加載類和方法，就等于徹底的解除了類和類，方法和方法的耦合。
當然，這樣編譯器就無法幫你檢查出其中的錯誤了，還是有一定的風險的。
總的來說，反射是一位好同志。他可以讓程序的擴展變得如此方便，免除了重新編譯之苦。
近來在玩C++，被其中的種種細節(jié)問題搞得暈頭轉向。
用LoadLibrary實現動態(tài)加載類，花了很多時間在dll的路徑問題上。
在傳入相對路徑時，文件的查找順序比較詭異，在XP sp2以后首先是系統(tǒng)目錄開始搜索，以前是首先從當前目錄開始搜索。微軟認為當前目錄是不安全的。所以如果很不巧你的System32下有一個同名的dll時，會造成dll版本的混亂。
解決這個問題，要改用LoadLibraryEx(path,NULL,LOAD_WITH_ALTERED_SEARCH_PATH);
另一種方法是先調用SetDllDirectory方法，將要設置的目錄會優(yōu)先開始搜索。
以上兩種方法是權宜之計，最值得推薦的方法是用絕對路徑而不是相對路徑。要獲得絕對路徑就要知道當前程序的目錄。問題來了，怎么獲得當前目錄呢？
我當時是一拍腦袋，用了GetCurrentDirectory方法。用了才發(fā)現，得到的路徑并不穩(wěn)定，有時候會得到莫名其妙的路徑，甚至在不同電腦上有不同的結果。
正確的解決方法麻煩了許多，要先AfxGetInstanceHandle()得出模塊句柄，然后得到當前模塊包含路徑的全名GetModuleFileName，最后通過字符串操作，去掉最后一個 / 后的內容，才得到當前路徑。
解決了這些問題，LoadLibrary路徑沒問題，得到結果卻是0，GetLastError得到126，找不到指定的模塊。我和同事一致認為是dll的其他依賴缺失。用depends打開這個dll，所有依賴都沒問題啊，Why？
后來我試著把dll和依賴放的滿磁盤到處都是，終于找出了問題所在：
我的程序主模塊app.exe和要加載的模塊 plugins/plgn1.dll不是在同一級目錄下，在用depends打開plgn1.dll時，會在當前目錄（/plugins/）下尋找其他依賴，這些依賴都在。
而LoadLibrary加載的模塊 plugins/plgn1.dll時，他認為的當前路徑是相對主模塊app.exe來說的，是程序根目錄（/）而不是/plugins/，所以就找不到相關依賴，導致plgn1.dll加載失敗。
解決方法：SetDllDirectory方法，設置為plgn1.dll所在的絕對路徑。