Boost logo

Boost :

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-09-12 19:37:57


> Text is generally more
>bloated than binary, so there is no need to write something that is based
on
>binary serialization to text.

I hadn't realized anyone had suggested this.

> The entire idea of being able to
>polymorphically switch between the two is senseless.

nor this.

===> Well that appears to be the only premise behind the basic_iarchive and
basic_oarchive in the serialization library with it's text and binary
specializations.

----- Original Message -----
From: Victor A. Wagner, Jr.
Newsgroups: gmane.comp.lib.boost.devel
Sent: Thursday, 2002:September:12 20:24
Subject: Re: Re: Re: Re: Serialization library - submission #5 and request

Are you sure you replied to the correct message?
At Thursday 2002/09/12 14:12, you wrote:
>void* shouldn't be in the language.

we disagree (and for a _real_ change of pace, the standards committee
apparently agrees with me).

>At any rate, I don't see any usefulness in a library that can arbitrary
>switch from writing in binary to writing in text.

I'm unclear on what you're trying to say here.

> Text is generally more
>bloated than binary, so there is no need to write something that is based
on
>binary serialization to text.

I hadn't realized anyone had suggested this.

> The entire idea of being able to
>polymorphically switch between the two is senseless.

nor this.

>----- Original Message -----
>From: Victor A. Wagner, Jr.
>Newsgroups: gmane.comp.lib.boost.devel
>Sent: Thursday, 2002:September:12 16:54
>Subject: Re: Re: Re: Serialization library - submission #5 and request
>
>
>At Thursday 2002/09/12 13:19, you wrote:
> >Here are my two cents on the serialization library:
> >
> >I haven't looked through it that much, just this message thread actually,
> >but I plan on looking through what it supports further. (I'm still
looking
> >for the link to where I can download it and check it out)
> >
> >1) I disagree with the use of the << operator. iostreams already have
> >claimed this operator and they mean a very specific usage: they imply
> >formating, which includes removal of whitespace etc. This is a very
> >different function of writing something out in binary.
>
>my US$0.02:
>They do NOT imply any formatting other than that appropriate to the stream.
>I have a perfectly useful "bfstream" for handling temporary files (no
>worries about alignment, endian, whatever because it's intended solely for
>files that are written then read in the same execution instance). It uses
><< and >> and nobody who uses it has ever complained, nor had any
>difficulty with the concept.
><nit> << doesn't do ANY whitespace removal that I'm aware of.... >>
>does </nit>
>
> >2) void pointers are bad practice,
>
>as a general guideline, yes. There are exceptions (else why would void*
>even be in the language??) and this very well may be one of them. That
>we're still saddled with the "char*" junk from when the C folks hadn't
>really thought things through is unfortunate.
>
> >and in one of the usages I saw below,
> >completely unnecessary. C++ provides templates, so use them.
>
>Why suffer from the code bloat? No compiler I'm aware of looks at the
>actual generated code, and collapses two template instantiations into one
>piece of code.
>
> > The idea of
> >translating a type to a byte array should always require a reinterpret
>cast:
> >
> >template <typename Object>
> >void write_binary (Object const* const object) {
> > /// do stuff reinterpret_cast and const_cast if necessary get a char
> >const* const
> >}
> >
> >You should never just ignore type information, no matter what the
purpose.
> >[deleted]

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"

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk