Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-25 02:29:29
> From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
>> Yes, and my expectation was/is that convert() (as
>> lexical_cast) piggy-backs
>> on that std::stream functionality.
> I hadn't seen any commitment to doing so, but I favor it. That offers the
> best reuse of functionality and knowledge.
Thank you. The commitment was implicit (due to IOStream-based
implementation, lexical_cast origins, manipulators) and I am still planning
to stick to it as it gets me where I'd like to be the quickest. Still,
hearing that I am not all alone with the view certainly helps. Thanks.
> I know you already requested a review, but that seemed woefully premature.
Yes, I see your point... and looking back I think I have to agree. :-) In my
defence I might say that functionality-wise not that much changed from the
first "Formal Review Request" as it provided the list below:
1. the default value,
2. no DefaultConstructibility,
3. throw/no-throw behavior,
4. simple/advanced failure checks,
5. formatting (even though only "uninteresting" std::stream-based),
Surely, the 'string' namespace and some stuff are gone, implementation looks
nothing as before. Although I'd expect "adjustments" like that to be an
expected result of a review. Granted, my first "Review Request" posting was
not that much of a review (as Scott correctly noted) as I wanted to
request/review/flash out what people actually needed from convert. Still,
your point taken. Do you think we are any closer to "formal formal review
> This is the closest thing to a set of requirements I've seen.
I think the list is pretty much as I listed it initially when requested the
"Formal Review Request". I could be wrong though.
> What about the concern I raised early on about implicit conversions?
> The ideal interface has the compiler deducing both the source and
> destination types to avoid implicit conversions of the source object to
> the source parameter and the conversion result to the destination object.
Unless I misunderstand, don't we achieve that with
template<class TypeIn, class TypeOut>
convert_from(TypeIn const&, class TypeOut const&)
as it is templated there is no implicit conversion. Still, when we actually
want one we can do
double d = convert_from<string, double>(str, -1/*implicitly converted to
> 4) and 5) are incompletely specified. What are the use cases?
> What sort of formatting control is needed?
> Does the current interface support them?
> Without use cases specifying the desired usage pattern,
> it's hard to know whether the current interface is sufficient.
As for #4 I tried covering that in the doc. and in a nutshell it is as
int i = convert_from(str, -1);
if (i == -1) // simple check
convert<string, int> i = convert_from(str, -1);
if (i.good()) // "advanced" check
I cannot see anything beyond that and unless I missed that there was no much
debate around it (or I was too busy defending my "string" namespace :-) ).
As for #5 then, it is as much or as little as std::stream provides. That, in
fact, covers all my formatting need and I think could be a good basis. I am
very reluctant getting more adventurous as I suspect the process will drag
for long time and will fizzle out with no result in the end.
> Was there a link to documentation on these requirements that I missed?
There is a hastily written "document" together with the implementation in
the Vault (the file called boost-string-convert.zip).
> What about Emil Dotchevski's desire for from_string() and to_string()?
> Have those been dropped entirely?
Indeed, Emil was very vocal about those to/from_string. I followed the
discussion and believe you provided very weighty arguments in favor of a
more generic scope. That's the direction I took.
> I think it was Emil's intention that those functions be concerned
> with providing optimized conversions to/from string with only
> limited formatting support, ...
> I didn't want Emil's concerns to be dropped altogether.)
I do not think Emil's concerns have been dropped. Yes, there is probably no
support for his specific needs in the current IOstream-based
implementations. However, the "framework"-style approach supports
specializations. I.e. Emil could write his own specific conversion (to/from
any type) and have it deployed via the "framework" interface. That's what
I've been doing with lexical_cast -- specializing it for my types to allow
handling them via common (lexical_cast) interface.
> FYI, "laconic" is rarely used in modern American English.
> (I can't speak for other variants.) We use "concise" instead.
Thanks. Appreciated (truly). Will avoid it then. It was not exactly a
success with the Australians I know. :-)
>> discussion (even
>> though it has left no stoned unturned of my original "vision").
> That is typically the case with Boost!
I am glad I went through that (well, not through yet :-) ). And many thanks
for taking me for the ride -- a ride worth taking on a few levels.