Picon

Re: [integer] Promotion of endian library code from vault

On Fri, May 23, 2008 at 1:46 PM, dizzy <dizzy <at> roedu.net> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Gmane