Vladimir,

you are right. My library is not designed to take care of yours needs, and never was. I could do my best trying to update my library if there is enough interest and agreement in the interface. Next follows how I see the interface that could respond to the Boost.Convert features:

In order to take care of types without default constructor I see several options:

* Add an overloading having a default parameter

template <typename Target, typename Source>
Target convert_to(Source const& s, Target const& t);

and use it as follows

Target t = convert_to<Target>(s, Target(x));

* Use the existing assign_to function

template <typename Target, typename Source>
Target& assign_to(Target& t, Source const& s);

as follows

Target t (x);
assign_to(t, s);

* Add a meta-function that returns a default value for a type

template <typename T>
struct default_value
{
  T apply()
  {
    return T();
  }
};

The user will need to specialize this function for types that are not default constructible.

This meta-function will be used instead of declaring a defaulted variable in the string conversion function.

T v(default_value<T>::apply());

As a user I would prefer the second one and then the last one it is transparent except when the specialization is needed. The first option is not appealing for my taste.

In order to take care of no throwing semantics, I will choose to add a convert_to overloading with a error code parameter, not throwing without not knowing why fails seems too specific to me.

template <typename Target, typename Source>
Target convert_to(Source const& s, err_code& ec);

Target t = convert_to<Target>(s, ec);
if (ec ....

But I could understand there are some cases where the single reason is a bad format. We could also use the no_throw_t as additional parameter, but in this case the return type should allow to know if the operation has succeed or not. If we follow the C++ standard interface the use of pair seems to be the more appropriated.

template <typename Target, typename Source>
pair<T,bool> convert_to(Source const& s, no_thow_t const&);

pair<T,bool> p = convert_to<T>(s, no_thow);
if (p.second)

Note also that there could be some conversions that could transport whether the conversion succeeds or not

optional<Target> t = convert_to<optional<Target> >(s);

This conversion could be overloaded and never throw.

or a Robert suggested overload the pointer to a source

template <typename Target, typename Source>
optional<Target> convert_to(Source const* s);

Both mechanism can be mixed

template <typename Target, typename Source>
Target convert_to(Source const& s, Target const& t, err_code& ec);

Target t = convert_to<Target>(s, Target(x), ec);
if (ec ...

template <typename Target, typename Source>
Target& assign_to(Target& t, Source const& s, err_code& ec);

Target t (x);
assign_to(t, s, ec);
if (ec ...

I think these could be added to Boost.Conversion without not to much trouble.
I could do my best for the Boost.Conversion part, if there is enough interest and agreement in the interface.

Respect to the stream manipulators, what do we want? output an output streameable type and extract another type after some manipulations.

Source s;
a_iostream ios;
Target t;

ios << s;
ios >> m1 >> m2 >> t;

But you want to hide the intermediary iostream. As I stated on one of my post it will be great if we can define a specific input stream that is built from an output stremable type that allows to extract the value stating whatever format is needed. What about

as_istream(s) >> m1 >> m2 >> t;

Respect to the functor I think that we need to use Phoenix syntax and overload the functions with a Phoenix placeholder to create the functor. So

  convert_to<Target, Source>(_1)

will return a functor that can be called with one Source parameter and return a Target. The same applies to each one of the other functions.

In this way each feature is separated and compassable, avoiding a bloated class that do everything.

The generic part of Boost.Conversion will not take care are the string conversions and the input stream view. Boost.StringConvert could take care of the string specializations.

I don't know if there are some features I have miss. Please let me know.

Best,
Vicente