Re: [boost] New Library Proposal: dual_state

From: Jost, Andrew (Andrew_Jost_at_[hidden])
Date: 2005-07-14 06:57:18

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