Subject: Re: [boost] [conversion] review
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-09-02 13:41:55
On Sep 2, 2011, at 12:14 PM, Phil Endecott wrote:
> Stewart, Robert wrote:
>> Joshua Juran wrote:
>>> On Aug 29, 2011, at 3:09 PM, Phil Endecott wrote:
>>> > Gordon Woodhull wrote:
>>> >> If I had to write a conversion function, I would rather
>>> >> write it as an overload of a general-purpose converter,
>>> >> rather than giving it some ugly typeA2TypeB name.
>>> > Why is e.g. rgb_to_cmyk() "ugly"?
>>> cmyk_t cmyk = rgb_to_cmyk( rgb );
>>> That's why. Compare:
>>> cmyk_t cmyk = cmyk_from_rgb( rgb );
>> I prefer this:
>> cmyk_t cmyk = to_cmyk(rgb);
>> That permits reusing "to_cmyk" for various types via overloading.
> The problem with that is the (common?) case where rgb_t is a typedef for e.g. uint8_t. This applies to other conversions too, e.g. time_t is a typedef for int, centigrade_t and farrenheit_t are both typedefs for float, etc. etc.
In a generic version you'd be forced to use Units or something to wrap those types before you ever saw them. This applies to any hypothetical converter code, as well as to the even more hypothetical (?) generic user code of Conversion. (So far we have a vague "Situations when generic conversion is required are less often" from Antony Polukhin, and a numeric application from Jeffrey Lee Hellrung.)
I still find a syntax that emphasizes types over function names preferable, even if it involves a lot of angle brackets and ::'s. But I guess there's no disputing tastes, and we also saw a couple of technical problems with the approach taken in Boost.Conversion.
Thanks everyone for participating.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk