enum class align is overkill. I'd prefer an ordinary enum: enum assignment { aligned, unaligned }; Usage, in endian_buffer for example, would be a little more straightforward: template < order Order , typename T , std::size_t Nbits , alignment Align = unaligned
class endian_buffer;
More doc comments.... index.html "and the least-significant-byte-first is traditionally called": omit "the" our add it to the beginning of the sentence. s/release builds/optimized builds/ (the former is colloquial) s/Useful when intrinsic headers such as byteswap.h are not being found by your compiler/This is useful when a compiler cannot find out has no intrinsic support or fails to locate the appropriate header/ s/Useful for eliminating missing intrinsics/This is useful for eliminating missing intrinsics/ The answer to the FAQ, "Does endianness have any uses outside of portable binary file or network I/O formats?", is unsatisfying. Several times already you've mentioned the same idea, but nowhere do you explain what you mean. How does the library provide that minor benefit? In the FAQ, "Why bother with binary I/O?", s/direct access/random access/. In the same FAQ, the sentence starting with "Disadvantages" should be a separate paragraph. On the FAQ, "Which is better, big-endian or little-endian?", s/x64/x86-64/. s/Systems where integer endianness differs/Systems on which integer endianness differs/ (systems aren't places) buffer.html s/See the Wikipedia/See Wikipedia/ reads better to me s/containing four byte big-endian/containing four-byte, big-endian/ In the GIS example, I suggest sizeof(h) vs. sizeof(header) as a general means to protect against type changes. Boost should set a good example. s/do layout memory/do lay out memory/ s/base classes will no longer disqualify/base classes no longer disqualify/ s/from being a POD/from being POD/ (s/POD/POD type/ would also work) "alignment of an 64-bit integer may be to a 32-bit boundary on a 32-bit machine" would be more helpful if you complete the thought: "and to a 64-bit boundary on a 64-bit machine." The note, "One-byte big and little buffer types have identical functionality", might be better as, "One-byte big and little buffer types are identical on all platforms." The endian_buffer default constructor should have a note saying that the value is unspecified. (I'm assuming the value is not zero-initialized.) s/endianness conversion if required is performed/endianness conversion, if required, is performed/ s/set to one../set to one./ If prefer s/POD's/PODs/ "This is ensures that , and so" needs some work. ___ Rob (Sent from my portable computation engine)