|
Boost : |
Subject: Re: [boost] [Endian] Review
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-09-09 02:32:22
Steven Watanabe-4 wrote:
>
> AMDG
>
> On 09/08/2011 12:23 PM, Beman Dawes wrote:
>> On Thu, Sep 8, 2011 at 1:18 PM, Tomas Puverle <
>> Tomas.Puverle_at_[hidden]> wrote:
>>
>>>
>>> However, as I said, that's my personal preference and last year plenty
>>> of
>>> people wanted to see the operators included. Perhaps they could be a
>>> policy?
>>>
>>> endian<..., bool EnableOperators_ > ?
>>>
>>
>> I'll give it some thought, but my initial reaction is that endian is
>> already
>> more complex than I like, so I'm leery of adding yet more complexity.
>>
>
> If you don't want the operators, then don't use
> them. Having an extra template parameter to
> disable them seems rather pointless.
>
Hi,
I have separated the endian class into a endian_pack that is integer
agnostic and an endian class that behaves as an integer (You could see the
details in the Sandbox under endian_ext).
http://svn.boost.org/svn/boost/sandbox/endian_ext/libs/integer/endian/doc/html
(Sorry but there is a bad link to the reference)
This is not complex and allows to define physical structures that can be
used only at the I/O frontier.
To separate the concerns and avoid the inefficient arithmetic on endian
integers, the example posted on another thread
struct file_header {
big32_t n_things;
....
};
int main()
{
file_header h;
h.n_things = 0;
while (....) {
++h.n_things;
....
}
write(h);
....
}
could be rewritten as follows to force more efficient code
struct file_header {
big32_pt n_things;
....
};
where big32_pt is a typedef for a 32 bits
typedef endian_pack<endianness::big, int_least32_t, 32,
alignment::unaligned> big32_pt;
int main()
{
file_header h;
int n_things = 0;
while (....) {
++n_things;
....
}
h.n_things = n_things;
write(h);
....
}
Best,
Vicente
-- View this message in context: http://boost.2283326.n4.nabble.com/Endian-Review-tp3799423p3800913.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk