> 不是很理解dynamic invocation proxies的意思，但pxgenproxy –h=foo.h > setup.xml這個命令行里的foo.h是必須的嗎？
指定foo.h對pxgenproxy不是必須的，但對編譯生成后的代碼是必須的。-h=foo.h的目的只不過是讓pxgenproxy將#include "foo.h"加入到生成代碼中而已。
> 是必須的話那就離不開源代碼了，至少是離不開頭文件的。
> 這對于動態裝載進來的、無法預知源代碼或頭文件的程序來說，
> 譬如說那些允許裝載第三方插件的場合，就不太適用了。
foo.h只是頭文件，不是源代碼。這里，我們所真正要求的是提供class和函數的類型和簽名聲明。除了debug或腳本程序環境等少數特殊工具以外，絕大多數C++（甚至在ANSI-C）實際應用中并不存在要調用一個第三方class或函數而不知道函數的簽名或class的聲明的情況。我E文BLOG上討論的就是這個問題。最重要的一點就是：IOC的實質目的并不是提供一個腳本環境，而是組件架構。你的目的若是需要調用C++庫的腳本環境，請不要考慮POCOCAPSULE。
> 但是reflection卻可以使用在這種場合。譬如說在一個 dll/so里，
> 裝載進來時將reflection信息（class的名字、屬性和方法）注冊進某個
> factory之類的東西里，然后ioc container就能用class名字在factory
> 里找出并構造出那個class的實例，這個過程不需要頭文件和pxgenproxy
> 這樣的步驟。
關于reflection的陳述我完全同意。但IoC的實質目的（至少對于PocoCapsule IoC框架來說）與reflection并不相同。IoC完全不必照搬其他基于天然reflection機制的IoC框架實現。達到實質目的是最根本的。在我的E文BLOG文中比較了用reflection的缺點。。。。對絕大多數C++應用來說，reflection機制往往是有害的（主要是增加內存占用和限制開發方式。。。比如禁止了模板和宏的應用）
> vcf的reflection并不需要修改頭文件，它要求加的那些宏是用來聲明reflect
> 信息的，完全可以和class分隔開放在別的地方的，你對它的誤解我想可能
> 是因為它的例子里把那些宏寫在了class定義里頭。
謝謝指正。但需要人肉寫內些宏已經與使用IoC減少非業務邏輯代碼的編寫的除衷相矛盾了。
> 老實說，可能是受java的影響比較大，我自己并不喜歡pxgenproxy
> 這類帶點源代碼生成味道的東西，因為它會強迫你必須取得部分源代碼，
> 這不適用于動態的開放的基于二進制層次的構件復用的環境。
pxgenproxy根本不需要任何源代碼，也根本不會對使用第三方二進制模塊造成任何障礙。pococapsule實例代碼（見<
http://www.pocomatic.com/docs/cpp-examples）中有很多這些例子。。。比如調用stdio中的printf()，調用iostream中的std::cout<<() operator，調用第三方CORBA或SOAP引擎函數等等。。。。
> 但是，像vcf這類的reflection其實還是依賴于源代碼，
> 做得還是不徹底，因為c++編譯后沒有 meta data了。
> 可是c++ 0x不在乎這個，那我們也沒轍。
IoC框架的目的不是為了提供debug或腳本環境，而是為了將管線邏輯分離并轉移至框架內，并將讓框架基于用戶提供的聲明式描述來完成管線搭接和應用的部署配置。對于此目的，reflection并不是必須的。相反，在C++中加入reflection將不可避免地增大內存開銷，這對很多C++應用來說是致命的。所以，即使以后的C++升級加上了對reflection的支持（甚至CERN現在就有一個。。。請艘SEAL Reflex），PocoCapsule C++也不會考慮使用（同樣的道理，PocoCapsule完全避免使用exception, template, rtti, stl, iostream等等機制和庫，就是要盡量減少內存開銷）。當然，PocoCapsule不會去禁止業務邏輯模塊去使用這些機制或庫。
多謝討論!