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. 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) in requires( // requires for type requirements 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 > > ) graph, // this is required (because it has no default) in auto visitor, default boost::dfs_visitor<>(), // auto for any type `*` in (typename boost::graph_traits<graphs::graph::_>::vertex_descriptor) root_vertex, default *boost::vertices(graph).first, // with default so optional in requires( boost::mpl::and_< boost::is_integral< boost::property_traits<boost::mpl::_>::value_type > , boost::is_same< typename boost::graph_traits<graphs::graph::_>:: vertex_descriptor , boost::property_traits<boost::mpl::_>::key_type > > ) index_map, default boost::get(boost::vertex_index, graph), in out requires( boost::is_same< typename boost::graph_traits<graphs::graph::_>:: vertex_descriptor , boost::property_traits<boost::mpl::_>::key_type > ) color_map, default default_color_map(boost::num_vertices(graph), index_map) ) precondition(...) postcondition(...) ) { ... } } // namespace graphs 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; 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? Thanks a lot. --Lorenzo