Peter Dimov wrote:

Fernando Cacciola wrote:

...

"David Abrahams" <dave@boost-consulting.com> escribió en el mensaje news:uvfee6kpk.fsf@boost-consulting.com...

...

I'm finding the documentation for in-place factories highly frustrating. There's no formal documentation for TypedInPlaceFactory, and almost no description whatsoever for InPlaceFactory. None of what's there describes how these things interact with optional; it isn't even mentioned in the corresponding section!

That stuff started out almost as an experiment and was intended to be generally usefull for all sorts of container classes. [...]

...

From the documentation:

"For example, one member of this familiy looks like:

template<class T,class A0, class A1> class TypedInPlaceFactory2 { A0 m_a0 ; A1 m_a1 ;

public:

TypedInPlaceFactory2( A0 const& a0, A1 const& a1 ) : m_a0(a0), m_a1(a1) {}

void construct ( void* p ) { new (p) T(m_a0,m_a1) ; } } ;

A wrapper class aware of this can use it as:

class W { X wrapped_ ;

public:

W ( X const& x ) : wrapped_(x) {} W ( TypedInPlaceFactory2 const& fac ) { fac.construct(&wrapped_) ; } } ;"

This doesn't look correct to me. W::wrapped_ is default constructed and then another X is placement-constructed on top of it.

Wrong indeed. Fernando Cacciola SciSoft

David Abrahams wrote:

"Fernando Cacciola" <fernando_cacciola@hotmail.com> 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) Best, Fernando Cacciola SciSoft

David Abrahams wrote:

"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:

...

David Abrahams wrote:

...

"Fernando Cacciola" <fernando_cacciola@hotmail.com> 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