[parameter] Avoiding the forwarding problem w/additional overloads

I've implemented a new macro, BOOST_PARAMETER_FUN2, that uses approach #3 mentioned in <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm>. For example, the BGL implementation of Dijkstra's algorithm <http://www.boost.org/libs/graph/doc/dijkstra_shortest_paths.html> can now be declared as: struct dijkstra_parameters : parameter::parameters<...> { } BOOST_PARAMETER_FUN2( void , dijkstra_shortest_paths , (0)(0)(1)(1)(0)(0)(0)(0)(0)(0)(1)(1) , 2 , dijkstra_parameters ) { ... } Each element in the Boost.Preprocessor sequence corresponds to a positional argument. If the element is set to 1, the argument is bound to an "out" parameter; otherwise it is bound to an "in" parameter. The size of the sequence is, of course, the total number of arguments accepted by the function. The macro argument following the sequence is the number of parameters required by the function. All other macro arguments are the same as the corresponding ones in BOOST_PARAMETER_FUN. The macro and example program are available in the "_Examples" directory of the Boost Vault, filename "boost_parameter_fun2_example.zip". GCC 3.4.2 (MinGW) compiles it cleanly, but MSVC 7.1 emits several instances of "warning C4003: not enough actual parameters for macro 'BOOST_PP_SEQ_SIZE_I'". (I know I shouldn't be passing BOOST_PP_EMPTY() to it, but replacing it with BOOST_PP_SEQ_NIL generates errors from both compilers. Fixes appreciated! Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1.34 will feature new macros in Boost.Parameter that have a significantly improved interface. Some of the syntax is demonstrated in this test: http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/parameter/... They also support in/out parameter overload generation, like what you have here. The syntax for this will be: BOOST_PARAMETER_FUNCTION((int), f, tag, (required (out(tester), *) ^^^ (name, *) ) ) Cromwell Enage wrote:
I've implemented a new macro, BOOST_PARAMETER_FUN2, that uses approach #3 mentioned in <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm>. For example, the BGL implementation of Dijkstra's algorithm <http://www.boost.org/libs/graph/doc/dijkstra_shortest_paths.html> can now be declared as:
struct dijkstra_parameters : parameter::parameters<...> { }
BOOST_PARAMETER_FUN2( void , dijkstra_shortest_paths , (0)(0)(1)(1)(0)(0)(0)(0)(0)(0)(1)(1) , 2 , dijkstra_parameters ) { ... }
Each element in the Boost.Preprocessor sequence corresponds to a positional argument. If the element is set to 1, the argument is bound to an "out" parameter; otherwise it is bound to an "in" parameter. The size of the sequence is, of course, the total number of arguments accepted by the function.
-- Daniel Wallin

--- Daniel Wallin wrote:
1.34 will feature new macros in Boost.Parameter that have a significantly improved interface. Some of the syntax is demonstrated in this test:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/parameter/... Wonderful! I'm curious as to how one would pass initializer lists to a Boost.Parameter enabled constructor. It looks like s/he would have to create a base class that handles all the initialization while the derived class, which is the frontend, passes on the arguments. Am I right? Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Cromwell Enage <sponage@yahoo.com> writes:
--- Daniel Wallin wrote:
1.34 will feature new macros in Boost.Parameter that have a significantly improved interface. Some of the syntax is demonstrated in this test:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/parameter/...
Wonderful!
I'm curious as to how one would pass initializer lists to a Boost.Parameter enabled constructor. It looks like s/he would have to create a base class that handles all the initialization while the derived class, which is the frontend, passes on the arguments. Am I right?
Yep. See libs/parameter/test/preprocessor.cpp -- Dave Abrahams Boost Consulting www.boost-consulting.com

Cromwell Enage wrote:
--- Daniel Wallin wrote:
1.34 will feature new macros in Boost.Parameter that have a significantly improved interface. Some of the syntax is demonstrated in this test:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/parameter/...
Wonderful!
I'm curious as to how one would pass initializer lists to a Boost.Parameter enabled constructor. It looks like s/he would have to create a base class that handles all the initialization while the derived class, which is the frontend, passes on the arguments. Am I right?
Yes, that's correct. I see two options for the constructor macros: 1) Delegate to base class constructor. 2) Two-step construction by delegating to init() member function. At this point only the first one is supported, because it's generally just a better way. I was going to implement the second one too, but I don't know if I have time and I'm not prioritizing it. -- Daniel Wallin

Daniel Wallin <dalwan01@student.umu.se> writes:
1.34 will feature new macros in Boost.Parameter that have a significantly improved interface. Some of the syntax is demonstrated in this test:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/parameter/...
They also support in/out parameter overload generation, like what you have here. The syntax for this will be:
BOOST_PARAMETER_FUNCTION((int), f, tag, (required (out(tester), *) ^^^ (name, *) ) )
Daniel did some really beautiful work on this stuff, I'd like to add. The library has now gone from being "cool" to "wicked cool." -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
Cromwell Enage
-
Daniel Wallin
-
David Abrahams