From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-10-01 01:54:02
Robert Ramey wrote:
Robert, can I first of all ask you to use a mailer, or a news reader, which
preserves threading? Recently experiments have shown that Mozilla
Thunderbird, for example, works fine both with emails and with NTTP
gateway, and it's free. You can also try some other clients, but please do
something about the issue.
>>> The idea of the library, as I see it, is to provide object
>>> - without the overhead serialization library has
>>> - with extra layout tweaks
>>Yes, it would be nice.
> For objects of the type being discussed, (i.e. no pointers, no class
> versioning, no memory tracking of duplicates, etc) the serialization
> library has no extra runtime overhead.
I was not talking about runtime overhead. To output something, I need at
least include appropriate archive headers. Last time I looked, they were
large and complex. This makes me nervous about including them in every
source file I have. Basically, I want every call I define to have a 'dump'
method which can be called from debugger. So, I need output facilities
available in every translation unit.
> serialization library did not result in smaller and faster code than the
> libraries being discussed.
Hmm... maybe serialization won't be much worse performance wise, but all the
levels of indirections which are there won't speed things up, that's for
sure. But anyway, speed is not my concern.
>>> I don't see why it's necessary to reinvent the object traversal code
> which is
>>> already in boost::serialization. For example, boost::serialization
>>> scoped_ptr. It would not make sense to add separate support for
> scoped_ptr in
> The serialization library has all that and much, much more.
Yes, we know that.
>>I would need to delve further into boost::serialize to have an oppoinion
>>- and the unfortunate thing is that I won't have any available time soon
> Too bad, it would have consumed much less time than has been already spent
> on this topic
> If function output formatters is helpful for making output more easily
> presentable, fine. Though G. Rozenthal's, experiment makes me doubt this.
> I believe the demos and documentation in the serialization package show
> that it to be much, much easier to use than the proposed library for this
Robert, while I agree that serialization is immensely usefull, the point you
make above is a bit skewed. Which example in the serialization library
shows how to change start/end delimiter of a vector?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk