Re: [boost] Endian library - request for comments

From: me22 (me22.ca_at_[hidden])
Date: 2006-05-31 14:02:41

On 5/31/06, Beman Dawes <bdawes_at_[hidden]> 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