Re: [boost] [endian] [bikeshed] Conversion function naming discussion

Subject: Re: [boost] [endian] [bikeshed] Conversion function naming discussion
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-01-26 17:55:17

On January 26, 2015 7:53:47 AM EST, Gottlob Frege <gottlobfrege_at_[hidden]> wrote:
> On Mon, Jan 26, 2015 at 5:09 AM, Rob Stewart <rob.stewart_at_[hidden]>
> 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)