|
Boost : |
From: Jeff Garland (jeff_at_[hidden])
Date: 2004-12-06 07:00:26
On Mon, 06 Dec 2004 08:41:40 +0100, Roland Schwarz wrote
> Jeff Garland wrote:
>
> >I'm interested in seeing something like this in boost...
> >
> >Question -- will this compile in your implementation?
> >
> > square* ps4 = dynamic_new<square>("square", 10.0);
> >
> >as well as:
> >
> > shape* ps4 = dynamic_new<shape>("square", 10.0);
> >
> >
> >
> Well this depends on which types you have registered.
> In
>
> square* ps4 = dynamic_new<square>("square", 10.0);
>
> you are assuming a different base class than shape, and to this
> end you also would need to "declare"
> TYPE_MAP(square);
> too.
Ok.
> But I admit since I only posted a small example to find out
> the level of interest I did not put much effort to explain
> my rationale and the possible range of usages.
>
> It goes something along this:
> To call a function of an object you need its interface.
> I use an (not necessarily) abstract base class to describe
> it. I use the covariant return types feature of C++ to
> return pointers to derived classes from a creator function.
>
> So the pattern of usage is:
>
> baseclass* p = dynamic_new<baseclass>("derivedclass");
>
> if the dynamic new cannot perform the requested operation at runtime
> it return a 0 - pointer instead. If succesfull p points to the
> derived class. To make it the exakt derived class, you need to cast
> it of course.
>
> derivedclass* p = (derivedclass*)
> dynamic_new<baseclass>("derivedclass");
>
> But this of course is not of much use, since it is easier then to call
>
> derivedclass* p = new derivedclass;
>
> since you already know everything that is needed to create the object.
I was asking because I was curious if the construction idiom based on string
could be applied consistently throughout an application even if in some places
in the code I had exact knowledge and hence wouldn't be constructing a base
class pointer. My interpretation of the above is that in this case I have to
drop back to doing a regular constructor because the virtual constructor
doesn't handle this elegantly....
Jeff
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk