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 instead. 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[] private. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at