headers
David Abrahams | 1 Mar 2002 01:01
Favicon
Gravatar

Re: Building boost.

BTW, most of the tests are not supposed to be run in release mode because
assert() gets turned off. Some even forcibly error if you compile them that
way, so that will make your error count higher.

----- Original Message -----
From: "Rene Rivera" <grafik666 <at> redshift-software.com>
To: <boost <at> yahoogroups.com>
Sent: Thursday, February 28, 2002 6:45 PM
Subject: Re: [boost] Building boost.

> On 2002-02-28 at 02:01 PM, kevin.vanhorn <at> ndsu.nodak.edu (Kevin S. Van
Horn)
> wrote:
>
> >According to the compiler status tables, Boost passes all tests on gcc
> >gcc 3.0.3.  This has me a bit perplexed, as I just tried to build Boost
> >with gcc 3.0.4 (I know, not exactly the same, but close), and got quite a
> >large number of errors -- Jam reports that it failed to update 79 targets
> >and skipped 40 targets.  I used
> >
> >  jam -sBOOST_ROOT=. -sTOOLS=gcc -sBUILD="debug release"
> >
> >The only thing I can think of is that perhaps it was getting the wrong
> >compiler (gcc 3.0.4 is installed in /opt/bin), although 'which g++'
> >verifies that the correct compiler is the first one in the my search
path.
> >Does anyone have any suggestions as to what might be wrong?  How can I
> >make sure that Jam uses the compiler I want it to use?
>
> A bit more detail would be cool...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rainer Deyke | 1 Mar 2002 01:11

Re: Re: Serialization (Persistence) library draft submission

----- Original Message -----
From: "rameysb" <ramey <at> rrsd.com>
To: <boost <at> yahoogroups.com>
Sent: Thursday, February 28, 2002 4:05 PM
Subject: [boost] Re: Serialization (Persistence) library draft
submission

> The issue that has concerned me is what happens when an archive
> is created on a machine with 80 bit IEEE floating point doubles and
> this archive is read by a program using the same serialization
> library on a machine which has 64 bit doubles.  if the second
program
> reads 80 bits is it going to have to include code to convert from
> every known binary double format to every other one?  The same
> issues occur on sizes of other binaries 16 vs 32 vs 64.  The same
> issue arises when considering that some machines store integers
> in little endien order (intel) while others store them
> in big endien order (sparc).  I doubt anyone will want to
> consider all these issues.

It is only necessary to support one standard format with conversions
to/from native.  In my personal serialization code I use 32 bit
integers (and 32 bit long, 16 bit short, 8 bit char), big endian, 2s
complement, and no floating point.  My reasoning is as follows:

  - Most of the platforms I use have 32 bit integers, so I chose to
support that.  On platforms with more bits per integer, the high bits
are dropped during serialization.  This is not necessarily a bad
thing, since integers with >32 bits cannot be portably read on 32 bit
platforms.  On platforms with less than 32 bits per integer, the high
(Continue reading)

Permalink | Reply | 6 comments |
headers
boost | 1 Mar 2002 01:53
Picon

New file uploaded to boost


Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the boost 
group.

  File        : /iostate.zip 
  Uploaded by : dwalker07 <darylew <at> mac.com> 
  Description : Version 4 (FC1); IOStream state saver classes 

You can access this file at the URL

http://groups.yahoo.com/group/boost/files/iostate.zip 

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

dwalker07 <darylew <at> mac.com>
Permalink | Reply | 0 comments |
headers
Damien Fisher | 1 Mar 2002 02:18
Picon
Picon
Favicon

Re: Re: Serialization (Persistence) library draft submission

On Thu, 28 Feb 2002, Rainer Deyke wrote:

> ----- Original Message -----
> From: "rameysb" <ramey <at> rrsd.com>
> To: <boost <at> yahoogroups.com>
> Sent: Thursday, February 28, 2002 4:05 PM
> Subject: [boost] Re: Serialization (Persistence) library draft
> submission
> 
> 
> > The issue that has concerned me is what happens when an archive
> > is created on a machine with 80 bit IEEE floating point doubles and
> > this archive is read by a program using the same serialization
> > library on a machine which has 64 bit doubles.  if the second
> program
> > reads 80 bits is it going to have to include code to convert from
> > every known binary double format to every other one?  The same
> > issues occur on sizes of other binaries 16 vs 32 vs 64.  The same
> > issue arises when considering that some machines store integers
> > in little endien order (intel) while others store them
> > in big endien order (sparc).  I doubt anyone will want to
> > consider all these issues.
> 
> It is only necessary to support one standard format with conversions
> to/from native.  In my personal serialization code I use 32 bit
> integers (and 32 bit long, 16 bit short, 8 bit char), big endian, 2s
> complement, and no floating point.  My reasoning is as follows:

It strikes me that this is a problem with serialization to text-based
files anyway.  I mean, if you serialize a 64-bit integer to a file and
(Continue reading)

Permalink | Reply | 4 comments |
headers
Noah Stein | 1 Mar 2002 02:27

RE: Re: Serialization (Persistence) library draft submission

> -----Original Message-----
> From: Damien Fisher [mailto:damien <at> maths.usyd.edu.au]
> Sent: Thursday, February 28, 2002 5:18 PM
> To: boost <at> yahoogroups.com
> Subject: Re: [boost] Re: Serialization (Persistence) library draft
> submission
>
>
> It strikes me that this is a problem with serialization to text-based
> files anyway.  I mean, if you serialize a 64-bit integer to a file and
> then deserialize it on a 32-bit platform with no "long long" or "__int64",
> what are you going to do?  So the issue is the same regardless of whether
> we are talking about text or binary, IMHO.

My personal feeling is that serializing back a 64-bit integer on a different
platform that does not support a 64-bit integer is really a non-issue.  If
the data type is not supported, what does it matter that you can't serialize
it back?  If you think you can work around not being able to get data out,
why was it saved in the first place?  And if you need a 64-bit integer on a
platform that doesn't have one, implement one, then you can serlialize it
back.

-- Noah
Permalink | Reply | 3 comments |
headers
rameysb | 1 Mar 2002 04:29

Re: Serialization (Persistence) library draft submission

--- In boost <at> y..., "Noah Stein" <noah <at> v...> wrote:

> > It strikes me that this is a problem with serialization to text-
based
> > files anyway.  I mean, if you serialize a 64-bit integer to a 
file and
> > then deserialize it on a 32-bit platform with no "long long" 
or "__int64",
> > what are you going to do?  So the issue is the same regardless of 
whether
> > we are talking about text or binary, IMHO.
> 
> My personal feeling is that serializing back a 64-bit integer on a 
different
> platform that does not support a 64-bit integer is really a non-
issue.  If
> the data type is not supported, what does it matter that you can't 
serialize
> it back?  If you think you can work around not being able to get 
data out,
> why was it saved in the first place?  And if you need a 64-bit 
integer on a
> platform that doesn't have one, implement one, then you can 
serlialize it
> back.
> 
> 
> -- Noah

Suppose I write a Computer Aided design package.  I have points,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Damien Fisher | 1 Mar 2002 04:54
Picon
Picon
Favicon

Re: Re: Serialization (Persistence) library draft submission

On Fri, 1 Mar 2002, rameysb wrote:

> Suppose I write a Computer Aided design package.  I have points, 
> lines in 3D scaling factors and who knows what else.  To save
> and restore a CAD drawing a use a serialization package.  Now
> I port the program to another machine.  I want to be able to
> transfer CAD drawing between machines. In my view if I can't do
> that without writing extra code the whole purpose of using such
> a library is defeated.
> 
> Suppose the two machine have different floating point formats and
> precisions. Machine A uses 80 bits of precision while B uses 64
> bits.  I create a CAD drawing on machine A, serialize (text) to a 
> file, move the file to machine B, run the ported version of the 
> program, deserializee the file and start drawing.
> 
> What has happened here?  Well I lost the 16 least significant bits of 
> precision so the new drawing is slightly in accurate compared to the 
> first.   But wait who is to say the first program was truely accurate 
> to 80 bits in the first place.  Floating point numbers are always 
> approximations of some physical measurement or constant.  What we 
> have done is to convert the CAD drawing from the most suitable 
> representation on machine A to the most suitable representation on 
> machine B.
> 
> So we havn't really transfered the exact object from one machine to 
> another, which is impossible for this example.  

I don't understand what you mean.  It seems to be that it is possible to
transmit an exact version, up to the loss of precision due to the 64 bit
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daryle Walker | 1 Mar 2002 04:56
Picon

No config workarounds?

Is there a way to disable all the workaround macros in <boost/config.hpp>,
in case an user wants to test how Boost reacts with their compiler without
the workaround macros secretly hiding problems?

--

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
Permalink | Reply | 1 comment |
headers
Douglas Gregor | 1 Mar 2002 05:25
Picon
Favicon

Re: Re: New version of valunion and stack_allocator uploaded

On Thursday 28 February 2002 05:27 pm, you wrote:
> > I did something like that at one point, and it was painful to compiler. I
> > like Brian Parker's version because it is so much simpler than any
> > typelist-based approach.
>
> Can you give the quick one-sentence summary of what he's doing?

The type to align against is a union, where the type 'X' of each member is a 
type 'U' if sizeof(U) <= sizeof(type_we_want_to_make_storage_for) and char 
otherwise.

	Doug
Permalink | Reply | 14 comments |
headers
dylan_nicholson | 1 Mar 2002 06:17
Picon

Re: Serialization (Persistence) library draft submission

--- In boost <at> y..., "rameysb" <ramey <at> r...> wrote:

> Portability and utility demands the numbers be in some sort of 
> canonical form.  I chose text rendition numbers as that canical 
form.
> 
> Why did I choose this one?  Well its the first that came to mind 
but 
> there is a real reason.  This permits us to leverage on the 
> float/text conversion functions already programmed for streams in 
the 
> standard library. What is the point of writing our own?  Are they 
> going to be better than the ones in the standard library? are they 
> going to be faster? use much less space? more robust? I doubt it. 
> 
Actually speed is a really big issue.  We attempted using an LZ 
compressed ASCII format for what are coincidentally enough 
essentially CAD models, and determined that the sheer time it took to 
parse all the ascii representations of floating point numbers was 
unacceptable (the compression time was less significant, but only 
made matters worse.  And the size of the ASCII files made compression 
necessary).  Hence we changed to an in-house binary format (I would 
have preferred XDR, which is what we use elsewhere, but so be it), 
and reduced load and save times by a factor of 10.

Basically what it comes down to it that any serialization that 
doesn't allow you to override how low-level data types are serialized 
is fairly useless.  I suggested elsewhere that the stream class 
itself should be templatized - I have written a binary_stream (it's 
in the boost files section) that is completely compatiable with
(Continue reading)

Permalink | Reply | 0 comments |

Gmane