[boost] Re: Boost Integer Library

From: Beman Dawes (beman_at_[hidden])
Date: 1999-08-20 12:36:31

At 11:11 PM 8/18/99 +0200, Jens Maurer wrote:

>A few general comments on bin_ubin.hpp:
>
>This is intended to be a representation for portable integers.
>However, there is no way to access the portable representation.

Interesting point.  Although what would be returned by such access? A
void* or const void* perhaps?  What would that achieve beyond just
taking the address of the struct and then casting it to whatever was
needed?

>I could use memcpy(), but this is ugly and not portable,
>because the layout of struct members in general is not
>defined.

Users of these classes are warned that they offer no ironclad
guarantee of portability.  But 15 years of experience with
predecessors of these classes and similar C structs tell us that they
are very portable in practice.  Compilers don't lightly break
compatibility with operating system structs which must remain
compatible with assembler and machine language layouts.  I know
depending on behavior that is not strictly portable is risky, but the
benefits of these classes outweigh the risk, at least until a counter
example surfaces!

>  I therefore suggest member functions
>	void write(ostream &);
>and
>	void read(istream &);
>and probably a constructor
>	binXX(istream &);

The actual uses I have seen almost always read/write structs
containing bin/ubin(s) (and usually other data), rather than plain
bin/ubin's.  And all sorts of I/O, not just std:: streams, gets used.

>Member variable identifiers start with an underscore, although
>these identifiers are reserved for the C++ implementation.

What the standard actually says in 17.4.3.1.2 is:

Certain sets of names and function signatures are always reserved to
the implementation:

— Each name that contains a double underscore (_ _) or begins with an
underscore followed by an upper-case letter (2.11) is reserved to the
implementation for any use.

— Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace. (A footnote
points out this includes namespace std.)

So it is OK to use a single leading underscores followed by a
lower-case letter in namespace boost.

>In general, I wonder why there are separate classes binXX
>instead of (specializations of)
>	template<int n> class bin { ... };

Historically, these classes existed long before templates. I thought
of converting them to a generic programming approach, but didn't see
any advantage to it. A separate chooser is possible if ever needed.

>This would even allow for a generic implementation using
>a C-array instead of separate char member variables.

An older implementation used arrays, but required special code to
handle extension of the sign bit (for bin's).

>And the C-array solves all troubles with struct layout,
>because (I think) C-arrays are supposed to have a compact
>memory layout.  If we don't trust the compiler, we can
>unroll the resulting loop with template techniques.

I don't want to spend that much effort on these low-level components.
 I need them to build the higher-level stuff I care about.  Every
compiler (and even the next release of the same compiler) seems to
optimize these differently, so I don't want to try for some
optimization which will have to be redone and redone.

>Beman Dawes wrote:
>> *  As an implementation artifact unrelated to the specification,
>> <boost/stdint.h> and thus <boost/cstdint.hpp> #include <limits.h>.
>> This allows an implementation portable to many (most?) modern
>> computer systems, but has the side effect of defining a bunch of
>> macros (xxx_MAX/xxx_MIN/etc).  Should these be #undef'ed at the
end
>> of boost/stdint.h?
>
>If some program actually needs these macros, probably for backward
>compatibility, and we have something like
>        #include <limits.h>
>        #include <boost/cstdint.hpp>
>the programmer would be surprised to find the macros undefined.

Yes, agreed.  I have been convince by several post that #undef isn't
a good idea.

>> *  What compilers does
>> http://www.boost.org/libs/integer/bin_ubin_test.cpp work with?  It
is
>> already known to work with Metrowerks and Microsoft compilers.  It
>> doesn't work with gcc 2.95 - are there any egcs experts out there
>> that can provide insight?
>
>It works with a slightly more recent CVS checkout of gcc/egcs.
>After fixing the line-ending trouble with smart_ptr (see other
>mails on that subject), I had to add "boost::" in front of int32_t
>in line 109 of bin_ubin_test.cpp.  Yes, I know we have a "using
>namespace boost" before.

Thanks for the insight on egcs.

>And, bin_ubin_test.cpp needs "#include <cstdlib>" for std::atol().

Fixed.  Thanks.

--Beman