On 5/27/08 1:19 AM, Roland Schwarz wrote:
1) Would it be possible to add a conversion operator to char* ? At least for unaligned types.
2) I'd like to be able to initialize a struct containing endian<> types by making it a reference to some buffer.
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. The idea is not to take individual endian integers and force them to a particular position within a buffer, but to let the whole struct do the work of computing the offsets. Of course, that can be still done with reinterpret_cast, but it's not how the library is designed to work.
3) The naming endian for the lib does not caption its "real" purpose. At least I was not aware of it altough I was searching for it. I'd suggest something as ptype.hpp for _P_ortable _TYPES_.
You have a point here, although the original purpose of the library is to provide a clean and safe way of accessing data that does not use native endianness. The capability to handle unaligned and odd-sized integers goes naturally with this, so it makes sense to me to keep the name. It was what I searched for when I was looking for something like this. I was trying to handle big-endian data on a little-endian platform. I would say the purpose is NOT to provide portable types, but to be able to handle non-portable types that are forced on us by legacy and platform-specific data formats. Endian *can* be used to create portable binary files, but users of endian should be careful to consider the issues before making use of endian too heavily for new formats. A truly portable format like XML is in general much preferable to creating new binary data formats. My only concern with the name endian is that there is already an endian.hpp elsewhere in boost and I think it would be easy for people to miss this endian, and never discover its functionality. --Neil