Boost logo

Boost :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2008-05-28 01:58:39

Neil Mayhew wrote:
> I think perhaps you've misunderstood the purpose of endian. The idea is
> to be able to define a structure like this:
> struct example_t
> {
> big8_t a;
> big24_t b;
> big32_t c;
> };
> example_t data;
> You read it from a file or a socket with read(fd, &data, sizeof(data))
> and then use data.a, data.b and data.c as if they were built-in integer
> types.
> Reading into a character buffer and then "mapping" a structure on top of
> it could be done with reinterpret_cast<example_t*>(buffer), although
> this is not the preferred approach.

I don't think I misunderstood the purpose. It is just that in my code I
ended up exactly as you said:

I have buffer in terms of char, i.e. char buffer[]. This buffer is not
from stream, file or socket. It comes from a fifo in my application.
The I want to make use of the buffer as:

if (type == id_foo) {
        foo& f(*reinterpret_cast<foo*>(&buffer[0]));
        ... do something with foo ...


And I think this is not only ugly but also unnecessary, since foo
already might be expressed in terms of char[]. If not, e.g. because
foo is not made of unaligned data, I'd prefer a compiler error

Btw. read(&foo, sizeof(foo)) also will need to do an equivalent
of reinterpret cast internally. Doesn't it?

I just think that endian is a fairly general idea that should not
be limited to stream, file and socket.

Yes of course I always can do the reinterpret_cast, but if we can
do better, why shouldn't we?

An alternative I can think of would be to not make the bytes[]

  _  _  | Roland Schwarz
 |_)(_  | aka. speedsnail
 | \__) | mailto:roland.schwarz_at_[hidden]

Boost list run by bdawes at, gregod at, cpdaniel at, john at