Factories and conversion from Base to Derived...

[werasm]

Hi all,

I want to know whether the following is possible. I started out
with an idea called a CreationAbstrac tor. Basically just a
factory function wrapper for all types.

It looks like this:

template <class T>
class CreationAbstrac tor
{
public:
virtual T* create() const = 0;
virtual ~CreationAbstra ctor(){ }

protected:
CreationAbstrac tor(){ }
};

Typically, it would be used as argument to a class constructor like
this:

Driver::Driver( const CreationAbstrac tor<Car>& );

I attempted to make CreationAbstrac tor generic of up to N arguments:

template <class BaseT, class DerivedT = BaseT>
class Creator: public CreationAbstrac tor<BaseT>
{
private:
typedef boost::scoped_p tr<CreationAbst ractor<BaseT ImplT;

ImplT impl_;

struct NoArgImpl: public CreationAbstrac tor<BaseT>
{ virtual BaseT* create() const{ return new DerivedT; } };

template <class Fstruct Impl;

template <class A1>
struct Impl<void(A1)>: public CreationAbstrac tor<BaseT>
{
Impl( A1 a1 ): a1_( a1 ){}
virtual BaseT* create() const{ return new DerivedT( a1_ ); }
A1 a1_;
};

//etc...

public:

virtual BaseT* create() const
{
return impl_->create();
}

Creator(): impl_( new NoArgImpl ){ }
template <class A1>
Creator( A1 a ): impl_( new Impl<void(A1)>( a ) ){ }
//etc..
};

This seems to work fine, although I suppose you guys could
give me some pointers as to how to implement it better. The
problem that I have is that my original implementation had
only on type. Therefore:

template <class T>
class Creator: public CreationAbstrac tor<T>......(1)

This prohibit me from converting Creator<Derived to
CreationAbstrac tor<Base>, despite my best efforts.

Does anybody know of a better implementation using nifty
conversions where a declaration as in (1) may suffice to do?

IOW:

const CreationAbstrac tor<Base>& a = const
CreationAbstrac tor<Derived>&.. .;compiles fine.

Regards,

Werner

[werasm]

werasm wrote:

Excuse my fast fingers. See below:

This seems to work fine, although I suppose you guys could
give me some pointers as to how to implement it better. The
problem that I have is that my original implementation had
only on type. Therefore:

only <onetype

>
template <class T>
class Creator: public CreationAbstrac tor<T>......(1)

This prohibit me from converting Creator<Derived to
CreationAbstrac tor<Base>, despite my best efforts.

This prohibits..

Regards again,

W

[werasm]

werasm wrote:

Hi all,

I want to know whether the following is possible. I started out
with an idea called a CreationAbstrac tor. Basically just a
factory function wrapper for all types.

It looks like this:

template <class T>
class CreationAbstrac tor
{
public:
virtual T* create() const = 0;
virtual ~CreationAbstra ctor(){ }

protected:
CreationAbstrac tor(){ }
};

Typically, it would be used as argument to a class constructor like
this:

Driver::Driver( const CreationAbstrac tor<Car>& );

This seems to be a monologue. Anyway, yesterday after writing this
code I contemplated (after forgetting why) why I could not simply have
done

Driver::Driver( std::auto_ptr<C ar);

[Excuse my example... It is the only simple real world case I can
think of now.]

This would have solved the problem. Alternatively I could have used
something
like Loki Factories (I've read the chapter, yes). The reason the
auto_ptr would
not suffice, is that given the following:

Car( std::auto_ptr<E ngine>, std::auto_ptr<I nterior>...), the client
would be
inclined to try this:

Car( new ConcreteEngine( ...), new LeatherInterior (...) );

Which is also frowned upon... not exception safe, so to speak. For
this reason the notion of a factory does not seem like a bad idea.

Loki factories (whilst I have great respect for the ideas) also have
its problems. The book gives to examples - OpNewFactoryUni t
that creates by calling new T(), and PrototypeFactor yUnit, that
uses Clone on prototypes. This implies either default or copy
constructors are required. This also does not cater for the
possibility of implementation classes being dependent on
other classes. There is another issue. Often creator objects
only need to live as long as required. Using prototypes
imply they live forever, and not using prototypes imply
default constructors are required. Another issue that I
contemplated is creating OpAbstractCreat orFactoryUnit. What
I don't like about this, is the fact that sometimes the creator may
have references to temporaries (like strings), and it may not live
longer than required (It ceases to live once the constructors scope
ceases). Storing these as variant to prototypes would imply they
would have to live indefinitely, meaning the creator may not contain
references to temporaries.

Therefore, back to the car example, this would make sense to
me:
Car( const CreationAbstrac tor<Engine>&, const
CreationAbstrac tor<Interior>&. ..)...

This does not burden the implementor with the need to copy construct.
The actual creation is delayed until the actual point of calling,
which would
be in the constructor initializer list - most likely, or in that of a
member, in
which case it would be forwarded. Also, its exception safe, as usually
the
concrete class is created on the stack.

Monologue complete, thank you.

Any implementation tips (or critique) would be welcome.

Kind regards,

Werner