|
Boost : |
Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-24 04:25:31
> std::hex assumes some state in the stream for storing
> that hexadecimal formatting
> ... but it still requires the cooperation of the manipulators
> to set the state and the formatting logic invoked later.
Yes, and my expectation was/is that convert() (as lexical_cast) piggy-backs
on that std::stream functionality. And I think we've achieved very decent
results in that direction that many people would prefer to raw std::streams
and lexical_cast.
> That same, save state and use it later when converting is needed for
> something like convert.
Discarding std::streams for formatting and building something similar from
scratch based on Boost.Parameter is quite a task. I am not well qualified to
take on such a task. Especially in a short timeframe. I am not even sure
there is truly pressing need for that. I could look into it without hurry
next if convert() gets through the review.
> I'd still like to see a coherent set of requirements.
> There are too many forces tugging on the concept
> from what appear to be competing directions.
I personally feel we've achieved all our immediate objections that I felt
were important to people --
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.
In fact, I do not feel there are many forces pulling in different
directions. The issues remaining are
1. if the existing interface could be improved and
2. one major issue of deploying Boost.Parameter.
As for #1 there always room for improvement. Having said that I feel
something very laconic and unambiguous has come out of the discussion (even
though it has left no stoned unturned of my original "vision").
As for #2, it could be looked at (and I am planning to) in due course.
V.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk