Re: [boost] Formal Review Request: Boost.Convert

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),
6. locale.

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 
request"?

> 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>
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 
double*/)

> 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 
follows:

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.

V.