Subject: Re: [boost] [endian] [bikeshed] Conversion function naming discussion
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-01-26 05:09:35
On January 25, 2015 9:06:17 AM EST, Beman Dawes <bdawes_at_[hidden]> wrote:
> These are quite explicit, but are a bit too long and awkward for my
> taste. I'd be willing to change these names if someone can come up
> with replacements that are shorter and less awkward, but still
> reasonable explicit.
One option is to use "_copy" for the first set and remove "_inplace" for the others.
I generally like "to" rather than "from" in names, but the types are usually distinct, so that doesn't work so well here. Peter's "from_big", et al, aren't bad, but not great, from that perspective, but don't distinguish between little and native as the target order.
There's nothing in the functions or their arguments that will ensure the right one is used, however. The explicit naming may be of slight value in making one choose correctly initially, or helping a reviewer spot a mistake, but I'm inclined to adopt the traditional notion of network order being big endian so the source or target endianness can be implied (which is not unlike Peter's suggestion):
"to_host" implies its argument is in network order, while "to_network" implies its argument is in host order. Add variants with copying and you're finished.
If you want to avoid the implied ordering of the network data, then the argument our target can be assumed to be in host order. Thus:
If the host order is little endian, "from_big" and "to_big" would swap the bytes. If the host is big endian, they would be noops. The others are similar.
I don't see a separate need for the "conditional_reverse" functions, for the above suggestions, but if you keep them, I can't think of a better name.
(Sent from my portable computation engine)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk