本來打算今天下午征人去打網球的，邊等人應征邊打實況，結果人沒征到，實況卻有所進步了，hiahia!
最近，每天下班后實況幾乎成為俺的必修課了。可是，不知道是因為什么，怎么就是玩不過電腦呢，搞得每次都很煩躁。偶爾也有狀態(tài)好打得不錯的時候，只是每次都曇花一現，過了兩天又被電腦郁悶。防守到是好說，只要不是沖得太猛，保持好陣形，一般不會出什么大錯。但是進攻就很頭疼，屢屢打不開局面，打世界杯往往是三場小組賽一球不進，一球未失，最后積三分飲恨出局，那個郁悶就別提了。今天不知不覺進攻居然打開了局面，而且突然有所感悟。最高難度，世界杯，小組賽三場比賽，1：0，2：0，3：0芝麻開花節(jié)節(jié)高。1/8決賽2:0，1/4決賽1：0順利進入半決賽，只可惜遇到了法國這個變態(tài)隊，還有特雷澤蓋這個變態(tài)球員。上半場完全被法國壓著打，下半場好不容易有所起色，有了一腳極具威脅的射門，以及后續(xù)的連續(xù)進攻，卻被特雷澤蓋這個變態(tài)反擊中30米開外，背對球門的一腳半轉身軟綿綿的地滾球洞穿球門，而這個時候法國隊前場是2打5的局面。雖然被電腦賴了一回，但我并不生氣，因為總算有些進攻的感覺了，在這個感覺消失之前，一定要寫下來，并且溫故而知新。
說說進攻吧：
1. 千萬不能急，除非對方拚搶非常兇狠的情況下，不要隨便快速出球，一定要等拿穩(wěn)了球，傳球方向確定之后再出球。
2. 當對方逼搶上來的時候，還有一定距離的時候，可以按對方沖刺的方向相反的方向帶球，過了這個逼搶的人之后，再輕松出球
3. 當出現同等機會的球的時候，要提前預測拚搶沖撞之后球的方向，在合適的時機采取行動，而不要從一開始就一直按住鏟球或者搶球鍵不放。
4. 要注意發(fā)現敵人的空檔，尤其是吸引了對方上來拚搶之后，拼搶得人原來所在的位置是一定有空檔的。這時候通過合理的方式將球轉移到那個方向，一定會有所收獲的。
5. 前面沒有好機會的時候，可以回傳，然后慢慢組織進攻，拉開對方防守陣線，制造和尋找空檔。
6. 當機會出現的時候不要猶豫，堅決轉身，堅決加速，掄開了大腳就射吧。尤其是球到了前鋒腳下的時候。
7. 當出現賴皮點球的時候，打中路低平球，往往有奇效，否則，你就等著吧，不是偏了，就是中柱。
至于防守：
1. 保持陣形最重要
2. 即時發(fā)現空檔，而且是沖著空檔去補位，不是沖著對方球員去補位
3. 角球要小心謹慎
4. 出現緊急情況時，該放倒就放倒，紅牌也再所不惜
5. 當進入關鍵比賽之后，隨時保持緊張，不能有絲毫松懈，今天就是沒有緊逼特雷澤蓋導致球門失守的，其實當時他旁邊至少有兩個防守隊員，當時就該放倒這個變態(tài)的。
目前來講，打實況還是沒有戰(zhàn)術上的東西，以后一定要在這方面培養(yǎng)一下，否則就永遠不可能有真的進步了，呵呵。這可能與我性格優(yōu)柔寡斷，總是拿不定主意有關系吧。一定要克服這個毛病，哼哼！
待續(xù)。。。
osg存在兩棵樹，場景樹和渲染樹。場景樹是一顆Node組成的樹，這些Node可能是矩陣變換，或者是狀態(tài)切換，或者是真正的可繪制對象，它既反映了場景的空間結構，也反映了對象的狀態(tài)。而渲染樹則是一顆以StateSet和RenderLeaf為節(jié)點的樹，它可以做到StateSet相同的RenderLeaf同時渲染從而不用切換Opengl狀態(tài)，并且做到盡量少的在多個不同State間切換。渲染樹在CullVisitor的cull過程中逐漸創(chuàng)建。
SceneView包含兩個與渲染相關的兩個成員，一個RenderStage對象與StateGraph對象
StateGraph顧名思義，就是以狀態(tài)為節(jié)點的圖。StateGraph包含了真正的可渲染對象RenderLeaf，但是一個StateGraph是不夠的，因為不同的RenderLeaf可能會有不同的StateSet，于是StateGraph內部包含一個以StateSet為key，StateGraph為value的Map對象，從而形成一顆渲染樹
渲染時以該渲染樹為基準按一定順序逐漸渲染各個RenderLeaf。以何種方式遍歷該樹呢，這正是RenderStage的任務。
RenderStage從RenderBin派生
RenderBin包含了一個StateGraphList，該List將渲染樹中的各個StateGraph摘取出來，形成列表。形成列表的過程就是遍歷渲染樹的過程。RenderStage可以在RenderBin渲染之前之后做一些預處理和后處理，以完成一些特殊效果。
RenderStage包含兩種類型的RenderBin，透明與不透明的。對于Transparent RenderBin比較難處理，就是必須按深度順序調用gl函數渲染對象，否則可能半透明會有問題。對于Opaque RenderBin則沒有此限制，它只需按照盡量少切換狀態(tài)的原則排列StateGraph即可。
StateSet的SetRenderingHint函數可以用來控制使用那個RenderBin進行渲染，題外話，StateSet的setAttributeAndModes函數可以指定AlphaFunc與BlendFunc，前者功能相當于Alpha測試，后者則反映了Alpha混合的方式。使用方式類似下面：
BlendFunc* func = new BlendFunc();
func->setFunction(...);
dstate->setAttributeAndModes(func, StateAttribute::ON);
可以參考的相關osg代碼：
void CullVisitor::apply(Geode& node)
void CullVisitor::addDrawableAndDepth(osg::Drawable* drawable,osg::RefMatrix* matrix,float depth)
StateGraph的部分函數。。。
void RenderLeaf::render(State& state,RenderLeaf* previous)
void RenderBin::drawImplementation(osg::State& state,RenderLeaf*& previous)
void RenderStage::drawImplementation(osg::State& state,RenderLeaf*& previous)
這兩天終于閑了下來有時間寫點東西了，只記得想寫相機已經是很久遠的事情了，開發(fā)中涉及到相機相關的內容也已經是兩個月之前了。
在3D的世界里相機與矩陣是密不可分的，首先在投影之前，有模型矩陣和視圖矩陣，這兩者并沒有本質上的區(qū)別，一個是站在模型的角度，另一個就是站在觀察者的角度了。模型的左移相當于相機右移，有鑒于此，OPENGL中并不區(qū)分Model Matrix 和 View Matrix，而是將兩者統稱為ModelView Matrix.
以gluLookAt函數為例，該函數根據眼睛的位置，場景中心的位置，以及一個從觀察者視角向上的向量定一個視圖轉換，實際上做的還是應用一個ModelView Matrix。原點位置和眼睛位置確定了z方向向量，向上的向量確定了y方向向量，兩者正交，叉積就是z方向向量了，這樣就可以確定一個視圖矩陣了。
相機不僅僅與ModelView Matrix有關，而且也與投影矩陣有關系。有了相機，再結合ViewPort大小，FOVy（Y方向Field Of View）或者Aspect Ratio，近裁減面，遠裁減面就可以確定透視投影矩陣了。
一個4*4的矩陣如何與模型/視圖變換聯系起來呢？看這個圖，前三個列向量分別代表新坐標系的x,y,z軸方向，而最后一個向量則代表平移量（新坐標原點），而矩陣的（4，4）元素則是一個放大因子，他同時將所有點之間的距離放大。如果我們把一個四維向量與之相乘，就可以得到新的坐標了。
什么是萬向節(jié)鎖（Gimbal Lock）呢？這是采用歐拉角的方式表示相機時出現的問題。這個問題源于繞軸旋轉時自由度的丟失。因為旋轉到軸向時將無法確定是從哪個方向旋轉過來的。這就有點像是北極與南極點的經度無法確定一個道理。而且在這個地方，可能出現角度的不連續(xù)變化。即直接從0度跳轉到180度。在相機方向平行于X軸向時，繞X軸的旋轉不會有任何效果，也就是說，從數學上來講此時的ModelView Matrix始終是不變的。在計算時，由于角度變化不連續(xù)，所以計算的結果是很不穩(wěn)定的。例如漫游旋轉時，簡單的增加角度，可能在某些臨界值上出現錯誤的情況，典型的就是繞某一個軸的來回震蕩，這也就是所謂Lock的意義了吧。
這兩天一直在研究一個Crash問題，其表現非常明顯就是Memory Heap被破壞了，但是由于破壞堆的現場無法準確定位，發(fā)生Crash的地方已經不是現場，所以一直都沒找到原因。最后只好將代碼Roll Back回去，一個一個模塊的試，最終發(fā)現問題出現在某一個模塊中指針類型的強制轉換引起的虛函數調用錯誤上。
錯誤是這樣的，有一個指針是A類型的，被強制轉換為B類型，并且通過B類型調用B的虛函數，但是實際上調用的虛函數地址在A的虛函數表中。由于兩者參數并不相同，所以導致錯誤出現。
B類型的函數參數中有一個std::vector類型，由于c++遵循cdecl調用約定，所以是由被調用端負責清理堆棧，這時候就會調用std::vector的析構函數，而實際上該參數已經在調用A的虛函數時被破壞了，在執(zhí)行完這個函數之后，棧是正確的，但是堆已經被std::vector的析構函數破壞，所以出現了heap Corruption的錯誤。
Heap Corruption是C++開發(fā)中非常棘手的一個問題，其引起的Crash有兩點非常難以琢磨：
1. 在Debug版較難或者不出現，在Release版常常出現
2. 在Release版本上也是在非現場出現，而且往往在大量釋放內存的地方出現。
相信應該有比較好C++的Heap Corruption工具，BoundChecker曾經用過，可惜太復雜不會用，不知道有沒有非常有效的檢測Heap Corruption工具。
最近好懶啊，不愿意打字。突然想起以前的一個做的一個職業(yè)心理分析，挺準的，呵呵，把它貼出來，豐富一下俺的Blog吧，很神奇的是，最后列出的職業(yè)中前三項分別是我以前做的，現在做的和將來的目標。
Psytopic分析：您的性格類型是“INTP”(內向+直覺+思維+知覺)
對任何感興趣的事物，都要探索一個合理的解釋。喜歡理論和抽象的事情，喜歡理念思維多于社交活動。沉靜，滿足，有彈性，適應力強。在他們感興趣的范疇內，有非凡的能力去專注而深入地解決問題。有懷疑精神，有 時喜歡批判，常常善于分析。
INTP型的人是解決理性問題者。他們很有才智和條理性，以及創(chuàng)造才華的突出表現。INTP型的人外表平靜、緘默、超然，內心卻專心致志于分析問題。他們苛求精細、慣于懷疑。他們努力尋找和利用原則以理解許多想法。 他們喜歡有條理和有目的的交談，而且可能會僅僅為了高興，爭論一些無益而瑣細的問題。只有有條理的推理才會使他們信服。通常INTP型的人是足智多謀、有獨立見解的思考者。他們重視才智，對于個人能力有強烈的欲 望，有能力也很感興趣向他人挑戰(zhàn)。 INTP型的人最主要的興趣在于理解明顯的事物之外的可能性。他們樂于為了改進事物的目前狀況或解決難題而進行思考。他們的思考方式極端復雜，而且他們能很好地組織概念和想法。 偶爾，他們的想法非常復雜，以致于很難向別人表達和被他人理解。 INTP型的人十分獨立，喜歡冒險和富有想象力的活動。他們靈活易變、思維開闊，更感興趣的是發(fā)現有創(chuàng)見而且合理的解決方法，而不是僅僅看到成為事 實的解決方式。
您適合的領域有：計算機技術 理論研究、學術領域 專業(yè)領域 創(chuàng)造性領域等
您適合的職業(yè)有：
· 電腦軟件設計師
· 系統分析人員
· 計算機程序員
· 研究開發(fā)專業(yè)人員
· 數據庫管理
· 故障排除專家
· 戰(zhàn)略規(guī)劃師
· 金融規(guī)劃師
· 信息服務開發(fā)商
· 變革管理顧問
· 企業(yè)金融律師
· 大學教授
· 科研機構研究人員
· 數學家
· 物理學家
· 經濟學家
· 考古學家
· 歷史學家
· 證券分析師
· 金融投資顧問
· 律師
· 法律顧問
· 財務專家
· 偵探
· 各類發(fā)明家
· 作家
· 設計師
· 音樂家
· 藝術家
· 藝術鑒賞
本來上個周末就應該寫Camera相關的內容的，結果拖到今天還沒寫，現在有想寫一點osg中的Render Engine，今天還了解了https的基本原理，也有所感觸，都想寫下來。可惜今天太累了，以后慢慢寫吧，不會說我是等明天吧，呵呵。
剛開始使用Ogre時總是碰到內存泄露，而且往往是一泄千里，等半分鐘才能打完日志，我想這和Ogre中的大量大對象很有關系。下面就來分析一下內存泄露的產生原因。
1. MFC中使用Ogre時發(fā)生的內存泄露
這個問題比較有意思，其實并沒有發(fā)生泄露，而是MFC自作主張的認為發(fā)生了內存泄露，實際上內存并不是沒有釋放，而是在VC報內存泄露之后釋放，先來看一看MFC報內存泄露時的調用堆棧：
msvcr71d.dll!_CrtDumpMemoryLeaks() 行2208 C
mfc71d.dll!_AFX_DEBUG_STATE::~_AFX_DEBUG_STATE() 行127 C++
mfc71d.dll!_AFX_DEBUG_STATE::`scalar deleting destructor'() + 0xf C++
mfc71d.dll!CProcessLocalObject::~CProcessLocalObject() 行472 + 0x26 C++
mfc71d.dll!CProcessLocal<_AFX_DEBUG_STATE>::~CProcessLocal<_AFX_DEBUG_STATE>() + 0xf C++
mfc71d.dll!$E10() + 0xd C++
mfc71d.dll!_CRT_INIT(void * hDllHandle=0x7c140000, unsigned long dwReason=0, void * lpreserved=0x00000001) 行234 C
mfc71d.dll!_DllMainCRTStartup(void * hDllHandle=0x7c140000, unsigned long dwReason=0, void * lpreserved=0x00000001) 行288 + 0x11 C
AFX_DEBUG_STATE的析構函數：
_AFX_DEBUG_STATE::~_AFX_DEBUG_STATE()
{
#ifndef _AFX_NO_DEBUG_CRT
_CrtDumpMemoryLeaks();
int nOldState = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
_CrtSetDbgFlag(nOldState & ~_CRTDBG_LEAK_CHECK_DF);
_CrtSetReportHook(pfnOldCrtReportHook);
_CrtSetDumpClient(pfnOldCrtDumpClient);
#endif // _AFX_NO_DEBUG_CRT
}
很顯然CrtDumpMemoryLeaks()是在mfc71d.dll卸載時被調用的，如果這個時候OgreMain_d.dll還沒有卸載，那么在Ogre中new的全局變量也就還沒有釋放，所以MFC會認為產生了內存泄露。如何處理這樣的問題呢。很簡單，讓OgreMain_d.dll在mfc71d.dll之前析構，但是默認的MFC程序似乎不是這樣干的（為什么呢？），這就要求對項目設置作一點調整，使得Mfc71d.dll在OgreMian之前被鏈接，這樣程序運行時MFC71d就會早于Ogre加載，也就晚于Ogre卸載。具體設置如下：
i) in the General tab, switch "Use MFC in a shared DLL" to "Use Standard Windows Libraries"
ii) in the C/C++/Preprocessor tab, add _AFXDLL to the preprocessor definitions
iii) in the Linker/Input tab, add mfc80d.lib anywhere before OgreMain_d.lib
另一種方法是，使用Ogre自己的MemoryManager，并且禁止調用MFC的DEBUG_NEW，這需要先
#define OGRE_DEBUG_MEMORY_MANAGER 1
然后刪除cpp中的以下行
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
這樣Ogre中會使用自己的new/delete，而不是調用vccrt中的_heap_alloc_debug
2. Ogre中的對象沒有釋放
由于Ogre中的很多對象并不是只要delete Root就可以釋放的。最好所有的對象都不要自己new，而是通過Ogre::Root，Ogre::SceneManager等創(chuàng)建，這些對象在Root析構時會自己銷毀，但是對于從Ogre類派生的類，由于Ogre不存在Create這些類的函數，所以只能在自己的代碼中new產生，并由自己負責析構了，比如MovableObject派生的MovableText。當然Ogre也會給你一個將新對象加入其管理的接口，對于MovableText就必須再實現一個MovableTextFactory才行。總之要小心小心再小心。
最后抱怨一下Ogre太大了，有一個OgreLite就好了。現在這樣使用起來光鏈接都要半天，真是太夸張了，所以沒事最好不要修改Ogre庫，呵呵。
最近由于工作的關系，希望用一個3D圖形引擎實現棋牌類的2D游戲桌面。為了提供盡可能好的兼容性，選擇了Ogre作為后臺渲染引擎，因為它的評價在開源3D引擎中很不錯，而且同時支持Opengl和D3D，所以沒有多想就選擇了它。到后期才發(fā)現，Ogre雖然是號稱“Object Oriented Graphics Render Engine”，而且確實在場景，相機，窗口等等的三維對象的建模上做得相當不錯，但是其對于OCP等原則的遵循僅僅是大面上，Ogre中隨處可見一些巨大的對象類。所以要擴展它或者重用它的部分功能簡直是太困難了，不得已而拋棄了Ogre。這倒不一定是Ogre的錯，因為Ogre定位于游戲制作的，追求的是最新最酷的特效，這樣肯定很難從一開始就抽象好的。而且它要同時支持Opengl和D3D，這也是一個抽象的困難點。
雖然沒有使用Ogre，但是對于Ogre中多窗口渲染方式的實現還是很下了一番功夫的，不想這些功夫白白浪費，還是把它寫出來與所有人共享吧。
為了提供同一個用戶同時打多局游戲的可能，所以采用Ogre的話必須支持多桌面渲染，這里有兩點需要考慮：
1. 窗口渲染而不是全屏幕渲染
2. 多窗口渲染，每一個窗口使用不同的三維場景數據。
先說說Ogre如何做到窗口渲染吧。Ogre中對應每一個渲染窗口有一個RenderWindow對象，該對象通過Root的CreateRenderWindow方法創(chuàng)建，為了與現有的GUI窗口兼容，我不希望Ogre為我產生新的HWND，而是把一個HWND作為參數傳遞給CreateRenderWindow方法，這是通過以下方法做到的：
Ogre::NameValuePairList parms;
parms["externalWindowHandle"] = Ogre::StringConverter::toStrin((long)hwnd);
bool bFullScreen = false; RECT rect; ::GetWindowRect(hwnd, &rect);
int windowWidth = rect.right - rect.left;
int windowHeight = rect.bottom - rect.top;
Ogre::RenderWindow* window = m_OgreRoot->createRenderWindow(windowName, windowWidth, windowHeight, bFullScreen, &parms);
關于多窗口渲染，則需要先說說Ogre中的場景結構：
如圖所示，Ogre中一切起源于Root對象，它負責產生和銷毀所有Manager。SceneManager負責管理場景數據，所以為了實現多窗口，必須要有多個SceneManager實例，SceneManager中包含MovableObject，顧名思義，MovableObject是場景中可以運動的物體，SceneManager中還有一些靜止不變的數據，比如Terrain等等，圖中并未列出。MovableObject如果不掛在SceneNode上在場景中是無法顯示出來的，一個SceneNode上可以掛多個MovableObject，這樣組織成一棵場景樹的結構，值得一提的是MovableObject是無法共享的，也就是說它只能掛在一個SceneNode下，想共享的話，只有使用Mesh了。Mesh由MeshManager產生，它定義了基本幾何形狀。一輛汽車可以同時在場景多個部分出現，顯然不需要每一輛汽車創(chuàng)建一個幾何形狀，公用一個Mesh即可，這正是Entity的工作方式。Entity還提供了位置，動畫等信息的封裝。
有了多個SceneManager之后如何讓這些場景渲染到指定的多個窗口上呢。這要通過Camera和Viewport實現。這里也正是Ogre設計得比較精巧的地方。Camera定義了觀察者從哪個位置以及角度觀察場景，以及可以觀察的范圍（視角，最遠與最近位置等等），而RenderWindow通過Camera創(chuàng)建一個自身的Viewport，使得場景可以渲染到RenderWindow上。具體的渲染機制我并沒有深入研究，在Root中應該有相關代碼。
說了這么多，還是來看看Ogre中多窗口渲染的代碼吧
Ogre::NameValuePairList parms;
parms["externalWindowHandle"] = Ogre::StringConverter::toString((long)hwnd);
RECT rect;
::GetWindowRect(hwnd, &rect);
int windowWidth = rect.right - rect.left;
int windowHeight = rect.bottom - rect.top;
Ogre::RenderWindow* window = m_OgreRoot->createRenderWindow(ogreNameFactory::applyWindowName(), windowWidth, windowHeight, false, &parms);
// Create SceneManager
m_SceneManager = m_OgreRoot->createSceneManager(Ogre::ST_GENERIC, ogreNameFactory::applySceneManagerName());
// Set ambient light
m_SceneManager->setAmbientLight(Ogre::ColourValue(1.0, 1.0, 1.0));
//Create Camera
m_Camera = m_SceneManager->createCamera(ogreNameFactory::applyCameraName());
m_Camera->setProjectionType(Ogre::PT_ORTHOGRAPHIC);
m_Camera->setFixedYawAxis( true, Ogre::Vector3(0, -1, 0) );
//// Position it at 500 in Z direction
m_Camera->setPosition(Ogre::Vector3(Ogre::Real(windowWidth)/2.0, Ogre::Real(windowHeight)/2.0, -260));
//// Look back along -Z
m_Camera->lookAt(Ogre::Vector3(Ogre::Real(windowWidth)/2.0, Ogre::Real(windowHeight)/2.0, 0));
m_Camera->setFOVy(Ogre::Degree(180.0 - 1.6416));
m_Camera->setNearClipDistance(5);
m_Camera->setFarClipDistance(271);
// Create one viewport, entire window
Ogre::Viewport* vp = window->addViewport(m_Camera);
vp->setBackgroundColour(Ogre::ColourValue(0,0,0));
//// Alter the camera aspect ratio to match the viewport
m_Camera->setAspectRatio(Ogre::Real(windowWidth) / Ogre::Real(windowHeight));
////Used for Hittest
Ogre::Ray aimRay = m_Camera->getCameraToViewportRay( 0, 0 );
m_RaySceneQuery = m_SceneManager->createRayQuery(aimRay);
// Make window active and post an update
window->setActive(true);
window->update();
代碼中與相機設置相關的部分看不懂美關系，關于相機的設置，我會在另一篇文章中詳細分析之。以上的代碼將成功的在hwnd上初始化渲染環(huán)境，現在要做得就是在SceneManager中添加Entity了，需要重繪的時候調用RenderWindow的update()即可。
時間不早了，打算今晚去星美看通宵電影，關于Camera的詳細分析就留到明天繼續(xù)吧，哈哈。
1. String類不能修改，只能通過new的方式或者函數返回值來獲取。而且有一個String池的概念，如果我們寫
String a = "aaaa";
String b = "aaaa";
那么a與b將指向同一份引用。這么做我想也是明確了文字常量這一“常量”的基本概念。
2. Array轉List可以利用Java.util.Arrays的asList方法，而List也有toArray方法轉為數組。Array打印可以用Arrays.toString方法，而List直接用toString就ok了。
3. Boolean賦值用TRUE/FALSE，boolean賦值用true/false
在使用stlport時，項目根據什么原則判斷是鏈接到靜態(tài)的stlport庫，還是動態(tài)的stlport庫呢？
對于MSVC來講，這一切的奧妙都在stlport/config/_msvc.h里。在這里有幾個宏需要特別注意：
_STLP_USE_DYNAMIC_LIB：定義這個宏，則鏈接到動態(tài)庫
_STLP_USE_STATIC_LIB：指示鏈接到靜態(tài)庫
_DLL：如果項目選項里設置了/MD 或者 /MDd Code Generation->Runtime Library->Multi-threaded Debug DLL (/MDd)，那么將會自動定義宏_MT 和 _DLL，看到_DLL這個宏，自動鏈接到stlport動態(tài)庫。
所以，靜態(tài)還是動態(tài)鏈接到CRT庫（多線程時為LibCMT.lib，單線程時為LibC.lib)，通過項目設置即可做到，此時stlport作為C++庫，也會自動根據項目設置調整。如果希望鏈接到stlport庫時的形式與CRT庫不一致，那么可以通過定義_STLP_USE_DYNAMIC_LIB或者_STLP_USE_STATIC_LIB做到。
參考：關于/MD /MT等選項的意義，可以參考MSDN相關內容