我認爲你是在正確的軌道上,當你提到「函子」 ......
這是很常見的通過傳遞它的參數(一個或多個)一些對象的方法來處理的選項。如果您可以將方法包裝爲notifier()將接受的參數,那麼可以使用通知器直接完成此操作。你可以。 (如果boost :: function有辦法做到這一點,我對它並不熟悉(現在也懶得去研究它) - 下面使用STDLIB的頭部函數中的例程。)
示例:
其中一個選項是--config-file,其中包含一個字符串參數,該參數指示非默認配置文件的路徑。你有一個名爲ConfigParser的類。沒有通告程序,你的代碼可能是這個樣子:
ConfigParser *cp = new ConfigParser();
std::string cp_path;
desc.add_options()
("config-file", value<std::string>(&cp_path)->default_value("~/.myconfig"), "Config File")
// ... the rest of your options
;
cp->setPath(cp_path);
與發出通知:
#include <functional>
ConfigParser *cp = new ConfigParser();
desc.add_options()
("config-file", value<std::string>()->default_value("~/.myconfig")->notifier(std::bind1st(std::mem_fun(&ConfigParser::setPath), cp)), "Config File")
// ... the rest of your options
;
哦,現在我明白了。你必須尋找「通知者」,不通知。通知函數是通過一個const引用值,所以不能改變它?如果選項「不好」,除了拋出異常外,我不會看到太多的東西。 – olooney
@olooney:意圖是你採取任何預期的行動將與該選項。例如,如果您有更改搜索路徑的選項,您的通知程序功能將修改搜索路徑。正如我在回答中所指出的那樣,您可以在選項解析代碼中執行相同的邏輯,方法是分別檢查每個選項,然後執行一些操作,但這會導致很長的程序性blob,難以讀取或修改。 –
當然,但是沒有能力改變variable_map,將不透明的句柄傳遞給環境對象,或者綁定到functor(使用boost :: function),你真的只限於異常和* global *副作用。這對於更改工作目錄或設置全局「詳細」標誌仍然很有用,但它不足以將大部分選項解析移動到通知程序。也許我應該在做出判斷之前嘗試一下,我只是在這裏推理。 – olooney