Stewart, Robert wrote:
Jeff Flinn wrote:
Stewart, Robert wrote:
Gordon Woodhull wrote:
[snip massively overquoted context]
sorry thought I snipped that stuff.
convert<int>::result res = convert<int>::from("blah", -1); if (!res) message("conversion failed"); int value = res.value(); // proceed with the fallback anyway. It's just that the next line might read
int res2 = convert<int>::from("blah");
and throw, and there's no indication why one version throws and the other does not. Of course there is. One was given a fallback value and the other wasn't. dynamic_cast sets a precedent for how to handle throwing/non- throw variations:
dynamic_cast<X&>(y); // throws if cast fails
X* x = dynamic_cast<X*>(y); // returns 0
So if boost::optional is the analog of pointer, and we go to some xxx_cast naming convention we could have:
// throws if fails int i = xxx_cast<int>(s);
// returns empty optional if cast fails boost::optional<int> oi = xxx_cast<boost::optional<int>>(s);
// never fails int i = xxx_cast<int>(s, 123);
This just reuses boost::optional rather than the (superfluous to me) convert<T>::result type. I for one see no reason that _cast need be limited to a single argument.
I really dislike the repetition of "boost::optional<int>" in that. What about going a little farther in the dynamic_cast direction (actually, following the boost::get precedent):
int const i(xxx_cast<int>(s)); // throws on failure boost::optional<int> const oi(xxx_cast<int>(&s));
My gut reaction is that it lacks symmetry. As mentioned else-thread, doesn't C++ 0x's auto solve the repetition entirely, while being explicit as to what's going on? auto oi(xxx_cast<boost::optional<int>>(s));
Whereas dynamic_cast requires casting from a pointer type to a pointer type, here the suggestion is that casting from a pointer type implies casting to an optional. Note that the cast is "xxx_cast<int>" in both cases; it’s the source argument's being a pointer or not that dictates the overload and, thus, the return type.
If others find multiple arguments too disgusting, perhaps boost::make<int>(s, 123) is more palatable.
That name could work, but does it allow for formatting? IOW, "convert," like "translate," leaves room to consider formatting, including locales. "Make" suggests something more fixed to me.
I personally don't have those reservations and the applicability of Make. Even more concise with perhaps less preconceptions might be: as<int>(s, 123); Jeff