Boost logo

Boost :

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

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

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 &);
> 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 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
>> 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
>> work with? It
>> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at