Re: [boost] Boost.Convert+Boost.Parameter

The keywords are decoupled. ... Did you read through the Boost.Parameter tutorial?
OK, I admit before I only glanced over the docs a couple of times. I thought I got the idea. Obviously not. :-( Now I printed it out and set down reading. Now I see the registration is all by itself and not coupled with anything. That's good. So, convert() can take those parameters in. Given we do not know how many parameters there might be I'd suggest we set those parameters with operator(). Like convert<string, int>(str)(default_ = -1)(throw_ = false)(some_other_parameter_ = ...) Given, convert() does not know and does not understand "some_other_parameter_" somebody else will need to do something with it. Who would that be and what would it do? I presume we could come up with a Boost.Parameter-based manipulator analog... or... no, I admit I am out of ideas. How can all that work? Thanks, Vladimir.

On Sun, Feb 22, 2009 at 12:39 PM, <Vladimir.Batov@wrsa.com.au> wrote:
The keywords are decoupled. ... Did you read through the Boost.Parameter tutorial?
OK, I admit before I only glanced over the docs a couple of times. I thought I got the idea. Obviously not. :-( Now I printed it out and set down reading. Now I see the registration is all by itself and not coupled with anything. That's good.
So, convert() can take those parameters in. Given we do not know how many parameters there might be I'd suggest we set those parameters with operator(). Like
convert<string, int>(str)(default_ = -1)(throw_ = false)(some_other_parameter_ = ...)
Given, convert() does not know and does not understand "some_other_parameter_" somebody else will need to do something with it. Who would that be and what would it do? I presume we could come up with a Boost.Parameter-based manipulator analog... or... no, I admit I am out of ideas. How can all that work?
It would be nice if a function (for example convert) could understand the parameters it is given, wouldn't it? :) It seems like you want convert to be as generic as: result convert( parameters ) which is almost as generic as: result f( parameters ) This is really in the domain of programming languages, not an interface expressed in C++. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

I spent some time reading Boost.Parameter docs and I hope I am getting a hang of it. Am I right thinking that in order to call convert<string, int>(str, default_ = -1) we are essentially creating "default_" on a side that we pass a reference to later? If so, am I right thinking that we might have a multi-threading safety issue if the call as above is called from two threads? Don't we have two threads assigning/accessing the same variable? Could that be an issue? Has it been looked into? Thanks, Vladimir.

on Sun Feb 22 2009, "Vladimir Batov" <batov-AT-people.net.au> wrote:
I spent some time reading Boost.Parameter docs and I hope I am getting a hang of it. Am I right thinking that in order to call
convert<string, int>(str, default_ = -1)
we are essentially creating "default_" on a side that we pass a reference to later? If so, am I right thinking that we might have a multi-threading safety issue if the call as above is called from two threads? Don't we have two threads assigning/accessing the same variable? Could that be an issue?
No. That assignment doesn't assign a variable; it creates a binding. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

convert<string, int>(str, default_ = -1)
No. That assignment doesn't assign a variable; it creates a binding.
Dave, I am glad you are confident there is no MT issue here. Apologies for being somewhat obtuse but what I see is namespace convert { BOOST_PARAMETER_NAME(value) } results in namespace convert { namespace tag { struct value; } // keyword tag type namespace // unnamed { // A reference to the keyword object boost::parameter::keyword<tag::value>& _value = boost::parameter::keyword<tag::value>::get(); } } My interpretation of the code above that it is a declaration of "_value" as a reference. Then, I call the same thing twice as below: convert<string, int>(str, _value = -1); convert<string, int>(str, _value = -2); Does not the *same* _value reference is used in *both* calls? I.e. after the first call "_value" references -1 and after the second call it references -2. If so, then, when two calls above called from different threads we might have a problem, isn't it? If it is not the case, I am really curious how you, guys, did that, it is surely looks magic. Any pointers, additional docs, anything? Thanks, V.

AMDG Vladimir Batov wrote:
My interpretation of the code above that it is a declaration of "_value" as a reference. Then, I call the same thing twice as below:
convert<string, int>(str, _value = -1); convert<string, int>(str, _value = -2);
Does not the *same* _value reference is used in *both* calls? I.e. after the first call "_value" references -1 and after the second call it references -2. If so, then, when two calls above called from different threads we might have a problem, isn't it? If it is not the case, I am really curious how you, guys, did that, it is surely looks magic. Any pointers, additional docs, anything?
Assignment is overloaded to return an argument pack rather than storing the value in a global location. Everything you need is encoded in the return type of _value = -1. the actual object _value is stateless. In Christ, Steven Watanabe

From: "Steven Watanabe" <watanabesj@gmail.com>
Assignment is overloaded to return an argument pack rather than storing the value in a global location. Everything you need is encoded in the return type of _value = -1. the actual object _value is stateless.
Thanks. I'll dig further to see how all that works. Thank you, V.

Vladimir.Batov@wrsa.com.au wrote:
So, convert() can take those parameters in. Given we do not know how many parameters there might be I'd suggest we set those parameters with operator(). Like
convert<string, int>(str)(default_ = -1)(throw_ = false)(some_other_parameter_ = ...)
There's no need for that clumsy syntax. The Boost.Parameter keywords already provide the operator, overload, so you can write: convert< string >((param1 = val1, param2 = val2, ...)); ...and so on for as many parameters you like. Note the double parenthesis. The "convert" function here accepts only _one_ argument, which is basically a tuple of references to the argument values with a fancy syntax for retrieving them: template< typename ToT, typename ArgsT > ToT convert(ArgsT const& args) { int p1 = args[param1]; // mandatory string p2 = args[param2 | "ouch"]; // optional } Boost.Parameter also provide macros that allow to declare the "convert" function in order to elide the need of the double parenthesis and to even allow to mix the positional arguments with named ones.
participants (6)
-
Andrey Semashev
-
David Abrahams
-
Emil Dotchevski
-
Steven Watanabe
-
Vladimir Batov
-
Vladimir.Batov@wrsa.com.au