Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-17 18:47:46

Matt Hurd <matt.hurd_at_[hidden]> writes:

>>David Abrahams <dave_at_[hidden]> wrote:
>> Daniel James <daniel_at_[hidden]> writes:
>> > Sorry, another feature request. Would it be possible/a good idea to
>> > add a way to get the type of a named parameter?
>> Certainly it's possible. Not sure if it's a good idea. Is there a
>> use case? Some people are complaining that the library is already
>> heavy artillery where none is needed.
> A use case I have that I'm not sure how best to approach, but would
> find incredibly useful, with named_params is using a compile time
> policy to support switching between:
> 1. direct function call
> 2. an indirection to the function call, such as the marshalling and
> transmission of the function parameters, including formal parameter
> names, to a target.
> To do this, named_params needs to support an interface for iterating
> over the parameters.

Why iterating?

> Getting type info and formal parameter names may
> help some styles of indirection.

"may help some styles...?" Doesn't sound like a strong argument for
introducing a new feature, to me.

> For example, matching the type to a
> specific transport's marshalling routine for the same type.
> The goal is being able to re-architect applications by simply changing
> policies at key workflow points in an application. Change from a
> function call, to a threaded work pool, to a call to a separate
> process, to a call to a separate machine via a udp/tcp or even tib rv.
> I see named_params as a key piece of the puzzle in enabling this.

I don't understand the relationship at all. Why not just use an
explicitly-secified function template parameter?

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at