在 C++ 中傳遞原始數據

Question

到目前為止，每當我想將一些原始數據傳遞給函數（例如從緩沖區加載圖像的函數）時，我都會執行以下操作：

void Image::load(const char* buffer, std::size_t size);

今天我查看了 Boost 庫，更具體地說是在property_tree/xml_parser.hpp頭文件中，我注意到了這個函數簽名：

 template<typename Ptree> 
 void read_xml(std::basic_istream<typename Ptree::key_type::value_type>&, 
               Ptree &, int = 0);

這實際上讓我感到好奇：這是使用流在 C++ 中傳遞原始數據的正確方法嗎？ 還是我誤解了該函數的用途？

如果是前者，能否請您指點我一些可以學習如何使用流的資源？ 我自己沒有找到太多東西（主要是 API 參考），我也找不到 XML 解析器的 Boost 源代碼。

---

編輯：一些額外的細節

似乎對我想要什么有些困惑。 給定一個數據緩沖區，如何將其轉換為流，使其與我上面發布的read_xml函數兼容？ 這是我的具體用例：

我正在使用SevenZip C 庫從存檔中讀取 XML 文件。 該庫將為我提供一個緩沖區及其大小，我想將其置於流格式中，以便與read_xml兼容。 我怎樣才能做到這一點？

Answer 1

嗯，流在 C++ 中非常常用，因為它們很方便：
- 錯誤處理
- 它們抽象出數據源，因此無論您是從文件、音頻源還是相機中讀取，它們都被視為輸入流
- 可能還有更多我不知道的優勢

這是 IOstream 庫的概述，也許可以更好地幫助您了解流的情況： http ://www.cplusplus.com/reference/iostream/

了解它們究竟是什么將幫助您了解如何以及何時使用它們。

Answer 2

沒有單一的正確方法來傳遞數據緩沖區。 指針和長度的組合是最基本的方式； 它是 C 友好的。 傳遞流可能允許順序/分塊處理 - 即不在同一時間將整個文件存儲在內存中。 如果您想傳遞可變緩沖區（可能會增長）， vector<char>&將是一個不錯的選擇。

特別是在 Windows 上，可能會使用 HGLOBAL 或節對象句柄。

C++ 哲學明確允許許多不同的風格，具體取決於上下文和環境。 習慣它。

Answer 3

C++ 中的原始內存緩沖區可以是unsigned char*類型，也可以創建一個std::vector<unsigned char> 。 您通常不想只對緩沖區使用char* ，因為標准不保證char使用單個字節中的所有位（即，這最終會因平台/編譯器而異）。 話雖如此，流也有一些很好的用途，考慮到您可以使用流從文件或其他輸入等讀取字節，然后從那里將該數據存儲在緩沖區中。

Answer 4

似乎對我想要什么有些困惑。 給定一個數據緩沖區，如何將其轉換為流，以便與我上面發布的 read_xml 函數兼容？

很容易（我希望PTree::Key_type::value_type類似於char ）：

istringstream stream(string(data, len));
read_xml(stream, ...);

更多關於這里的字符串流。

Answer 5

這實質上是使用引用來傳遞流內容。 所以在幕后，它本質上與你目前所做的非常相似，而且本質上是相同的——只是使用了不同的符號。 簡而言之，引用只是隱藏了指針方面，因此在您的 boost 示例中，您實際上是在使用指向流的指針。

引用具有避免所有引用/取消引用的優勢，因此在大多數情況下更容易處理。 但是，它們不允許您進行多級（取消）引用。

以下兩個示例函數的作用基本相同：

void change_a(int &var, myclass &cls)
{
    var = cls.convert();
}

void change_b(int *var, myclass *cls)
{
    *var = cls->convert();
}

談論傳遞的數據本身：這實際上取決於您要實現的目標以及更有效的目標。 如果您想修改字符串，使用std::string類的對象可能比使用指向緩沖區的經典指針 ( char * ) 更方便。 流的優勢在於它們可以表示幾種不同的事物（例如網絡上的數據流、壓縮流或簡單的文件或內存流）。 通過這種方式，您可以編寫接受流作為輸入的單個函數或方法，並且可以立即工作而無需擔心實際的流源。 使用經典緩沖區執行此操作可能會更復雜。 另一方面，您不應該忘記所有對象都會增加一些開銷，因此根據要完成的工作，指向字符串的簡單指針可能非常好（也是最有效的解決方案）。 沒有“唯一的方法”。