From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-07 14:35:57
From: Pavol Droba <droba_at_[hidden]>
> However, maybe something in between might be feasible. Actualy your interface is quite close.
> What I would like to propose, is to have a core part working with an arbitrary
> encoding (implementation defined) and a set of templated interfaces.
> So insted of writing unicode::whatever as in your proposal, "whatever" will be thin templated
> layer, that will convert application specific data to the format understood by the core library
> and vice versa. This layer should be fully dependant on locales to do the required conversion.
> These can be suplied by imbue().
Wouldn't it be better to use an installable translator (a policy
class or a strategy class?) that leaves up to the client the
responsibility to perform the required string operations like
concatenation (perhaps not needed), searching for a substring,
trimming a string, etc. That is, have the program_options
library defer all string operations, that require customization
to support Unicode strings, to the client.
Then, the library can provide the default, std::string
implementation, and clients can, as they see fit for their own
Unicode types, provide alternatives. Eventually, there may be a
few accepted translators that can be added to the library, but
for now, program_options won't need to define them, yet it will
be ready for the future.
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk