Re: [boost] [Review] of binary_int utility starts

From: Scott Schurr (scott_schurr_at_[hidden])
Date: 2005-10-18 12:30:22

Reece Dunn wrote:
> Scott Schurr wrote:
> > I'm going to wait until after the review period to start on fixing 
> > the 64-bit support.  Since I don't have a local 64-bit compiler
> > I'll be working blind and my first few efforts will be dead wrong.
> 
> The 32-bit microsoft compiler has support for 64-bit literals if you 
> have version 7.0 or above handy (6.0 might have this, but I haven't 
> checked). You will need to enable language extensions. I am not sure 
> about the other compilers, though.
> 
> It should be possible to test the 64-bit stuff on a 32-bit compiler like 
> VC7 with MS language extensions, or even GCC.
> 
> You may get warnings when converting a 64-bit type to a 32-bit type, or 
> even a 32-bit type to a 16-bit type. However, the solution for this is:

Thanks for the suggestion Reece.  I thrashed about some this
morning turning on extensions.  I'm now able to reproduce the problem
that Markus Sch?pflin found:

Markus Sch?pflin wrote:
> For the next test, I changed struct test_values (in binary_int_test.cpp) to 
> the following:
> 
>      struct test_values {
>          uint64_t hex_value;
>          uint64_t bin_value;
>      };
> 
> This additionally needs #include <boost/cstdint.hpp>.
> 
> When compiling and running this (on both 32 bit and 64 bit systems), I got 
> the following error:
> 
> At test_array index 40 8a6c4e20 != ffffffff8a6c4e20
> assertion "test_array[i].hex_value == test_array[i].bin_value" failed: file 
> "../binary_int_test.cpp", line 118

And I found that...

Scott Schurr wrote prematurely:
> > At an initial glance it looks like 64-bit support should be 
> > achievable without heroic efforts.  But it certainly won't come
> > along for free.

I'm using the Microsoft 32-bit Compiler, Version 13.00.9466, and
I'm running into two different problems with 64 bit values:

 1. So far I've been unable to make Marcus's problem go away.  With
    32-bit values I was able to fix this up by forcing the underlying
    type that I write to my enums.  When I try this same fix in 
    64-bits nothing gets better.

 2. The worse problem is that binary value values larger than 32 bits
    (8 nibbles) get their upper nibbles truncated.

After a couple of tests it appears that, for this compiler, the 
largest supported enum value must fit in 32 bits.  If that's correct,
then my enum based calculations run out of steam on this compiler
at 32 bits.

Hmmph.

Matt Calabrese's macro-based approach is looking more appealing,
at least as far as 64-bit support goes.

Scott Schurr