Robert,
As you view binary archives as an extension to a basic serialization
library, which I can submit but which can be kept separate from the
core functionality - so can the polymorphic pointer
registration/serialization be viewed as an extension to a basic
serialization library that provid
Date: Tue, 26 Nov 2002 04:52:15 -0500
From: "Gennadiy Rozental" <[EMAIL PROTECTED]>
>> Some more elaborate registration system might be interesting and/or
>> useful, and presumably some unique id could be passed to the
>> serialization package, but beyond that it doesn't have to be used
>> by the
>// (C) Copyright 2002 Robert Ramey - http://www.rrsd.com . Permission to copy,
>// use, modify, sell and distribute this software is granted provided this
>// copyright notice appears in all copies. This software is provided "as is"
>// without express or implied warranty, and with no claim as t
> Date: Mon, 25 Nov 2002 05:14:23 -0500
> From: "Gennadiy Rozental" <[EMAIL PROTECTED]>
>
> >> 5.2 "registration" - A brief recap:
> > You did not comment on my Issue 1 and proposition to completely separate
> >registration into template parameter. This way you won't need any macro.
The
> >user wil
"Robert Ramey" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Date: Mon, 25 Nov 2002 11:08:32 +0300
> [...]
> a) a libray gets accepted to boost.
> b) some time after, someone comes up with a next great improvement
> c) so he tries to convince the original autho
Date: Mon, 25 Nov 2002 05:14:23 -0500
From: "Gennadiy Rozental" <[EMAIL PROTECTED]>
>> 5.2 "registration" - A brief recap:
> You did not comment on my Issue 1 and proposition to completely separate
>registration into template parameter. This way you won't need any macro. The
>user will choose what
> 5.2 "registration" - A brief recap:
You did not comment on my Issue 1 and proposition to completely separate
registration into template parameter. This way you won't need any macro. The
user will choose what kind of registration system he prefer at the later
stage.
Gennadiy.
_
On Saturday, November 23, 2002, at 01:34 AM, Augustus Saunders wrote:
[ lots of very interesting comments deleted]
One last thought on the
multiple format problem: it may be wiser to standardize all
serialization on XML and rely on XSLT to transform into all the
different formats we might want
On Friday, November 22, 2002, at 10:07 PM, Dave Harris wrote:
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 19 Nov 2002 08:09:13 +0100 Matthias Troyer
([EMAIL PROTECTED]) wrote:
The only solution which comes to my mind is additional virtual
functions for writing blocks of primitive types, which defa
> Could you please expand upon this? If serialization of fundamental type
is invoked
> through a base class member virtual functions are suggesting that this
> base class be built differently on a regular basis? Wouldn't this
preclude
> leaving serialization code in a precompiled library? Even i
Thomas Matelich wrote:
"Dirk Gerrits" wrote in message
ar37hg$6hm$[EMAIL PROTECTED]">news:ar37hg$6hm$[EMAIL PROTECTED]...
>Thomas Matelich wrote:
>
>
>>Anyway, seemed like a nice package for general use. My company is
>>currently in love with XML, so I probably wouldn't be using it for our
>>c
Date: Fri, 22 Nov 2002 16:28:34 -0500
From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
> > > The only solution which comes to my mind is additional virtual
> > > functions for writing blocks of primitive types, which default to
> > > just calling the operator<< (>>) n times, but can be overridden
>
Robert Ramey <[EMAIL PROTECTED]> writes:
> Thats all for now. I will have much more to say on this topic in the coming days.
Please say it soon, if so. The review period ends on Monday and I'd
like to have your information for when I evaluate everything
Thanks,
Dave
--
Hi,
I've been following the library and the discussion surrounding it since it
was first announced on the list.
I believe it is a very important and much needed component and I thank
Robert for bringing it forward to the boost community!
For the review I have gathered some issues I would like to b
Date: Fri, 22 Nov 2002 16:34:46 -0800 (PST)
From: Augustus Saunders <[EMAIL PROTECTED]>
>Persistence: A transformation-less transfer of application native
>data to an alternate storage medium. Only useful and only intended
>to be useful to applications that apriori agree on object type and
>layo
I have been following the discussion thread for the serialization
library review with some interest, as I think the topic is of extreme
importance. Right up there with smart pointers and threading, it's
something that would be used by many people for many different
things. I want to thank Robert
> > The only solution which comes to my mind is additional virtual
> > functions for writing blocks of primitive types, which default to
> > just calling the operator<< (>>) n times, but can be overridden
> > by optimized functions for those archive types where optimized
> > writes (load) are possi
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 19 Nov 2002 08:09:13 +0100 Matthias Troyer
([EMAIL PROTECTED]) wrote:
> The only solution which comes to my mind is additional virtual
> functions for writing blocks of primitive types, which default to
> just calling the operator<< (>>) n times, but can be
"Dirk Gerrits" <[EMAIL PROTECTED]> wrote in message
ar37hg$6hm$[EMAIL PROTECTED]">news:ar37hg$6hm$[EMAIL PROTECTED]...
> Thomas Matelich wrote:
>
> > Anyway, seemed like a nice package for general use. My company is
> > currently in love with XML, so I probably wouldn't be using it for our
> > com
Matthias Troyer wrote:
On Monday, November 18, 2002, at 02:30 PM, Yitzhak Sapir wrote:
I think taking out the pointer facility into a separate class would be
better design. By this I mean, that register_type<> and the logic for
identifying and maintaining pointers would be in a separate clas
And here promised attachments
Gennadiy.
serialization.rar
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 17 Nov 2002 19:08:14 -0800 Robert Ramey ([EMAIL PROTECTED]) wrote:
> From: [EMAIL PROTECTED] (Dave Harris)
>
> [snip]
> > ... but wouldn't produce very readable text files.
>
> readible text files are a minor convenience useful for debugging -
> nothing
On Tuesday, November 19, 2002, at 04:32 AM, Robert Ramey wrote:
Date: Mon, 18 Nov 2002 08:19:28 +0100
From: Matthias Troyer
overriding the very general template definiations above for this
special case would result in
template
inline boost::basic_iarchive & operator>>(boost::basic_iarchive &ar
Date: Mon, 18 Nov 2002 08:19:28 +0100
From: Matthias Troyer
>> overriding the very general template definiations above for this
>> special case would result in
>>
>> template
>> inline boost::basic_iarchive & operator>>(boost::basic_iarchive &ar,
>> double & x[]){
>> ar.read_binary(x, sizeof
On Monday, November 18, 2002, at 02:30 PM, Yitzhak Sapir wrote:
I think taking out the pointer facility into a separate class would be
better design. By this I mean, that register_type<> and the logic for
identifying and maintaining pointers would be in a separate class from
the archive. The
> From: "Jeff Garland" <[EMAIL PROTECTED]>
> >
> > Anyway, my conclusion is there is nothing preventing using
> > serialization for XML other than the time and energy to do
> > it.
>
> As I already said, my experience is that this theory sometimes proves wrong.
I understand. And I would like to s
It is not clear to me, but it seems like the deadline was extended. Dave Abrahams
asked Thomas, and he wrote back a simple message. It would have been nicer if there
was a general announcement to that end, in my opinion.
In any case, I have MSVC 6.5, and based on the discussions it seems that
From: "Jeff Garland" <[EMAIL PROTECTED]>
>
> Anyway, my conclusion is there is nothing preventing using
> serialization for XML other than the time and energy to do
> it.
As I already said, my experience is that this theory sometimes proves wrong.
I certainly know that I had to redesign my seriali
> The problem here is that the way you want to serialize a
> std::pair into XML might depend on the
> context. Sure, we can design an XML schema that is not context
> dependent, but most XML schemas are application specific and the way to
> serialize the data IS context sensitive.
The mapping
On Monday, November 18, 2002, at 01:04 PM, Jeff Garland wrote:
Let me give one example: we store parameters in a class
typedef std::map ParameterMap
...
If instead of typdef-ing ParameterMap as a std::map, I derive
ParameterMap from it then I can easily write a save and load function
to write
> Let me give one example: we store parameters in a class
>
> typedef std::map ParameterMap
>
> Actually the second template parameter is a more complex class, but for
> the sake of this example above is a valid simplification. I write that
> into XML as e.g.:
>
> ParameterMap m;
> m["L"]="10"
> If you need an apriori guarentee that this is extensible to XML
> in order to vote for the library then your decision is easy. I don't
I wasn't asking for this, I was asking for clarification. From the
tone of your previous mail it seemed like you had some insight about
the details of the des
On Monday, November 18, 2002, at 05:54 AM, Robert Ramey wrote:
From: "Jeff Garland" <[EMAIL PROTECTED]>
If there are technical reasons why the library cannot be extended to
do this than I would definitely vote to reject. It sounds like that's
what you and Robert are saying, but I don't unders
There seems to be a confusion regarding XML serialization.
An XML archive could easily be done by wrapping every output of a
primitive type in tags, e.g. int could be wrapped in 32434
, et.c. Thus XML output is no problem at all. Of course that's
not very useful. However the user can wrap all
From: Beman Dawes <[EMAIL PROTECTED]>
>Uh... I think one of us must be misunderstanding something about XML. If
>you can represent serialization of some objects as a character based file,
>can't you turn it into dumb XML by wrapping it in
>? Perhaps you mean you don't think it is
>possibl
From: "Jeff Garland" <[EMAIL PROTECTED]>
>If there are technical reasons why the library cannot be extended to
>do this than I would definitely vote to reject. It sounds like that's
>what you and Robert are saying, but I don't understand why you think
>this?
I have to admit I have only a cursory
From: [EMAIL PROTECTED] (Dave Harris)
[snip]
> ... but wouldn't produce very readable text files.
readible text files are a minor convenience useful for debugging - nothing more.
I needed a universal method for rendering/de-rendering all C++ fundemental
to a series of bytes. This method had to
At 12:51 PM 11/17/2002, Robert Ramey wrote:
>From: "Peter Dimov" <[EMAIL PROTECTED]>
>
>>> I'm really interested in the XDR format, not because I care about the
>>> format itself, but because others seem to use it as some sort of
litmus
>>> test for serialization libraries. Thus knowing that Robe
> We use both XML and binary XDR formats for serialization in our
> applications: XML for short files and for meta-information, files in
> XDR and/or HDF5 for large data sets. While I can imagine a
> serialization of a class into XML as part of a serialization library
> like the one proposed, I
We use both XML and binary XDR formats for serialization in our
applications: XML for short files and for meta-information, files in
XDR and/or HDF5 for large data sets. While I can imagine a
serialization of a class into XML as part of a serialization library
like the one proposed, I cannot ea
From: "Robert Ramey" <[EMAIL PROTECTED]>
> From: "Peter Dimov" <[EMAIL PROTECTED]>
>
> >FWIW, in my experience, XML is a better test for whether a serialization
> >library handles custom formats well. Sequence-based, header-only formats
are
> >very similar, but a reasonable XML serializer creates a
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 17 Nov 2002 10:44:33 -0800 Robert Ramey ([EMAIL PROTECTED]) wrote:
> they are arbitrary. but unimaginably high in my view.
I agree if we must have limits these are fairly reasonable. I don't see
the need for limits at all. It seems like premature optimisat
From: [EMAIL PROTECTED] (Dave Harris)
>>From the headers...
>>typedef unsigned char version_type; // upto 255 versions
>>namespace serialization_detail {
>>typedef unsigned short class_id_type; // upto 64k kinds
>>// of objects
>
> 1) I made orginally made archive_exception the simplest possible, it wasn't derived
> from std::exception and and contain an enum of every exception type. It suited
> my needs and I didn't feel that std::exception added anything.
Not for you, but for clients of the library that want a reasonabl
From: "Peter Dimov" <[EMAIL PROTECTED]>
>> I'm really interested in the XDR format, not because I care about the
>> format itself, but because others seem to use it as some sort of litmus
>> test for serialization libraries. Thus knowing that Robert's library
>> handles XDR well is of interest.
>
From: "Jeff Garland" <[EMAIL PROTECTED]>
On archive exception:
A short recap on the history of this:
1) I made orginally made archive_exception the simplest possible, it wasn't derived
from std::exception and and contain an enum of every exception type. It suited
my needs and I didn't feel that
From: "Jeff Garland" <[EMAIL PROTECTED]>
> > FWIW, I much prefer well-defined what() strings
("boost::pointer_conflict")
> > that I can use as keys into a message table over implementation-defined
> > descriptive messages.
>
> I don't I agree with this. While I have no issue with your desire
> to
> > I am going to much prefer something that gives me some sort of real
> > clue about the nature of the problem instead of the cryptic message
> > "pointer conflict"...
>
> Only if you can read English. Don't forget that. :-)
True...
> FWIW, I much prefer well-defined what() strings ("boost::p
From: "Jeff Garland" <[EMAIL PROTECTED]>
> > >Why not derive a different exception from archive_exception for each of
the
> > >enum types instead of using the enum? This would be better because if
a user
> > >creates a new archive type they might need to add an exception type
which is
> > >not cur
> >Why not derive a different exception from archive_exception for each of the
> >enum types instead of using the enum? This would be better because if a user
> >creates a new archive type they might need to add an exception type which is
> >not currently possible.
>
> Wouldn't it be better for t
> The program test.cpp tests every aspect of the library that I can think of. I have
>included
> all the tests in one program because it is convenient to for me to develop with.
Ok. It may be sufficient once it compiles :-( Sorry I didn't actually look
at it until now. At the very least a se
In-Reply-To: <[EMAIL PROTECTED]>
On Sat, 16 Nov 2002 22:50:23 -0800 Robert Ramey ([EMAIL PROTECTED]) wrote:
> A default constructor is not required. The reference section
> "Serialization Overrides" explains this and gives a code excerpt
> showing what one has to do to use a constructor with argu
From: "Jeff Garland" <[EMAIL PROTECTED]>
>From my perspective the following changes must are must-haves:
>1) The library must have a 'real' test suite that checks. We will never get this
> ported without some automated tests. Further, it is simply too much to ask users
> to use this library w
I am having hard time finding free time lately. So I wouls also ask for
couple more days.
Gennadiy.
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Jeff Garland" <[EMAIL PROTECTED]> writes:
>
> ...
>
> > And, also a request that we try to sch
> Requiring a default constructor is a mistake. For one thing there are
often reasons not to provide a default constructor. For
> another, when serializing we might want different behavior. Provide a
factory method instead.
>
> Question, do classes without default constructors must be serializab
Thomas Matelich wrote:
Anyway, seemed like a nice package for general use. My company is
currently in love with XML, so I probably wouldn't be using it for our
commercial products.
Maybe you missed it due to only skimming the documentation, but it is
possible to write your own archive types
Disclaimer: I haven't read any other reviews or much of the discussion of
this library so I can't say if my issues have already been covered.
Serialization Review
I haven't participated in any reviews for a long time, so I thought I'd
tackle this one. Conveniently, I had a little tool that was
Robert Ramey wrote:
Alberto Barbati wrote
Please note that the "registry" class I described *does not* attempt to
solve the broader issue of UUIDs I read about in the discussion between
you and Vladimir. My proposal is just a way to separate the
"registration" part from the "serialization" int
Alberto Barbati wrote
>>>2) A most needed addition to the design is to provide a sort of
>> "registry" object.
>>
>> This has been a hot topic. It is really not possible to achieve the
>> desired results. I will add a section to th rationale explaining this
>> in detail,
>Please no
> 1) I don't like the non-intrusive way of specifying the
> version/save/load operation. The rationale for having the
> serialization<> template in the global namespace is quite weak. The
> alternative of using free functions is much better IMO. The library
> should use unqualified calls to tho
> 1) I don't like the non-intrusive way of specifying the
> version/save/load operation. The rationale for having the
> serialization<> template in the global namespace is quite weak. The
> alternative of using free functions is much better IMO. The library
> should use unqualified calls to tho
Robert Ramey wrote:
From: Alberto Barbati <[EMAIL PROTECTED]>
1) I don't like the non-intrusive way of specifying the
version/save/load operation.
a non-intrusive method is required to implement serialization for classes that
you don't want to change. For example, the library includes serializat
Robert Ramey wrote:
From: Alberto Barbati <[EMAIL PROTECTED]>
Hi David,
1) I don't like the non-intrusive way of specifying the
version/save/load operation.
a non-intrusive method is required to implement serialization for classes that
you don't want to change. For example, the library inc
>From: Alberto Barbati <[EMAIL PROTECTED]>
>Hi David,
>1) I don't like the non-intrusive way of specifying the
>version/save/load operation.
a non-intrusive method is required to implement serialization for classes that
you don't want to change. For example, the library includes serialization
f
Hi David,
- What is your evaluation of the design?
I like the design very much. It's neat and far superior to other
alternatives I evaluated in the same problem domain. I have just a few
observations:
1) I don't like the non-intrusive way of specifying the
version/save/load operation. The rat
65 matches
Mail list logo
