Vladimir Prus wrote:
Hi Roland,
What if I write:
shape* ps2 = dynamic_new<shape>("circle", 20);
?
Since I am using a template function as a type generator and tipeid().name() in turn this will deduce a function requiring an int for the ctor. Since only double has been registered in the example program your example will not work. (It will give a 0 -pointer at runtime.) Please note that my implementation is not very smart and could be improved by someone more knowledgeable than me. Perhaps it is not so hard to add support for automatic type conversion too? But then my implementation fits entirely (almost) on two sheets of paper.
I tried to create virtual construct functionality for a future Boost.Plugin library and it worked like this:
namespace boost { namespace plugin { template<> struct virtual_constructors<Weapon> { typedef mpl::list<mpl::list<std::string>, mpl::list<std::string, int> > type; }; }}
Given those declaration, instantiaton of boost::plugin_factory<Weapon> will have a 'get' method for each listed constructor signature, and usual overload resolution will work.
Altough I have not a very good knowledge of the mpl lib right now, this looks very interseting to me.
The disadvantage is that you need to explicitly instantiate 'virtual_construct',
Hmm, I cannot see how I ever could do away with this instatiation. Or do you mean it should better be done implicitely?
but then you get static checking. For example, a plugin can't forget to define a required constructor.
I also considered this syntax: struct virtual_constructors<Weapon> { typedef mpl::list<ctor (std::string), ctor (std::string, int)> .....
where 'ctor' is auxillary struct, but maybe it's too smart, haven't decided yet.
I am not entirely sure, if you intend this struct as external to your class or as a member? Most likely I did not yet get the full picture and my question might seem somewhat blurry. Could you post a little example that exhibits the user interface? I have the vague feeling that you have found a more pleasing way to specify the virtual constructors. Having said this I should mention another design criterion of mine: I wanted the mechansim to be non-intrusive and appliable to any class (as I think yours is too, isn't it?) Hidden behind my macros are objects whose sole purpose is that their (global) ctors are to be called before program start to register all the ctor types. E.g.: #define TYPE_REGISTER(B, D) dynanew::type_entry<B, D> type_entry_##D(#D) If there is anything smarter possible I would prefer it! BTW.: I am not so much interested in getting my proposal into boost as seeing this kind of functionality within boost. If you already are on the way to preparation of such a proposal I would in no way contend, rather support your efforts. If you think my implementation could be of interest to you I am pleased to mail you a copy for further study. Roland