從Boost :: spirit解析返回多種數據類型

Question

我想解析大約5-10種共享通用格式（例如JSON）的消息類型，但是每種消息都有需要驗證的特定字段。 最終，每條消息都應解析為具有不需要任何類型轉換的類型的自定義類/結構（例如，字段是int而不是變體/元組）。 我看到了解決該問題的兩種方法：

1. 為每條特定的消息編寫一個語法，以處理消息格式（在此示例中為JSON樣板）的驗證並驗證字段的內容，並返回真正的自定義結構

2. 編寫僅驗證結構（僅JSON規則）並返回更通用的對象（具有變體/元組等的字段）的語法，並在更高級別將其驗證/轉換為自定義結構（廣播和檢查各種變體字段）

我認為這些分別是優點和缺點：

優點1：

• 所有驗證均在boost :: spirit內完成
• 業力生成器（如果已編寫）看起來像現有的精神分析代碼

缺點1：

• 必須為將來可能會發明的每種新消息類型編寫和維護一個新語法（並且主語法不直觀）

優點2：

• 復雜的精神代碼編寫一次，很少被觸及

缺點2：

• 通用消息對象的驗證和翻譯將是凌亂的代碼，而精神本來應該消除的

哪種方法更好？ 是否存在使用一種語法將其解析為多種類型的第三種方法？

這是一些示例消息以及它們最終應駐留的類：

{"messageType": "messageTypeA", "numberParam": 1}
{"messageType": "messageTypeB", "stringParam": "Test"}

class MessageTypeA
{
public:
    double numberParam;
};

class MessageTypeB
{
public:
    std::string stringParam;
};

Answer 1

我認為這個問題確實接近於最近的答案，在此我恰好做到了：我回答了兩個答案：

1. 答案1：采用通用方法，僅根據特定的“方案”進行解釋
2. 答案2：采用臨時方法，OP認為這更容易

我的投票是第一選擇，因為

• “復雜的代碼只需編寫和測試一次，很少碰到”，超過了我經驗中的其他因素，
• 實際上，語法極大地受益於職責分離，並使AST真正接近自然規則屬性
• 我已經為適應Fusion的類型（使用融合“反射”）編寫了多個JSON后端（OData，Edm，版本，元數據級別）“風味”。 這些都共享相同的解析器/生成器。

甚至連鏈接問題中的OP稍后似乎也確實需要我的第一個答案已經提供的靈活性：

那好吧。 我很驚訝您當時接受了這個答案，因為另一個答案的確完全一樣，只是它確實接受並忽略了“其他” JSON內容。 您是否錯過了定義extract_from的更新？ 它使用完全相同的數據結構-您在問題中建議的結構。 – sehe 1月4日下午16:41