|
Boost : |
Subject: Re: [boost] [conversion] review
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-08-30 10:41:18
Hi Phil,
On Aug 29, 2011, at 6:09 PM, "Phil Endecott" <spam_from_boost_dev_at_[hidden]> 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"?
>
> Is it because it is C, and C syntax is ancient history that must be purged from modern C++?
I have nothing against C. (I have learned a few techniques from C that got lost in C++'s rush to object orientation.)
It's probably a matter of personal taste, but once I know that a function is a conversion from X to Y any other names are just noise to me.
Having a unique name means (to me) that there might be many other ways of doing the same thing, and I'm not sure if I've chosen the right one. Going through a generic function means I or someone has chosen the best way and can replace it if they want.
E.g. convert strings to & fro types with a generic interface where you could switch in either lexical_cast or coerce and evaluate their performance.
Granted this is not as strong an argument as if we had a real use case for generic conversion itself.
E.g. why write
template<typename X, typename Y>
void do_something_amazing(Y const& Y) {
X x;
// If only I could convert Y to X... aha!
x = boost::conversion::convert_to<X>(y);
// ... some magic occurs
}
?
The only example I could come up with is implementing Perl-like scalars in C++ but I have no idea why you'd want to do that. So I'm hoping that some people who have tried to use lexical_cast for general type-to-type conversion will speak up.
I think Vicente's argument is much like my "personal taste" argument above: he would just rather have a single function than many. Especially when you consider that there's combinatorial complexity in the number of interchangeable types.
Cheers
Gordon
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk