|
Boost : |
From: Hansi (hansipet_at_[hidden])
Date: 2008-05-27 10:41:52
It would be also great if it is possible to directly use lexical_cast
with the endian library!
Neil Mayhew schrieb:
> 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
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk