On Fri, May 23, 2008 at 1:46 PM, dizzy <dizzy@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