From: "Stewart, Robert" <Robert.Stewart@sig.com>
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.