From: "Gennadiy Rozental" <[EMAIL PROTECTED]>
I am still considering aspects of your review. I have a questions about
a couple of comments:
>Major [Issue 2]: I believe it design error to couple both sides of
>serialization together in one library. It should be separated . So that user
>should be
Matthias Troyer
> Sent: 26 November 2002 09:47
> To: Boost mailing list
> Subject: Re: [boost] Serialization library review
>
> I was referring to one virtual function call for EVERY element in a
> large vector as opposed to only one virtual function call for the
whole
> vector.
I was referring to one virtual function call for EVERY element in a
large vector as opposed to only one virtual function call for the whole
vector.
Matthias
On Tuesday, November 26, 2002, at 09:39 AM, Keith Burton wrote:
For the ignorant like me , would you care to explain under what
circumsta
For the ignorant like me , would you care to explain under what
circumstances this is true.
I can see the case that a one off virtual function call is much slower
because the called code needs to loaded into ( cache ) memory but I
assume you are referring to more than this.
> -Original Messag
On Tuesday, November 26, 2002, at 03:01 AM, Robert Ramey wrote:
Date: Mon, 25 Nov 2002 10:41:17 +0100
From: Matthias Troyer <[EMAIL PROTECTED]>
I guess this should be changed to:
#ifdef BOOST_HAS_MS_INT64
virtual basic_iarchive & operator>>(int64_t & _Val) = 0;
virtual basic_iarchive & oper
Date: Mon, 25 Nov 2002 11:08:32 +0300
>Frankly speaking, I have one concern. We (you and I) seem to
>have problems understanding each other. Therefore, if I
>implement something after the library is accepted, it
>may be hard to convince you to adopt the change. I may be
>mistaken, but this is how
Date: Mon, 25 Nov 2002 10:41:17 +0100
From: Matthias Troyer <[EMAIL PROTECTED]>
>> I guess this should be changed to:
>> #ifdef BOOST_HAS_MS_INT64
>> virtual basic_iarchive & operator>>(int64_t & _Val) = 0;
>> virtual basic_iarchive & operator>>(uint64_t & _Val) = 0;
>> #endif
Date: 25 Nov 2002 00:03:08 -0500
From: Jeremy Maitin-Shepard <[EMAIL PROTECTED]>
>> Hmmm - what I don't understand is how this would be different that calling
>>
>> void basic_oarchive::write_array(void* p, size_t count)
>>
>> Incidently, this would work for any kind of archive - not just the
>>
The review of Robert Ramey's Serialzation library is now over. Thanks
to Robert for his library submission (and his indulgence), and thanks
to everyone who reviewed it! Because of the thanksgiving holiday I may
not be able to render a verdict and summary this week. Please stay
tuned...
-Dave
--
>>code fragments such as:
>>line 95-96 of archive.cpp seem unacceptable to me:
>>
>>// note breaking a rule here - is this a problem on some platform
>>is.read(const_cast(s.data()), size);
>
>Although is non standard I believe that the above code will work on all
known platforms.
>It yields an imp
* A serialization of bool is missing - easy to fix
I don't understand what you mean. basic_[i|o]archive contain:
Sorry, I missed that because it is separate from the other virtual
functions and not implemented in the b[io]archive class on which I
based my XDR implementation.
* The code wil
On Monday, November 25, 2002, at 05:22 AM, Robert Ramey wrote:
Date: Sun, 24 Nov 2002 20:39:03 +0100
From: Matthias Troyer <[EMAIL PROTECTED]>
you seem to have misunderstood that: a function
void basic_oarchive::write_array(double* p, std::size_t n)
will work for ALL contiguous data: C-a
Robert Ramey wrote:
b) Some posts suggested alterations in libary interface to
permit a specific usage of the library. These were of the character
as "required to implement bracketing for XML" etc. My view
is that it dangerous to alter the library interface to
accomodate speculation about futur
Robert,
posts where the quoted text you are replying to is only /sometimes/
preceded with '>' are very hard to follow, and make the job of review
manager very difficult, since it becomes impossible to analyze the
discussion. Would you mind re-posting this with consistent quoting?
Robert Ramey <[
Date: Sun, 24 Nov 2002 16:28:50 +0100
From: Matthias Troyer <[EMAIL PROTECTED]>
3. Does not work on all platforms - solvable problem
4. Interface design: there are some show-stoppers here for now
a) primitive types: code is not portable at the moment
b) performance: need improved methods f
On Sun, 2002-11-24 at 23:22, Robert Ramey wrote:
> Hmmm - what I don't understand is how this would be different that calling
>
> void basic_oarchive::write_array(void* p, size_t count)
>
> Incidently, this would work for any kind of archive - not just the
> binary ones.
But then the serialized
Date: Sun, 24 Nov 2002 20:39:03 +0100
From: Matthias Troyer <[EMAIL PROTECTED]>
>you seem to have misunderstood that: a function
>void basic_oarchive::write_array(double* p, std::size_t n)
>will work for ALL contiguous data: C-arrays, std::vector, ublas and MTL
>arrays, and so on
Hmmm - what I
In-Reply-To: <[EMAIL PROTECTED]>
I have considerable experience with Microsoft's MFC archive library, which
I have found to be deeply flawed. My main concern is that boost not repeat
those mistakes. I have reviewed Robert Ramey's current submission with
that in mind. I have not much looked at th
On Sunday, November 24, 2002, at 06:40 PM, Robert Ramey wrote:
5.5 "Superfast I/O"
There have been requests to add more primitive virtual functions to
basic_[i|o]archive in order to permit increased efficiency.
Specifically,
the idea is to add for each primitive type a virtual function to per
After spending more time with the serialization library, implementing
an archive
for the XDR format and considering how I could read my old archive
files using this
library instead of my own one, I can now give a more detailed review of
the
serialization library. I will keep those parts that
Robert --
A few thoughts...
> Well, I havnt actually counted up the votes but
> the concensus seems pretty clear that it shouldn't
> be accepted into boost as is.
Yes, but it isn't consensus that matters. In fact,
the whole decision rests with Dave. He takes into
account all of the informatio
Fellow Boosters:
Serialization Discussion Summary
Well, I havnt actually counted up the votes but
the concensus seems pretty clear that it shouldn't
be accepted into boost as is.
Of course I'm disappointed.
Now the question becomes whether its possible to
make changes such that it would be acce
From: "Gennadiy Rozental" <[EMAIL PROTECTED]>
Its clear you spend a lot of time on this. Your attention to end perception of
detail is extraordinary. Also your critisms are phrased in a way that
proposes and contrasts the alternative - a very useful feature.
So many of these I have no problem w
On Wednesday, November 20, 2002, at 01:42 PM, Gennadiy Rozental wrote:
[Issue 3] Library seems to hardcode important part of functionality
that
users may want to overwrite. Here I refer in most part to
archive/object
preamble.
Major [Issue 3]: Submitted library is somewhat limited in a means
Hi,
After spending some time with library, looking through docs and code,
compiling it and comparing with my expectations I see following 5 major
issues with submitted library:
[Issue 1] Registration/reflection facility should be completely separated
from serialization implementation and became r
I have another minor comment:
There are certain unclean code segements, like the following loading of
a string:
// note breaking a rule here - is could be a problem on some
platform
read_binary(const_cast(s.data()), size);
I expect that these to will cleaned up before a final submissi
At 10:46 PM 11/17/2002, Robert Ramey wrote:
>I will be very curious to see timings on this. There is no apriori
reason
>to know that the translation from native types <-> XDR is faster than
>native types <-> text
I did a detailed timing study some years ago. Binary was four times faster
round
Hi Boosters,
I sorry I haven't followed this thread, so maybe you have already discussed
this issue.
Perhaps its even explained in the documentation?.
Anyway,
I just looked through some of the test code in the serialization library.
Much of the classes used 'XX.close()' inside catch-clauses. What
Thomas Witt <[EMAIL PROTECTED]> writes:
> On Sunday 17 November 2002 15:04, David Abrahams wrote:
>> > Could we extend it by one week so that we have another weekend?
>>
>> Thomas Witt is the Boost Review Wizard. It's up to him. Thomas?
>
> Fine with me.
OK, the Serialization Review is extended t
On Monday, November 18, 2002, at 04:46 AM, Robert Ramey wrote:
From: Matthias Troyer <[EMAIL PROTECTED]>
I believe we all agree that portable binary archive formats are
essential in addition to the text based one.
I will be very curious to see timings on this. There is no apriori
reason to
From: Matthias Troyer <[EMAIL PROTECTED]>
>I believe we all agree that portable binary archive formats are
>essential in addition to the text based one.
I will be very curious to see timings on this. There is no apriori reason to know
that the translation from native types <-> XDR is faster tha
On Sunday, November 17, 2002, at 07:08 PM, Robert Ramey wrote:
Date: Sun, 17 Nov 2002 10:19:23 +0100
From: Matthias Troyer <[EMAIL PROTECTED]>
It is mentioned in several places in the code, docs and in this list
that the native binary archive derivations have absolutly no
pretentensions to porta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 17 November 2002 15:04, David Abrahams wrote:
> > Could we extend it by one week so that we have another weekend?
>
> Thomas Witt is the Boost Review Wizard. It's up to him. Thomas?
Fine with me.
>
> [BTW, Thomas, can we put your name and a
Date: Sun, 17 Nov 2002 10:19:23 +0100
From: Matthias Troyer <[EMAIL PROTECTED]>
>> From: Matthias Troyer <[EMAIL PROTECTED]>
>
>> Suppose you have a number on the first platform that exceeds 32
>> significant bits. What happens when the number is loaded onto
>> the second platform. Are the high o
From: "Beman Dawes" <[EMAIL PROTECTED]>
> At 04:08 AM 11/17/2002, Matthias Troyer wrote:
> >
> >On Sunday, November 17, 2002, at 05:43 AM, David Abrahams wrote:
> >>
> >> Does anybody else feel they need more time to give this library a
> >> thorough going-over? I think we could afford to exte
At 04:08 AM 11/17/2002, Matthias Troyer wrote:
>
>On Sunday, November 17, 2002, at 05:43 AM, David Abrahams wrote:
>>
>> Does anybody else feel they need more time to give this library a
>> thorough going-over? I think we could afford to extend the review for
>> a few more days. I would especially
In-Reply-To: <[EMAIL PROTECTED]>
On Sat, 16 Nov 2002 23:43:31 -0500 David Abrahams
([EMAIL PROTECTED]) wrote:
> Does anybody else feel they need more time to give this library a
> thorough going-over?
If no more time is available, I'd have to vote against including the
library in its current for
Matthias Troyer <[EMAIL PROTECTED]> writes:
> On Sunday, November 17, 2002, at 05:43 AM, David Abrahams wrote:
>>
>> Does anybody else feel they need more time to give this library a
>> thorough going-over? I think we could afford to extend the review for
>> a few more days. I would especially be
On Sunday, November 17, 2002, at 05:43 AM, David Abrahams wrote:
Does anybody else feel they need more time to give this library a
thorough going-over? I think we could afford to extend the review for
a few more days. I would especially be willing to do so if it would
allow for enough discussion
"Jeff Garland" <[EMAIL PROTECTED]> writes:
...
> And, also a request that we try to schedule more time for library
> reviews -- 9 days just isn't enough given that this has to be fit in
> with everything else.
>
> I'm going to abstain on voting for or against inclusion because I'm
> impossibly c
I have spent several hours looking at the library. In that time I read the docs,
skimmed the implementation, tried compiling the
tests, and wrote a simple sample program. I have written more than one serialization
library, so I am pretty familiar with the
domain. Unfortunately, I didn't have m
David Abrahams wrote:
Here's a reminder of what to include in your review comments:
Here are some questions you might want to answer in your review:
What is your evaluation of the design?
First comes my opinion on library scope. The biggest features that it
adds (compared with older '
On Mon, Nov 11, 2002 at 09:07:40AM -0500, David Abrahams wrote:
>In this system, we use term "serialization" to mean a system where
>the current state of group of objects can be stored to a permanent
>medium that may outlast the current program execution. At any later
>time an equiv
This is a belated announcement that the review period of Robert
Ramey's Serialization Library, which runs from 9 November to 18
November, has started.
Here is an introductory paragraph describing the library, from its
documentation.
In this system, we use term "serialization" to mean a system
44 matches
Mail list logo
