Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-10 08:52:38

Vicente BOTET wrote:
> De : "Stewart, Robert"
> > Vicente BOTET wrote:
> > > De : "Stewart, Robert"
>
> > > > 2. convert::converter customization point
> > > > * Non-stream-based main logic
> > > > * Functor interface
> > >
> > > Do you mean that the default behavior is a call to the
> > > conversion operator?
> >
> > The default behavior is to rely on T(S) or T = S.
> > Specializations of converter can do things differently.
>
> OK. Boost.Conversion customization point is based on overload
> of the convert_to function. Are you proposing I change this?
> What are the advantages?

Yes.  As I have mentioned elsewhere, the functor interface is useful and provides a convenient place to do specializations since it supports partial specialization.  IOW, having the function template use a class template to implement its logic gives the best of each: template argument deduction and partial specialization.

> > > > 6. convert::stream_converter customization point
> > > > * Stream-based main logic
> > > > * Functor interface
> > > > * Supports manipulators
> > >
> > > What about streamable::converter?
> >
> > In my mind, there's one main namespace for the conversion
> > library. Therefore, that would need to be
> > conversion::streamable::converter and then I'd expect
> > conversion::something_else::converter for the non-stream-based
> > converter. I'd prefer conversion::converter and
> > conversion::stream_converter, but that does require different
> > names for the two sets of function templates.
>
> Well, I don't think we need absolutely a specific namespace for
> the generic conversion (using the conversion operator by
> default) other than the conversion namespace,

Is that, perhaps, because the type-to-type conversions have been your focus?

> For the stream based conversion I will not use
> conversion::streaming::, but just streaming::

Distinct namespaces within boost conventionally implies distinct libraries, yet we're creating symmetry between the stream-based and non-stream-based conversions that cries out for a single library.

If default_value is conversion specific, and if we retain Vladimir's result type, both belong to the boost::conversion (or convert!) namespace.  Using them with boost::streaming functions would not be horrible, but seems odd, especially if there's just one library.  Therefore, boost::conversion::streaming and boost::conversion::direct (or whatever) seems better.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com





IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.