[boost] Re: [optional] In-Place Factories

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2004-09-17 16:08:50

David Abrahams wrote:
> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
>>>
>>>> Fortunately, they seem to fulfill their intended purpose, at least
>>>> with Optional.
>>>
>>> Problem is, I can't tell what that purpose is.  I think I might have
>>> a use for such a thing, but I can't tell.
>>>
>> Ok,  I just checked in a draft of the new documentation.
>>
>> libs/utility/in_place_factories.htm
>>
>> This superseeds the documentation in Optional.
>>
>> I hope you can make sense out of this stuff now.
>> I'll finish the new document and update the optional doc soon.
>>
>> This stuff is supposed to be used by end users, so the new
>> documentation talks about it being on /utility instead of /detail as
>> it is now.
>> It also uses the 'correct' class names.
>> However, I haven't move nor change the code yet as I'm not sure if
>> today is a good time for doing that (becaue of the branch for
>> release)
>
> This still doesn't explain how to use these factories with
> boost::optional.

Yes, I still need to update optional's documentation.

> It's all very abstract.  Which of boost::optional's
> interfaces interact with this stuff?

In a nutshell:

A constructor and an assignment operator.

Here's a more complete example:

struct X
{
  X ( int a0, int a1 ) : m_a0(a0), m_a1(a1) {}
  int m_a0, m_a1 ;
} ;

void foo()
{
  // Constructs X(3,4) right within the optional
  boost::optional<X> opt( boost::in_place(3,4) );

  // Destroys the previosuly held value and constructs a new X(5,6) in place
  opt = boost::in_place(5,6);

  // Typed factories are also supported, though not very useful in optional
  opt = boost::in_place<X>(5,6);
}

> What is the concept requirement
> on those interaces?

Ok, this must be added to the documentation.

Simply put:

(1)
InPlaceFactory must derive from the class InPlaceFactoryBase
(wrongly named in the current code)

TypedInPlaceFactory must derive from the class TypedInPlaceFactoryBase
(wrongly named in the current code)

(2)
The InPlaceFactory concept requires the following member function
(its sematics is explained here with the sample implementation)

template<class T>
void InPlaceFactory::apply ( void* address ) const
{
  new (adress) T ( <argument_list> ) ;
}

The TypedInPlaceFactory concept requires the following member function:

void TypedInPlaceFactory::apply ( void* address ) const
{
  new (adress) T ( <argument_list> ) ;
}

In both cases, <argumet_list> is a detail of the model, but naturally it
must match the signature of a T ctor.
In the Typed case, the type 'T' is also a detail of the model (not part of
the concept req)

> How do specializations of these factory class
> templates fulfill those concept requirements?

They need only derive from the stated base classes and provide the apply
method.
The details of the argument list, such as what parameters it contains, how
it is stored and how the parameters are passed to the object ctor are model
details.

In the case of the non-typed version, the concept user (say Optional) will
pass to apply() a storage compatible with the type passed to apply.

In the case of the typed version, the storage will correspond to a type
which is not necesarily compatible with the type 'T' (since T is a model
detail).
In this case, it is expected that the code passing a particular model for
the TypedInPlaceFactory
concept to Optional uses the correct type (which must be exactly the type
contained in the Optional)

HTH

Fernando Cacciola
SciSoft