On 5/31/06, Beman Dawes <bdawes@acm.org> wrote:
The rationale for hiding the templates was that some implementations may prefer to provide hand-coded implementations of each type, either to speed compiles or to achieve platform specific optimizations. (I don't recommend the latter because of a lot of past experience where optimizations became pessimizations when something as simple as a compiler switch changed.)
With templates, specialisation could be used to provide hand-coded implementations, if desired. I fail to see how these would drastically speed compilation while remaining header-only, and if an implementation file becomes acceptable, explicit instantiation could be easily used for the templates that are needed.
I'm often amazed at the clever names Boosters suggest, so I think it is worthwhile to speculate a bit about better names. But the everyday use typedefs really do need to be short and memorable. I've been using the "bin2", "bun3", etc. since 1984 or so, with several hundred programmers now using them all the time, and never had a request to change the names.
* Use the naming conventions of the C++ Standard Library (See Naming conventions rationale): o Names (except as noted below) should be all lowercase, with words separated by underscores. o Acronyms should be treated as ordinary names (e.g. xml_parser instead of XML_parser). o Template parameter names begin with an uppercase letter. o Macro (gasp!) names all uppercase and begin with BOOST_. * Choose meaningful names - explicit is better than implicit, and readability counts. There is a strong preference for clear and descriptive names, even if lengthy. ~ http://boost.org/more/lib_guide.htm#Naming
The rationale for typedefs is that when an application uses endian classes, they are often used very heavily. Think hundreds, thousands, or even more uses in an organization. So, the names should be short, and all developers should use the same names.
struct header_record { bun3 version; bun1 rev; bun5 nrecs; ..... blah blah blah };
In a struct like that, copy-pasting would mean that slightly longer names wouldn't be much of an inconvenience: struct header_record { unsigned_bigendian<3> version; unsigned_bigendian<1> revision; unsigned_bigendian<5> record_count; }; and I think the readability gain would quickly make up for it. That being said, Rene Rivera's suggestions might be a nice middle-ground. Rene also raises an interesting point about the nessessity of operations on the types. How often does the internal byte ordering matter when not doing IO?
I guess I shouldn't have used that example, since it isn't realistic. In the real world, the endian classes are almost always used in classes or structs, and the I/O is usually Unix or fstream level rather than iostreams.
Sorry, but can you explain the difference between "fstream level" and "iostreams"? Also, how do you usually deal with padding? struct S { boost::bin4 a; boost::bun4a b; boost::bin5 c, d; }; g++ 3.4.6, for example, gives sizeof(S) as 20. Thanks, Scott McMurray