dynamic_cast<> has a implicit 'nothrow' version that returns the default value of NULL. having a 'nothrow' version of lexical_cast would not a all be out of line. --Ben On Sun, Feb 8, 2009 at 2:33 PM, Ben Muzal <bmuzal@gmail.com> wrote:
In fact, if we put together all the badly needed functionality that overlaps with lexical_cast, and give it appropriate interfaces, I'm not entirely convinced that there would be much use for lexical_cast anymore.
Really what is with all of the "slippery slope" arguments? People are not asking for the kitchen sink. We just want a nothrow version of the cast and to do that, a default value is needed.
I always use my own extension "lexical_cast_nothrow" operator anyway that just catches the exception and returns a supplied default value if necessary.
Lots of times there are cases when a default value simply will not be acceptable, but quite often one will. Why can't it be easy to support both models?
I had not even heard of the <optional> library until reading this thread. I might update my little boost extension after checking to see how <optional> affects performance and code bloat -- but really, <optional> looks rather more complicated than necessary.
I heard once that google was experimented with the number of search results that it returned. If they returned 100 results instead of 10, the search took .4 seconds longer. They found that the extra delay reduced the number of searches by 20% within the experimental group.
The moral of the story: some times it is the little conveniences that count. I think that supplying a 'nothrow' version of lexical_cast is one of those little conveniences that would definitely count.
--Ben