Boost logo

Boost :

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2004-11-10 10:19:37


> I've just finished documenting a small library, available here:
>
> http://home.comcast.net/~jturkanis/format_lite/
>
I took (brief) look and have question about feasibility of other idea:

- would it be possible to combine format_lite functionality with
Boost.Serialization to take advantage of both libs?

Imagine solution like:

// the formatting info is provided via boost::archive compatible object
formatted_text_oarchive arch(a_ostream, default_formatting_settings ....);

arch << my_data;

class MyObject
{
     template<class Archive>
     void serialize(Archive& ar, const unsigned) {
           .... normal serialization code, used when we DO NOT do formatting
output
     }
     // specialization for debug formatting
     template<>
    void serialize<formatted_text_oarchive>(....) {
          ar << my_vector; // default formatting will apply

          ar << "some info text...";
          ar.increase_indentation();

          // use different formatting for next vector
          punctuate<vector<...>(ar)(....);
          ar << my_other_vector;
    }
};

The advantages I see:
 - the whole infrastructure of Boost.Serialization is available and ready
   and it handles all situations like cycles. format_lite could concentrate
   on just formatting.

- the debugging output can be separated from other serialization types
  (but doesn't need to be)

- formatting directives can be "inherited" from
  "higher level of data" to "lower levels". Newly added data would
   not need formatting of its own by default. Change on higher level
   would propagate itself "down".

- indentation for pretty printing could be handled (semi)automatically
  by formatting archive.

- multiple formatting styles could be provided for any class.

My experience is that Serialization is quite easy to use and
lightweight enough so I do not consider it any disadvantage
for practical use.

/Pavel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk