|
Boost : |
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-05-23 09:45:35
On Fri, May 23, 2008 at 1:46 PM, dizzy <dizzy_at_[hidden]> wrote:
> On Friday 23 May 2008 14:05:56 Roland Schwarz wrote:
>> Neil Mayhew wrote:
>> > This code is still in the vault, but I'd like to see it in the main part
>> > of boost. What needs to be done to make this happen?
>> >
>> > The endian library is exactly what I've been looking for, and I would
>> > really like to use it in my work, but I can't justify that to my
>> > colleagues if it's not an official part of boost.
>>
>> This is an interesting library indeed! Thank you for having this
>> brought up on the list again.
>>
>> However I have some concerns about usefulness when it comes to
>> compiler independence and platform independence.
>>
>> One of the goals of such a library to be useful (for me at least) would
>> be to be able to create compiler/platform independent binary files.
>>
>> I can see two problems here:
>>
>> 1) struct layout.
>> The standard gives no provisions for struct layout. So e.g. for
>>
>> struct foo {
>> big8_t a;
>> big32_t b;
>> };
>>
>> one cannot predict the alignment of the members. (Or am I wrong
>> in this respect?)
>
> Correct, which is why protocol binary structures are never mapped directly in
> memory (you can with some compiler extensions but you won't gain anything
> since I/O is the bottleneck in such cases and not memory copy). Instead a
> serialization aproach should solve such issues.
>
With disk I/O this is certainly true, on the other hand, high speed
LAN networks might actually be faster than (uncached) memory accesses
(think for example 10G ethernet). Zero copy I/O is certainly an useful
property.
-- gpd
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk