German,

On Sat, Sep 13, 2008 at 1:13 AM, Germán Diago <germandiago@gmail.com> wrote:
Sorry for my mistakes in the code. I wrote very quickly. Anyway, I
think the basic idea
is understood. Please do take a look at the papers, I think the use
cases can be
understood.

I won't have time to dig into the second and third papers today (though I have read the second one recently, and you'll notice that I use the same types of techniques in the parameter_map class), but I do have a couple of questions:
  1. Could you send me the corrected version of your code? If I match the API for the "mistakes in the code", you won't get what you want :) It's not entirely clear which parts are mistakes and which are on purpose.
  2. What API would you prefer for exporting such classes?
  3. What are YOUR specific use cases? I know what the use cases of the authors are - but if it is those use cases that you need, you ought to use the code that they have written instead. Much of it is, I believe, open source.
What you propose seems to be a special case of the Adapter Pattern. In that case, perhaps it could be implemented something like the code I put into:

http://svn.boost.org/trac/boost/browser/sandbox/libs/extension/examples/value/

I threw this code together in less than ten minutes, meaning it doesn't support multi-parameter constructors and a few related things. The basic idea should be there though. Is this the type of thing you are looking for?

The declaration of the various boilerplate classes could certainly be shortened by using macros, but I'm not sure it's worth putting in as actual library functionality since many users might need highly specialized versions of the adapters (and because macros are ugly, and I need a really good reason to use them).

Jeremy Pack