<clip>

Adapters don't have to require copyable objects. A specialization can deal with noncopyable objects by replacing requirement to underlying type to be copyable with requirement to client code to accept const references and don't require identity semantic. Also, the adapter should live until it's default value is used somewhere.

Here is pseudo-code:

------- const T & adapter<T>::adapter(<constructor_parameters>) : default_value_member(<constructor_parameters>) { }

const T & adapter<T>::adapt(const T & value_to_adapt) { return value_to_adapt ? value_to_adapt : default_value_member; } -------

I think because this flavour of adapter manages the lifetime of contained default value, it's possible to build a version which would manage a container of multiple "default" objects and would enable identity semantic and remove const requirement. I don't think if this exotic case will be useful though.

I agree. Difficult as it was to find real cases that could use even a simple adapter, a multi-default adapter would seem to be a rare thing.

Also it's possible to decouple the adapter from its managed default value object by using

MO managed_object; // accepts, stores and returns a reference adapter<MO> f(managed_object);

Also default values don't have to be constants. Default objects can be generated by a generator object (which produces values) or by a factory (which produces identities and may allocate memory). For example, sometimes a random or "next free" default value can be useful. Like in case of bind() TCP socket function with optional port number.

Yes, a generator or factory would help if it decouples the adapter's interaction with the optional object.

And finally, it's possible to relax the requirements to both underlying objects (T) and client code (loadPoint) by storing a reference to an inplace factory inside of Optional objects, but as a price for this improvement we are back to that "metadata binding sin" then.

Sorry, I don't fully understand.

Or we can allow adapters simply to modify underlying objects:

adapter<MO> f(<inplace factory for default values>);

What do you think about all these proposed adapter designs?

Andrey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost