Re: [boost] [conversion] ADL and templates

Subject: Re: [boost] [conversion] ADL and templates
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-06-01 08:25:07

Vicente Botet wrote:
> Stewart, Robert wrote:
> > Vicente Botet wrote:
> >
> > namespace boost
> > {
> > namespace conversion
> > {
> >    template <class Target, class Source,
> >       class Enable = void>
> >    struct converter
> >    {
> >       Target
> >       operator ()(Source const &) const;
> >    };
> > }
> > }
> >
> > Note that I'm suggesting
> > boost::conversion::converter<Target,Source,Enable> as the
> > name and I'm suggesting s/apply/operator ()/ to make it a
> > function object.  These alterations mean that there is now a
> > function object interface for effecting conversions from
> > Source to Target which is the sole point of customization
> > for all such conversions in the library.
>
> Yes, this could be a valid possibility. I will need to fix
> names for the other function objects associated to assign_to
> (assigner?), try_convert_to (try_converter), ... Or shouldn't
> the library provide CP for all the operations?

There should be one place to effect customization for all of the APIs supported by the library.  The converter interface above would need to throw an exception to indicate a failure, so perhaps instead it should be:

   bool
   operator ()(Target &, Source const &) const;

That would support the try API directly while those that throw an exception would do so if the conversion returns false.  Obviously, that avoids the need for Target to be Copyable, if not using a wrapper function that requires it, but it does mean that Target must be DefaultConstructible or that there be a CP for providing a default value (as we've discussed before).

Perhaps it would be better if the function object interface and the customization point were split:

template <class Target, class Source, class Enable = void>
struct converter
{
   Target
   operator ()(Source const & _source) const
   {
      Target result;
      if (custom_converter<Target,Source>::apply(result, _source))
      {
         return result;
      }
      throw exception;
   }
};

template <class Target, class Source>
struct custom_converter
{
   static bool
   apply(Target &, Source const &);
};

A PTS of converter that tests Enable, however you intended that to work, would be provided by the library, too.  Both specializations would defer to custom_converter<Target,Source>::apply() to do the conversion.  That means the CP isn't concerned with the Enable template parameter or with throwing exceptions.

Obviously, the try API could be written to catch exceptions and return false while the CP could be this instead:

   static Target
   apply(Source const &);

That permits those customizing a particular conversion to throw whatever exceptions they like.  I'm not sure which I prefer.  The flexibility of throwing custom exceptions is nice, but absorbing exceptions in order to return false from the try API seems heavy handed.

_____
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.