Re: [Boost-users] Re: (newbie) design question (is there an MPL solution?)

On Aug 10, 2004, at 4:12 PM, David Abrahams wrote:

Timothy Perrigo writes:

...

Dave wrote:

...

Need more info.

Does each id map to just one type, or might there be different types using the same ID in different registries of type R?

Is the id a runtime value, or is it known at compile-time?

Thanks for the reply...I'll try to give as much background information as I can without clouding the issue. We're working on a constraint processing system. Particular problems will be modeled with variables with values within certain domains and subject to certain constraints. These constraints, when propagated, will narrow the domains of the variables, but some form of searching will be required to bind all the variables to values and find a feasible solution. The idea behind the registry I mentioned is for it to serve as a snapshot of the current state of the system (at a specific point in a search, for example). The "same" variables will exist in different registries, but may have different domains since their sets of possible values may have been reduced due to decisions made during the search.

Actually all that background info clouds the issue. Sorry...I was afraid of that!

...

So to answer your first question, a particular id will always correspond to a variable of a given type, though its value at that point in time (i.e, in that registry) may differ from the same variable in a different registry.

OK.

...

Right now, the id is a runtime value; whenever a new constrained variable is created, it is given a new id.

But does it *need* to be a runtime value? If so, something like Gennadiy's solution is the only choice. If not, you can do something much more efficient with MPL.

It may be possible to design things so that the ids of the variables are known at compile time...If so, do you have any thoughts on how we could accomplish this using MPL? I'm excited about learning more about metaprogramming, so I'd welcome any suggestions or advice. Thanks again, Tim