On Mon, Mar 2, 2009 at 7:07 PM, Vladimir Batov <batov@people.net.au> wrote:
From: "David Abrahams" <dave@boostpro.com> Also, for what it's worth, when this discussion moved from simple to_string/to_int type functionality into the realm of a "generalized conversion framework," I mostly lost interest.
I haven't been watching closely, so I could be wrong, it seems like a classic premature generalization... the same one, in fact, that makes lexical_cast unsuitable for many people's purposes. Generic components can only properly arise from a survey of many specific, non-generic components. Have we done that for this "generalized conversion utility" or is the interface being designed speculatively to allow for something that maybe nobody wants or needs?
Yes, I have to agree as I've been feeling the same. I read/write a lot of configuration data and I have to rely on XML for communications. I need/use string-to/from-type conversions a LOT in the lexical_cast manner. I've never had the urge of integrating type-to-type conversions into any kind of a framework as those conversions seem so type-specific that the following always felt as the natural choice:
class Some { Some(Other const&) }
That said, I was not sure if my experience was that exemplary so I did not want to shut the door for such a possibility. I am still hoping that that fairly neutral interface
int i = convert<int>::from(str);
does not sacrifice the string-based origins of that whole discussion and at the same time leaves the door open whatever might come our way... if ever.
The point is, you're generalizing the interface without anybody having posted even a single use case that requires that generalization. Such generalization is not needed by anyone, or if it is needed we have no idea if that use case will fit this interface. So why is it supported? Just in case? We have lexical_cast for that. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode