boost :: fusion的目的是什么？

Question

我花了整整一天的時間閱讀筆記並觀看了關於boost :: fusion的視頻，但我確實沒有涉及到任何方面。

以boost::fusion::has_key<S>函數為例。 在boost :: fusion中使用它的目的是什么？ 我們只是嘗試並盡可能多地移動編程以在編譯時進行的想法嗎？ 幾乎所有boost::fusion函數都與運行時版本相同，只不過它現在在編譯時求值？ （並且我們認為在編譯時做更多是好的嗎？）。

與boost :: fusion有關，我也有些困惑為什么元函數總是返回類型。 為什么是這樣？

Answer 1

查看boost :: fusion的另一種方法是將其視為“窮人自省”庫。 boost :: fusion的最初動機來自boost :: spirit解析器/生成器框架的方向，特別是需要支持所謂的“解析器屬性”。

想象一下，您有一個CSV字符串要解析：

aaaa，1.1

該字符串解析為的類型可以描述為“字符串和雙精度元組”。 我們可以使用舊式結構（ struct { string a; double b; }或較新的tuple<string, double> ）在“普通” C ++中定義此類元組。 我們唯一想念的是某種適配器，它將允許將任意組成的元組（和某些其他類型）傳遞給統一的解析器接口，並期望它在不傳遞任何帶外信息（例如字符串）的情況下理解它解析scanf使用的模板）。

那就是boost :: fusion發揮作用的地方。 構造“融合序列”的最直接方法是改編普通結構：

struct a {
    string s;
    double d;
};
BOOST_FUSION_ADAPT_STRUCT(a, (string, s)(double, d))

“ ADAPT_STRUCT”宏為解析器框架（在此示例中）添加了必要的信息，以便能夠“迭代” struct a成員，以解決以下問題：

1. 我只是解析了一個字符串。 我可以將它分配給struct a第一個成員嗎？

2. 我只是解析了一個雙。 我可以將它分配給struct a第二個成員嗎？

3. struct a是否還有其他成員，還是應該停止解析？

顯然，可以進一步擴展此基本示例（並通過boost :: fusion提供此功能）來處理更復雜的情況：

1. 變體-假設解析器可能遇到sting或double，並且希望將其分配給struct a的正確成員。 BOOST_FUSION_ADAPT_ASSOC_STRUCT可以解決（現在我們的解析器可以問“ struct a哪個成員是double類型？”之類的問題）。

2. 轉換-我們的解析器可以設計為接受某些類型作為參數，但其余程序已發生了很大變化。 然而，融合元功能可以方便地用於使新類型適應舊現實（反之亦然）。

其余的boost :: fusion功能自然遵循上述基礎。 當需要將“松散的IO數據”（在任一方向上）轉換為C ++程序所基於的強類型/結構化數據時（如果考慮效率的話），融合確實很出色。 它是spirit :: qi和spirit :: karma如此高效（可能是最快的）I / O框架背后的促成因素。

Answer 2

融合是編譯時和運行時容器與算法之間的橋梁。 您可能會或可能不想將某些處理移至編譯時，但是如果您願意，Fusion可能會有所幫助。 我認為它沒有特定的宣言來盡可能多地轉移到編譯時，盡管我可能是錯的。

元函數返回類型，因為模板元編程不是故意發明的。 偶然發現或多或少地發現C ++模板可以用作編譯時編程語言。 元功能是從模板參數到模板實例的映射。 從C ++ 03開始，有兩種模板（類和函數），因此元函數必須“返回”類或函數。 類比函數更有用，因為您可以將值等放入其靜態數據成員中。

C ++ 11添加了另一種模板（用於typedef），但這與元編程無關。 對於編譯時編程更重要的是，C ++ 11添加了constexpr函數。 它們是針對此目的而適當設計的，並且它們像正常函數一樣返回值。 當然，它們的輸入不是類型，因此它們不能以模板可以的方式從類型映射到其他對象。 因此，從這種意義上講，它們缺少元編程的“元”部分。 它們只是普通C ++函數而非元函數的編譯時評估。