[parameter] Avoiding the forwarding problem w/additional overloads

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[parameter] Avoiding the forwarding problem w/additional overloads

Cromwell Enage
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 
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [parameter] Avoiding the forwarding problem w/additional overloads

Daniel Wallin
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/test/preprocessor.cpp

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [parameter] Avoiding the forwarding problem w/additional overloads

Cromwell Enage
--- 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/test/preprocessor.cpp

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 
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [parameter] Avoiding the forwarding problem w/additional overloads

David Abrahams
In reply to this post by Daniel Wallin
Daniel Wallin <[hidden email]> 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/test/preprocessor.cpp
>
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [parameter] Avoiding the forwarding problem w/additional overloads

David Abrahams
In reply to this post by Cromwell Enage
Cromwell Enage <[hidden email]> 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/test/preprocessor.cpp
>
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [parameter] Avoiding the forwarding problem w/additional overloads

Daniel Wallin
In reply to this post by Cromwell Enage
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/test/preprocessor.cpp
>
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost