Re: [boost] Serialization Draft Submission # 3 - Final Draft

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-05-19 01:01:09

At Saturday 2002/05/18 15:27, you wrote:
>Good day,
>
>I have a few comments regarding the serialization
>library documents:
[deleted]
>Also I believe there is more to portability of text
>archives than support for a particular character set
>(especially when it comes to wide characters). Two
>"platforms" might very well support Unicode but use
>different representation of characters.

Then it's not Unicode, but some OTHER "wide character" system.   There may 
indeed be other problems, but that isn't one of them.

>Also I think the use of term "platform" is not
>appropriate in the context it is used. I think what
>you mean is not *platform*, but an "implementation of
>ISO C++ requirements". A platform in the usual sense
>(a combination of hardware and system software) might
>support more than one implementation of C++, such that
>certain details differ between implementations (e.g.,
>sizes of types or alignment of objects).
>
>Come to think of it, the issue of data transfers
>between different implementations deserves more
>consideration. The serialization library relies on an
>external entity ("storage medium") for its correct
>operation, therefore there should be a set of
>requirements to the storage medium. For example,
>consider the following program:
>
>ifstream ifs( "filename" );
>ifs.put( 'a' );
>ifs.close();
>
>ofstream ofs( "filename" );
>int x = ofs.get();
>assert( x == 'a' );

ummm, you're going to have difficulty getting that to compile.  one 
generally writes to ofstreams and reads from ifstreams.

>Ignoring the error checking, is the last assertion
>guaranteed to hold? The answer is obviously "no"
>because the ISO C++ definition of a file is very
>loose. The contents of the file could be changed by an
>external process. Or it could be a UNIX FIFO that does
>not produce the same data as it consumes.
>
>Another problem is the representation of types on
>different implementations. If sizeof(char) in program
>"A" is different from sizeof(char) in program "B" what
>happens when proram "A" tries to read a *text* archive
>written by program "B"?
>
>In all fairness we can't claim that text archives are
>portable without specifying additional requirements
>with respect to the above issues.
>
>I'd like to point out that we will face similar issues
>with any library that has to do with interprocess
>communications, in particular the much-talked-about
>networking library. IMHO it would be very desirable to
>have these issues addressed w.r.t. the current ISO C++
>execution, memory requirements and such.
>
>Anyhow, going back to serialization:
>
>- how exactly does one implement serialization not
>based on streams?
>
>- there are typos :)

pot, kettle............

>- The "Overview" section contains the following set of
>sub-headings:
>
>** Archive Operators **
><text>
>** For Primitive Types **
><text>
>** For Classes **
><text>
>....
>
>Headings that start with "For" in the middle of text
>left me buffled there for a while. Perhaps you should
>repeat the word "Operators" in each such phrase (e.g.,
>"Operators for Classes" vs just "For Classes").
>
>I'll try to read the design more carefully in the next
>few days and might come back with more comments.
>
>Regards,
>D.P.
>
>
>
>______________________________________________________________________
>Find, Connect, Date! http://personals.yahoo.ca
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"