Boost logo

Boost :

From: Thomas Matelich (matelich_at_[hidden])
Date: 2005-05-05 11:00:02

On 5/5/05, Dave Dribin <dave-ml_at_[hidden]> wrote:
> On May 3, 2005, at 3:27 AM, Kevlin Henney wrote:
> > In message <8dee398f92d54b9e2f27e107ee73052c_at_[hidden]>, Dave Dribin
> > <dave-ml_at_[hidden]> writes
> >> On May 1, 2005, at 1:56 PM, Kevlin Henney wrote:
> >>> This issue of providing a default value in case of failure was
> >>> discussed in the early days of lexical_cast, but not included. In
> >>> fact, if you go back far enough, opting for the default or zero
> >>> constructed value of the target rather than throwing an exception
> >>> was the original behaviour.
> >>>
> >>> However, the accommodation of an additional argument was not
> >>> included in lexical_cast in part for the simple reason that it
> >>> ceases to look like a cast and in part because once you start down
> >>> that road there are a number of additional arguments and options
> >>> that you might want that are "reasonable". It was felt that much of
> >>> this would be better off in a general conversions library that had
> >>> no pretensions to being cast-like.
> >>
> >> I agree that the default behavior should throw an exception. It just
> >> seems silly to create a whole new library that could be done in an
> >> existing one with about 5 lines of code. And I'd prefer a
> >> multi-argument cast-like function than include yet *another* 3rd
> >> party library with my application. Anyhow, I have an idea or two as
> >> alternatives. If you're interested, lemme know, otherwise I'll drop
> >> the whole idea. :)
> >
> > I'd be interested to hear your ideas.
> Since it sounds like the main argument against adding a second argument
> is that it is no longer cast-like, the simplest idea is to rename
> lexical_cast so it is no longer cast-like. I was thinking convert_to
> would be nice and readable:
> int n = convert_to<int>("abc"); // Should throw an exception...
> bad_conversion?
> int n = convert_to<int>("abc", 0); // Should return 0
> string s = convert_to<string>(5);
> The main issue with renaming, obviously, is backward compatibility. Of
> course, there's no need to remove lexical_cast right away, or at all,
> even. Maybe make it deprecated, or at least implemented in terms of
> convert_to.
> Thoughts?
> -Dave

As an early whiner about issues of lexical_cast, I've seen these
issues discussed many times. A few years ago there was a nice
proposal/implementation of an extensible lexical_cast that could use
other, more optimal, choices for certain conversions
( unfortunately
the code seems to have been lost). lexical_convert was bandied about
as a name for something providing default values, but I really like
the name convert_to. This is a library I'd really like to see in

Boost list run by bdawes at, gregod at, cpdaniel at, john at