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

From: dizzy (dizzy_at_[hidden])
Date: 2008-05-23 07:46:54

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.

> 2) The standard makes no provision for object representation, so
>    writing out a bit pattern (which essentially is object
>    representation) cannot be guaranteed to be read in on another
>    platform. (Irresepective of endianess.) The only way to do
>    this is to map object values to a stream of chars.
>    One way to implement this mapping is to convert to ASCII
>    representation (this is what the standard lib provides), but
>    as I believe this is not the only mapping possible.
>    I can imagine a mapping to char values that is less computing
>    intensive and will resemble binary a little closer.
>
> In an attempt to solve issue 1) I came up with something like:
>
> struct foo
> {
>   foo(char* begin, char* end)
>
>     : x(begin)
>
>     , y(begin)
>     , z(begin)
>   {}
>
>   field<int, bigint32_t, 0> x;
>   field<short int, bigint16_t, 32> y;
>   field<short int, bigint16_t, 48> z;
> };

That kinda looks like reinventing boost.serialization although with a 
different API (I did something similar in my code).

I'm not sure if boost.serialization allows read/write on different platforms 
right now, if not, something could be added to it to do so (a new kind of 
archive type maybe). 

-- 
Mihai RUSU					Email: dizzy_at_[hidden]
			"Linux is obsolete" -- AST