on Sat Oct 22 2011, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:
On Fri, Sep 2, 2011 at 3:14 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Fri Sep 02 2011, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:
(I still have to implement named parameter support (using Boost.Parameter behind the scene) but that shouldn't be too hard. The macros already parse the named parameter syntax using in/out/inout "keywords".)
I can't wait.
Hello all,
Here's how I am thinking to support named parameters within Boost.Contract's syntax.
Cool! Don't forget deduced parameters, though ;-)
Essentially, named (also template) parameters are prefixed by the new preprocessor "keywords" in, out, or in out.
Sorry for the large amount of code but these are complex examples from Boost.Parameter docs so you can directly compare this Boost.Contract proposed syntax with the one of Boost.Parameter: http://www.boost.org/doc/libs/1_47_0/libs/parameter/doc/html/index.html
namespace graphs {
BOOST_PARAMETER_NAME(graph) BOOST_PARAMETER_NAME(visitor) BOOST_PARAMETER_NAME(root_vertex) BOOST_PARAMETER_NAME(index_map) BOOST_PARAMETER_NAME(color_map)
CONTRACT_FUNCTION( void (depth_first_search) ( namespace tag, // optional namespace (tag assumed by default)
I'd really like to eliminate that if possible; it's quite off-putting. I guess if you can make it optional, that handles the problem.
in requires( // requires for type requirements
Why are we using "in" before "requires?" Requirements are not "in parameters."
boost::mpl::and_< boost::is_convertible< boost::graph_traits<boost::mpl::_>::traversal_category , boost::indicence_grapth_tag > , boost::is_convertible< boost::graph_traits<boost::mpl::_>::traversal_category , boost::vertex_list_graph_tag > >
I realize this is a direct translation of what's in the Boost.Parameter docs, but it would be instructive to see the example without all the mess, using something like concepts for the "requires" clause. In fact, I believe much of what you have below could also be consolidated into something more semantically meaningful. Would something like that be possible? Also, the use of graphs::graph::_ and boost::mpl::_ below is confusing me. I've never heard of the former. I guess, to sum up, to evaluate the syntax I'd need to see the most beautiful possible realization of this algorithm as opposed to the most horrendous ;-).
And for class templates:
namespace py {
BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType) BOOST_PARAMETER_TEMPLATE_KEYWORD(BaseList) BOOST_PARAMETER_TEMPLATE_KEYWORD(HeldType) BOOST_PARAMETER_TEMPLATE_KEYWORD(Copyable)
CONTRACT_CLASS( template( in typename ClassType, in typename BaseList, default boost::python::bases<>, in typename HeldType, default ValueType, in typename Copyable, default void ) class (class_) requires(...) // concepts ) { ... // class invariants, members with pre/postconditions, etc };
} // namespace py
struct b { virtual ~b() = 0; } struct d : b { ~d(); }
typedef py::class_<b, boost::noncopyalbe> c1; typedef py::class_< d, std::auto_ptr<d>, boost::python::bases<b> > c2;
This one, again, uses deduced parameters, because as I'm sure you noticed, boost::noncopyable doesn't play the same role as std::auto_ptr<d>. I presume that's possible in your scheme.
IF I can do this (not sure yet), it should be beneficial especially for class templates because all the boiler plate code (class template skeleton A0, A1 = parameter::void_, class template signature, argument pack, and parameter extraction) will be automatically generated by the CONTRACT_CLASS macro.
Before I start diving into the implementation, what do you think of this syntax for named parameters?
Certainly looks nice for the class template case, but as noted above I'm having a hard time digesting the function template example. -- Dave Abrahams BoostPro Computing http://www.boostpro.com