From: "Stewart, Robert" <Robert.Stewart@sig.com> ... I don't think there's any reason to pursue a review until things begin to quiesce which doesn't appear likely any time soon, if the current discussions are any indication.
Well, that's IMHO too bad. I obviously cannot carry on forever and I do not see a consensus getting any closer. The crux of the matter (in my view) is that the convert() functionality is available and IMHO way better than lexical_cast has to offer. Rejecting it because Spirit can do formatting better or because convert() does not use Boost.Parameter would be shortsighted IMHO as in the end people will be still left with nothing -- a huge hole between lexical_cast and Spirit. Is it realistic/practical approach? I do not think so. When/If something better comes up, this functionality will die out by itself.
I appreciate your excitement, but it would be far better to have a well conceived, broadly acceptable idea before heading for review. Otherwise, you're quite likely to find your library rejected with comments like you're seeing now.
Again, I am not convinced that what I have on offer is badly conceived. Surely, there's been quite a discussion about names and the 'string' namespace. However, I hope that well-conceived means quite a bit more than just names... which we'll never come to an agreement about. So, if it is really the case that the naming (rather than functionality) will be the deciding factor for an acceptance or a rejection, maybe it is better to drop the whole thing altogether.
What about the concern I raised early on about implicit conversions? The output value can still be implicitly converted to the callers destination object. To avoid input and output conversions, you need the likes of this:
template <class Out, class In> void convert(In const &, Out &); // or convert(Out &, In const &)
Aha, now I understand. Passing a parameter by a non-const reference. Yes, as above we indeed avoid the implicit conversions. That's nice. Never occured to me. I admit I am allergic :-) to returning results this Pascal-style. Never grew on me. Sorry. Just not my cup of tea. Will probably do *anything* just not to have it. :-) Truly sorry.
Without that, the following might surprise someone:
foo f(convert<double>("1234.5"));
Yes, that's typical of C/C++. Although I admit that after reviewing/looking at so much of somebody else's code it has never been my major concern. And isn't a compiler warns us of things like that?
I had no idea that testing for the default value or querying a success flag was what you meant by simple and advanced "failure checks."
Wel, calling it "advanced" is probably a bit rich. How about simple and "better" failure checks. They *are* failure checks, aren't they?
I think there should be two or three distinct signatures for using the conversion facilities:
1. A call that throws on failure. 2. A call that takes a default and always succeeds. 3. A call that returns false on failure.
As I indicated, I am not convinced there is such a clear cut as I might be forced to provide a default (due to no def.ctor) but still want to throw. My thinking behind convet_to, convert_from is that the latter *is* the interface. I'd be happy to get rid of #1 (which is convert_to) but I think it'd better be there for better transition from lexical_cast. As you indicated in your very first reply to this thread (in relation to string::is()) #3 will have to actually try the conversion. If I remember correctly you did not like it much (or did you object to the name only?).
... With that set of signatures, there's no implied need for a special return type that converts implicitly to the destination type and can be queried for success, or a throw/nothrow flag. There may yet be a special return type to account for specifying the default value as I suggested elsewhere, or for some other peculiarity, but it isn't a given.
Again, my real example: direction dir = convert_from(str, direction::up); It takes the default because it has to (no def.ctor). It does not mean I do not want to throw on failure... In real life, I don't. However, then I need a means to distinguish the failure. With convert::result<direction> dir = convert_from(str, direction::up); if (dir.good()) I can achieve that without resorting to your #3 to actually try the conversion twice.
I had no idea that you were referring to the formatting facilities inherent in the underlying IOStreams implementation. Still, there must be a large number of use cases of various kinds of UDT and builtin conversions, complete with a variety of formatting tasks, to determine if the interface will cope well in this context.
I feel there is too much emphasise on formatting. I do not believe convert() is the tool for it. For good formatting we need good formatting tools (Spirit?). However, for basic formatting IOStream-based approach works for me -- I do not need to bring a cannon (Spirit) to shoot a few little birds (basic formatting). V.