Stewart, Robert wrote:
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).
Each operation can be applied to types with different restrictions. It is clear that convert_to can only be used for types that are CopyConstructible. The specific implementation could have other requirements. In particular the default one requires the expression Target(source) to be valid. The preceding interface corresponds to the try_assign_to function and the interface doesn't have any requirements on the target type, except if the target should not be modified when the conversion fails. In this case the implementation will impose more requirements CopyConstructible. Again each specific implementation have its owns requirements.
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 &); };
I don't think the default implementation of converter should use a function that needs to use a try-catch block to hide the possible exception thrown during the conversion.
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.
Sorry, I don't understand what do you want to do with Enable.
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.
This correspond to the current implementation of try_convert_to.
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.
I think we can resume that having a single customization point for all the operations would not be enough open, and that we need CP for all the operations. The question now is what is the default behavior for each one of the operations. On the current implementation all the operations use directly or indirectly the convert CP. I will add on the documentation the requirements for each one of the implementations. I will use the Enable parameter each time the requirements can be expresed using a trait meta-function. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/conversion-ADL-and-templates-tp3561641p35... Sent from the Boost - Dev mailing list archive at Nabble.com.