$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] Boost.Convert+Boost.Parameter
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-03-02 22:07:15
> From: "David Abrahams" <dave_at_[hidden]>
> 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.
V.