c++ - Boost Serialization – Avoid string length output? -

c++ - Boost Serialization – Avoid string length output? -

i'm serializing info coming off of 2 different branches of project. info outputted in text archive form using boost::serialization. since diff made between 2 serialized files, i'm adding debug messages serialized files between each serialized part, improve see point @ difference in output may occur.

here broad overview of code i'm using:

std::ofstream ofs("./somefile.txt"); // brevity's sake, no actual path used { boost::archive::text_oarchive oa(ofs); std::string debug_str; debug_str = "\n\npart 1\n"; oa & debug_str; // ... other serialized parts ... debug_str = "\n\npart 145\n"; oa << debug_str; }

you can notice first thought used operator (& vs <<) made difference in output, yet doesn't, next text file :

22 serialization::archive 7 9 [crlf] [crlf] part 1 [crlf] 11 [crlf] [crlf] part 145 [crlf]

the 22 serialization::archive 7 part standard boost serialization header, identifying type of archive guess. afterwards comes part have removed, namely 9 – after bit of goose chasing figured out 9 length of "\n\npart1\n" string!

is expected behaviour or there way of circumventing output? in case of other actual records, there no apparent utilize of other such "control codes", marking length or such.

it useful add together debug output, yet because lengths of said debug strings may differ (since heavy refactoring occured on 1 of branches), diff yields false positives.

any thoughts appreciated, thanks!

i uncertainty possible.

the problem face here textual output need parsed back deserialized. there 2 main ways of structuring textual output can parsed easily:

length-prefixed strings special characters (with escape codes)

for example, in xml archive tags surrounded < , > , cannot utilize characters yourself, instead using escaped codes < , > respectively. on other hand, if @ redis format see things 13$hello, world! length of record string of digits, followed $, followed actual record.

the former way (length-prefixed strings) much more efficient, much less human writable.

from boost::serialization documentation, see 2 different "human-readable" archives:

boost::text_[i/o]archive uses length-prefixed string (it seems) boost::xml_[i/o]archive uses xml representation

you might want switch boost::xml_oarchive.

c++ boost-serialization