[endian] [bikeshed] Conversion function naming discussion

Beman Dawes

25 Jan 2015 25 Jan '15

2:06 p.m.

Naming is always a bike shed issue. I'm starting a separate thread for those who don't care can easily ignore it. The current names I'm least comfortable with are the conversion function names in the endian sub-namespace: big_to_native big_to_native_inplace native_to_big native_to_big_inplace little_to_native little_to_native_inplace native_to_little native_to_little_inplace conditional_reverse conditional_reverse_inplace 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. --Beman

Show replies by date

Peter Dimov

25 Jan 25 Jan

2:32 p.m.

New subject: [endian] [bikeshed] Conversion function naming discussion

Beman Dawes wrote:

...

The current names I'm least comfortable with are the conversion function names in the endian sub-namespace:

big_to_native big_to_native_inplace native_to_big native_to_big_inplace little_to_native little_to_native_inplace native_to_little native_to_little_inplace conditional_reverse conditional_reverse_inplace

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.

You can consider 'native' to be implicit and use from_big from_big_inplace to_big to_big_inplace from_little from_little_inplace to_little to_little_inplace although I, personally, am not sure whether this is an improvement.

Beman Dawes

3:34 p.m.

New subject: [endian] [bikeshed] Conversion function naming discussion

On Sun, Jan 25, 2015 at 9:32 AM, Peter Dimov wrote:

...

Beman Dawes wrote:

...
The current names I'm least comfortable with are the conversion function names in the endian sub-namespace:

big_to_native big_to_native_inplace native_to_big native_to_big_inplace little_to_native little_to_native_inplace native_to_little native_to_little_inplace conditional_reverse conditional_reverse_inplace

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.

You can consider 'native' to be implicit and use

from_big from_big_inplace to_big to_big_inplace from_little from_little_inplace to_little to_little_inplace

although I, personally, am not sure whether this is an improvement.

Those are a nice set of alternatives, but like you I'm not sure if they are an improvement. Let's see what others think. Thanks, --Beman

Rob Stewart

26 Jan 26 Jan

10:09 a.m.

New subject: [endian] [bikeshed] Conversion function naming discussion

On January 25, 2015 9:06:17 AM EST, Beman Dawes wrote:

...

big_to_native big_to_native_inplace native_to_big native_to_big_inplace little_to_native little_to_native_inplace native_to_little native_to_little_inplace conditional_reverse conditional_reverse_inplace

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 to_network "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: from_big to_big from_little to_little 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. ___ Rob (Sent from my portable computation engine)

Gottlob Frege

12:53 p.m.

New subject: [endian] [bikeshed] Conversion function naming discussion

On Mon, Jan 26, 2015 at 5:09 AM, Rob Stewart wrote:

...

On January 25, 2015 9:06:17 AM EST, Beman Dawes wrote:

...
big_to_native big_to_native_inplace native_to_big native_to_big_inplace little_to_native little_to_native_inplace native_to_little native_to_little_inplace conditional_reverse conditional_reverse_inplace

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.

In general, I actually like "from" better than "to", as it typically (although not in the endian case) solves a problem of param order: foo_to_bar(a, b); // which is the foo a or b? ie strcpy order (dst,src) or function-name order (foo,bar)? foo_from_bar(a, b); // a is the foo. function-name order AND strcpy order. (note: Stepanov admitted he got std::copy() in the wrong order and should have matched strcpy() and assignment - destination on the left). But anyhow, in this case we only have a single arg, so not exactly the same situation. Other common words used for this are "as" and "make" (the std uses "make" a lot, I think there are proposals for "as" - which are for cast-like situations) int x = as_little(y); int x = make_little(y); Not sure those are any better. I would say "make" would actually be a good term for the in-place version (ie alter this thing to make it little) if only the standard didn't already use it everywhere with a return value. :-( But maybe in-place could use different terms, replacing the "to/from" with uh, something? ie bigify(x); unbiggen(x); Another alternative: use 'native' for the inplace versions x = from_little(y); x = to_little(y); native_to_little(y); // in place Probably not as clear as the other choices. :-( Basically, I don't like any of them because I don't like that the input's big vs little is not part of the type system (ie use the arithmetic endian types), and is instead part of the function name ie I'd prefer int x = to_native(assume_big(y)); // assume_big casts y to a big int type, without altering the bits, then to_native knows what to do that could probably just be int x = assume_big(y); or int x = assume_cast<big>(y); because once assume_big returns a big_int32 then the int conversion is already there. Anyhow, - I could live with the original long names (how often are they used? Won't it only be in isolated code?) - I could live with Peter's shortened names Tony

Rob Stewart

10:55 p.m.

New subject: [endian] [bikeshed] Conversion function naming discussion

On January 26, 2015 7:53:47 AM EST, Gottlob Frege wrote:

...

On Mon, Jan 26, 2015 at 5:09 AM, Rob Stewart wrote:

...
I generally like "to" rather than "from" in names, but the types are

usually distinct, so that doesn't work so well here.

In general, I actually like "from" better than "to", as it typically (although not in the endian case) solves a problem of param order:

foo_to_bar(a, b); // which is the foo a or b? ie strcpy order (dst,src) or function-name order (foo,bar)? foo_from_bar(a, b); // a is the foo. function-name order AND strcpy order.

If "foo_from_bar" implies the two arguments are in the order "foo" then "bar", why doesn't "foo_to_bar" imply the same?

...

But anyhow, in this case we only have a single arg, so not exactly the same situation.

Right

...

Other common words used for this are "as" and "make" (the std uses "make" a lot, I think there are proposals for "as" - which are for cast-like situations)

int x = as_little(y); int x = make_little(y);

Not sure those are any better.

"as" works just as well as "to" for my purposes. "make" in no way implies conversion to me, although...

...

I would say "make" would actually be a good term for the in-place version (ie alter this thing to make it little)

...that does rather fit.

...

if only the standard didn't already use it everywhere with a return value. :-(

That's the problem. "make" doesn't imply conversion normally.

...

But maybe in-place could use different terms, replacing the "to/from" with uh, something? ie

bigify(x);

Enlarge

...

unbiggen(x);

Reduce ;-)

...

Another alternative: use 'native' for the inplace versions

x = from_little(y); x = to_little(y); native_to_little(y); // in place

Probably not as clear as the other choices. :-(

Using "as" for the copying variants and "to" for the in-place variants would work pretty well.

...

Basically, I don't like any of them because I don't like that the input's big vs little is not part of the type system (ie use the arithmetic endian types), and is instead part of the function name ie I'd prefer

int x = to_native(assume_big(y)); // assume_big casts y to a big int type, without altering the bits, then to_native knows what to do

that could probably just be

int x = assume_big(y); or int x = assume_cast<big>(y);

because once assume_big returns a big_int32 then the int conversion is already there.

I appreciate the idea, but that's just a more verbose way of writing the original names.

...

Anyhow, - I could live with the original long names (how often are they used?

Even in code that uses ntoh kinds of functions, there normally aren't that many uses, so the long names aren't the worst thing in the world. ___ Rob (Sent from my portable computation engine)

3765

Age (days ago)

3766

Last active (days ago)

List overview

Download

5 comments

4 participants

participants (4)

Beman Dawes
Gottlob Frege
Peter Dimov
Rob Stewart