Re: [boost] Re: generic polyvalent input/output ['pickle']

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2000-11-16 16:25:29

Asger Alstrup Nielsen wrote:
> Please have a closer look at XTL, because I feel that it solves most of
> the problems you are trying to address. No reason to reinvent the wheel.
> 
> The URL was:
> 
> http://xtl.sourceforge.net/

I've looked at XTL.

Please find my detailed comments below.
In general, the library seems to cover a lot of the issues.
I'm asking myself if it's efficient to pursue the boost
re-invention of this any further?

Beman, you should have a look at the XTL documentation as
well.

 - cfile_buffer is described in the documentation, but I could
not find it in the implementation anywhere at all.   What's
the equivalent iostream buffer?

 - text_format doesn't support input (yet?).  text_format doesn't
properly escape special characters in string output.  For example,
a " within a string makes the resulting output un-parseable.

 - The documentation starts with explaining the intrusive way of
adding a serialization function first.  This may shy away users,
since there is indeed a non-intrusive way (global function) as
well.

 - The copyright is LGPL, which seems to be incompatible with
the boost copyright policy.

 - I think that the "buffer" layer can be removed entirely.
I believe the correct way is to write a streambuf for C files
and fixed-size memory areas.  (std::stringstream is close (but
not fixed-size) to a memory area, btw.)

 - The interface does not use iterators.  For example, writing
any container (even user-defined ones, whithout assuming they
have begin() and end() methods) can be more flexibly achieved
by iterators.  And reading is happy with a back_insert_iterator
or similar.

 - Page 9 of the documentation mentions "partial specialization
of template functions".  This is a concept alien to ISO C++
(at the moment).  Overloading with partial ordering is the term
to be used.

 - The smart pointer example assumes an internally-counted
implementation, which should at least be explained explicitly.

 - Lots of ugly C-style type casts in the code.

 - Some macros are used without any deeper qualification.
Clashes may occur.

 - Include guards start with double underscores, which thus
infringe on the identifier space reserved for implementations of
C++.

 - The code is not in a namespace.

Jens Maurer