Wu Yinghui, Freddie wrote:

...

Dear all,

I'm implementing a hierarchy of classes to handle different types of objects. The characteristics of these objects are mostly similar (so I can put them into a container that knows only about the pure abstract base interface type), but some properties are specific to each object types.

I plan to use Boost.Parameter for its capability of providing named parameter to these object types. However, I have one problem in this approach: Since Boost.Parameter requires that the function processing the ArgumentPack to be a template, I cannot make it virtual (a member function template cannot be virtual) in my pure abstract base interface. Furthermore, due to the lack of "virtual" member function, I cannot use the base class pointer to provide these named parameters to some subclasses.

Depends on what you actually want to do. Perhaps you could use something like the template pattern (pseudo-code):

----- struct Parameters : boost::parameter::parameters< ... > {};

struct Base { BOOST_PARAMETER_MEMFUN(void, Work, 1, 4, Parameters) { DoWork( p[arg1], p[arg2|0], p[arg3|1] ... ); }

private: virtual void DoWork(actual, args, goes, here) = 0; };

class Derived : public Base { virtual void DoWork(actual, args, goes, here) { ... use args ... } };

class Derived2 : public Base { virtual void DoWork(actual, args, goes, here) { ... use args ... } };

-----

I've used something similar myself, hope that gives an idea on how to solve your problem.

// Johan

Thanks for your quick reply, Johan. I actually thought of a similar solution. I guess I didn't explain my problem clear enough... Unfortunately, this solution doesn't seem to suit my need. The situation is like this: In the pseudo-code you provided, DoWork() function is declared in the Base class, and is overridden by Derived1 and Derived2, with a fixed number of arguments. My problems is that, my base class cannot predict the exact number of parameters that a derived class may have. (A derived class may have 10 parameters, while another may have none.) So it looks a little bit out-of-shape in terms of the OO programming style I'm familiar with if I'm going to provide overloads of DoWork() for all the possible parameters used by all derived classes (not to mention the undesirable dependency introduced). Thanks again for your comments! Any further thoughts? :) Cheers, Freddie -- Wu Yinghui, Freddie Research & Development Senior Software Engineer Volume Interactions Pte Ltd 1 Kim Seng Promenade, #12-01 Great World City East Tower Singapore 237994 Tel: +65 62226962 (Ext 216) Fax: +65 62226215 Email: yhwu@volumeinteractions.com URL: http://www.volumeinteractions.com Important: This message is intended for the recipient(s) addressed above. It contains privileged and confidential information. If you are not the intended recipient, please notify the sender immediately by replying to this message and then delete it from your system. You must not read, copy, use, or disseminate this communication in any form. Thank you.