Boost logo

Boost :

From: me22 (me22.ca_at_[hidden])
Date: 2006-06-10 16:36:20


On 6/10/06, Beman Dawes <bdawes_at_[hidden]> wrote:
> There are two defaults we might like:
>
> (1) alignment defaults to unaligned.
> (2) num_bytes defaults to sizeof(T)
>
> [ Snip lots more discussion ]
>
I've been working on Yuval's idea, and in doing so came up with a
different interface that I'll describe here, as it deals with the
issues mentioned here in a different way. (This is not the exact one
I've implemented, I've adjusted some things to fit closer with what's
been discussed here.)

I've basically inverted some of the things. Instead of having
num_bytes default to sizeof(T), why not have T default to some type
based on num_bytes? Boost.Integer already provides an elegant
interface for doing this. This requires an extra template parameter
to specify signedness, but I don't think that's a problem. For one,
it means that the T parameter is unneeded, so it's not increasing the
number of parameters anyways. It means that the type can default to
signed, "as the ints do", and the signed and unsigned keywords are
valid arguments to a type template parameter, which I think is a
fairly elegant interface.

As for alignment, might there ever be a need to have alignment at
something other than num_bytes? If the storage is done in an
anonymous union of the char array and some type where
sizeof(Align_T)==align_bytes, then you can allow attempted alignment
at any number of bytes. Allowing aligned and unaligned as arguments
would also be easy. If unaligned has the value 1, then defaulting to
unaligned makes the Align_T a char, which has no effect on the
alignment. aligned could be given a value of 0, for which the
implementation would pick T as the Align_T.

Examples:
little-endian, 3 bytes, signed, unaligned: endian<little,3>
little-endian, 5 bytes, unsigned, unaligned: endian<little,5,unsigned>
big-endian, 4 bytes, signed, 4-byte aligned: endian<big,4,signed,aligned>
big-endian, 2 bytes, unsigned, 4-byte aligned: endian<big,2,unsigned,4>

This would, however, modifying (or implementing a clone of)
Boost.Integer to add support for long long or __int64_t or similar,
where available, but I think that would be a worthwhile project
anyways.

> Thanks for all the comments,
>
Thanks for bringing it up in the first place,
~ Scott McMurray


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