On 6/2/06, Beman Dawes <bdawes@acm.org> wrote:
"Cliff Green" <cliffg@codewrangler.net> wrote in message
But I'm curious as to the rationale [...] Sure. The usual application for me is a record (or page) oriented disk file. The app works with a record, but often only touches a portion of that record. The rest remains unchanged. Doing a byte-reversing copy of the entire record into a buffer would kill performance.
Thanks, I was wondering about that as well. On 5/31/06, Yuval Ronen <ronen_yuval@yahoo.com> wrote:
What I'm suggesting is to provide a library for integer types of various sizes/alignments. This already partly exists in Boost.Integer (AFAIK, support for alignment is missing there). So Boost.Integer needs to be expanded for this.
On 6/2/06, Beman Dawes <bdawes@acm.org> wrote:
I've exposed the integer_cover_operators template and moved it to a separate header to make it generally available. I like your suggestion to make it part of Boost.Integer - I hadn't thought of that.
I've attached a basic exact.hpp header. I took the endian.hpp header and cut it down to something that might make a nice addition to Boost.Integer regardless of the outcome of the endian discussion. It's basically the unaligned_bytes idea, but done in host endianness. Usage is exact_int_t<N> or exact_uint_t<N>. ( it BOOST_STATIC_ASSERT's if N is not a multiple of numeric_limits<unsigned char>::digits ) It might be possible to make them faster by typepunning the internal storage to a bitfield, but I don't think that's legal. I didn't use integral types instead of the char array where the size matches nor bitfields internally because that resulted (in g++ 3.4.6) in extra padding or alignment requirements being added to the struct, which would presumably be unacceptable. Perhaps exact and aligned_exact could be added to uint_t and int_t? As a typedef to void or a fancy template trick to have it not be provided where impossible, presumably. Additionally, though this is slightly off-topic, why do uint_t and int_t not use __int64_t or long long or similar when available? That currently prevents using N>32 on x86 with the attached code. It might also be a nice template argument to some big_endian<> and little_endian<> wrapper templates, if that design is used. I find the appearance reasonably elegant: boost::little_endian< short > boost::big_endian< boost::uint16_t > boost::little_endian< boost::uint_t<24>::exact > boost::little_endian< boost::int_t<32>::aligned_exact > I particularly like the separation between sizing and endianness, though it's probably too verbose for your tastes. Hoping that that was more productive than my last few posts, ~ Scott McMurray