1 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 The Boost Parameter Library
3 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
7 .. |(logo)| image:: ../../../../boost.png
10 __ ../../../../index.htm
12 -------------------------------------
14 :Abstract: Use this library to write functions and class templates that can
15 accept arguments by name:
27 , **deleter<Deallocate<Foo> >**
28 , **copy_policy<DeepCopy>**
31 Since named arguments can be passed in any order, they are especially useful
32 when a function or template has more than one parameter with a useful default
33 value. The library also supports *deduced* parameters: that is to say,
34 parameters whose identity can be deduced from their types.
36 .. @jam_prefix.append('''
38 : requirements <include>. <implicit-dependency>/boost//headers ;
41 .. @example.prepend('''
42 #include <boost/parameter.hpp>
46 BOOST_PARAMETER_NAME(title)
47 BOOST_PARAMETER_NAME(width)
48 BOOST_PARAMETER_NAME(titlebar)
50 BOOST_PARAMETER_FUNCTION(
51 (int), new_window, tag, (required (title,*)(width,*)(titlebar,*))
57 BOOST_PARAMETER_TEMPLATE_KEYWORD(deleter)
58 BOOST_PARAMETER_TEMPLATE_KEYWORD(copy_policy)
69 namespace parameter = boost::parameter;
75 template <typename T, typename A0, typename A1>
88 -------------------------------------
90 :Authors: David Abrahams, Daniel Wallin
91 :Contact: dave@boost-consulting.com, daniel@boostpro.com
92 :organization: `BoostPro Computing`_
93 :date: $Date: 2005/07/17 19:53:01 $
95 :copyright: Copyright David Abrahams, Daniel Wallin
96 2005-2009. Distributed under the Boost Software License,
97 Version 1.0. (See accompanying file LICENSE_1_0.txt
98 or copy at http://www.boost.org/LICENSE_1_0.txt)
100 .. _`BoostPro Computing`: http://www.boostpro.com
102 .. _concepts: http://www.boost.org/more/generic_programming.html#concept
104 -------------------------------------
106 [Note: this tutorial does not cover all details of the library. Please see
107 also the `reference documentation`__\ ]
111 .. contents:: **Table of Contents**
120 .. section-numbering::
122 -------------------------------------
128 In C++, arguments_ are normally given meaning by their positions with respect
129 to a parameter_ list: the first argument passed maps onto the first parameter
130 in a function's definition, and so on. That protocol is fine when there is at
131 most one parameter with a default value, but when there are even a few useful
132 defaults, the positional interface becomes burdensome:
136 Since an argument's meaning is given by its position, we have to choose an
137 (often arbitrary) order for parameters with default values, making some
138 combinations of defaults unusable:
144 , **int border_width = default_border_width**
145 , bool movable = true
146 , bool initially_visible = true
149 bool const movability = false;
150 window* w = new_window("alert box", movability);
152 In the example above we wanted to make an unmoveable window with a default
153 ``border_width``, but instead we got a moveable window with a
154 ``border_width`` of zero. To get the desired effect, we'd need to write:
158 window* w = new_window(
159 "alert box", **default_border_width**, movability
164 It can become difficult for readers to understand the meaning of arguments
167 window* w = new_window("alert", 1, true, false);
169 Is this window moveable and initially invisible, or unmoveable and
170 initially visible? The reader needs to remember the order of arguments to
173 * The author of the call may not remember the order of the arguments either,
174 leading to hard-to-find bugs.
178 -------------------------
179 Named Function Parameters
180 -------------------------
184 This library addresses the problems outlined above by associating each
185 parameter name with a keyword object. Now users can identify arguments by
186 name, rather than by position:
190 window* w = new_window(
192 , **movable_=**\ false
197 ---------------------------
198 Deduced Function Parameters
199 ---------------------------
203 A **deduced parameter** can be passed in any position *without* supplying
204 an explicit parameter name. It's not uncommon for a function to have
205 parameters that can be uniquely identified based on the types of arguments
206 passed. The ``name`` parameter to ``new_window`` is one such
207 example. None of the other arguments, if valid, can reasonably be
208 converted to a ``char const*``. With a deduced parameter interface, we
209 could pass the window name in *any* argument position without causing
214 window* w = new_window(
218 window* w = new_window(
223 Appropriately used, a deduced parameter interface can free the user of the
224 burden of even remembering the formal parameter names.
228 --------------------------------
229 Class Template Parameter Support
230 --------------------------------
234 The reasoning we've given for named and deduced parameter interfaces
235 applies equally well to class templates as it does to functions. Using
236 the Parameter library, we can create interfaces that allow template
237 arguments (in this case ``shared`` and ``Client``) to be explicitly named,
243 **ownership<shared>**
244 , **value_type<Client>**
247 The syntax for passing named template arguments is not quite as natural as
248 it is for function arguments (ideally, we'd be able to write
249 ``smart_ptr<ownership = shared, …>``). This small syntactic deficiency
250 makes deduced parameters an especially big win when used with class
255 // *p and q could be equivalent, given a deduced*
256 // *parameter interface.*
257 smart_ptr<**shared**, **Client**> p;
258 smart_ptr<**Client**, **shared**> q;
266 This tutorial shows all the basics—how to build both named- and
267 deduced-parameter interfaces to function templates and class
268 templates—and several more advanced idioms as well.
270 ---------------------------
271 Parameter-Enabled Functions
272 ---------------------------
274 In this section we'll show how the Parameter library can be used to
275 build an expressive interface to the `Boost Graph library`__\ 's
276 |dfs|_ algorithm. [#old_interface]_
280 After laying some groundwork and describing the algorithm's abstract
281 interface, we'll show you how to build a basic implementation with keyword
282 support. Then we'll add support for default arguments and we'll gradually
283 refine the implementation with syntax improvements. Finally we'll show
284 how to streamline the implementation of named parameter interfaces,
285 improve their participation in overload resolution, and optimize their
288 __ ../../../graph/doc/index.html
290 .. _dfs: ../../../graph/doc/depth_first_search.html
292 .. |dfs| replace:: ``depth_first_search``
295 Headers And Namespaces
296 ======================
298 Most components of the Parameter library are declared in a header named for
299 the component. For example, ::
301 #include <boost/parameter/keyword.hpp>
303 will ensure ``boost::parameter::keyword`` is known to the compiler. There
304 is also a combined header, ``boost/parameter.hpp``, that includes most of
305 the library's components. For the the rest of this tutorial, unless we
306 say otherwise, you can use the rule above to figure out which header to
307 ``#include`` to access any given component of the library.
309 .. @example.append('''
310 using boost::parameter::keyword;
315 Also, the examples below will also be written as if the namespace alias ::
317 namespace parameter = boost::parameter;
321 has been declared: we'll write ``parameter::xxx`` instead of
322 ``boost::parameter::xxx``.
324 The Abstract Interface to |dfs|
325 ===============================
327 The Graph library's |dfs| algorithm is a generic function accepting
328 from one to four arguments by reference. If all arguments were
329 required, its signature might be as follows::
333 , typename DFSVisitor
341 , typename graph_traits<g>::vertex_descriptor root_vertex
348 However, most of the parameters have a useful default value,
349 as shown in the table below.
351 .. _`parameter table`:
352 .. _`default expressions`:
354 .. table:: ``depth_first_search`` Parameters
356 +-----------------+------+-------------------------+------------------------------------+
357 | Parameter | Data | Type | Default Value |
358 | Name | Flow | | (if any) |
359 +=================+======+=========================+====================================+
360 | ``graph`` | in | Model of | none - this argument is required. |
361 | | | |IncidenceGraph|_ and | |
362 | | | |VertexListGraph|_ | |
363 +-----------------+------+-------------------------+------------------------------------+
364 | ``visitor`` | in | Model of |DFSVisitor|_ | ``boost::dfs_visitor<>()`` |
365 +-----------------+------+-------------------------+------------------------------------+
366 | ``root_vertex`` | in | ``graph``'s vertex | ``*vertices(graph).first`` |
367 | | | descriptor type. | |
368 +-----------------+------+-------------------------+------------------------------------+
369 | ``index_map`` | in | Model of | ``get(boost::vertex_index,graph)`` |
370 | | | |ReadablePropertyMap|_ | |
371 | | | with key type := | |
372 | | | ``graph``'s vertex | |
373 | | | descriptor and value | |
374 | | | type an integer type. | |
375 +-----------------+------+-------------------------+------------------------------------+
376 | ``color_map`` | in / | Model of | a ``boost::iterator_property_map`` |
377 | | out | |ReadWritePropertyMap|_ | created from a ``std::vector`` of |
378 | | | with key type := | ``default_color_type`` of size |
379 | | | ``graph``'s vertex | ``num_vertices(graph)`` and using |
380 | | | descriptor type. | ``index_map`` for the index map. |
381 +-----------------+------+-------------------------+------------------------------------+
383 .. |IncidenceGraph| replace:: :concept:`Incidence Graph`
384 .. |VertexListGraph| replace:: :concept:`Vertex List Graph`
385 .. |DFSVisitor| replace:: :concept:`DFS Visitor`
386 .. |ReadablePropertyMap| replace:: :concept:`Readable Property Map`
387 .. |ReadWritePropertyMap| replace:: :concept:`Read/Write Property Map`
389 .. _`IncidenceGraph`: ../../../graph/doc/IncidenceGraph.html
390 .. _`VertexListGraph`: ../../../graph/doc/VertexListGraph.html
391 .. _`DFSVisitor`: ../../../graph/doc/DFSVisitor.html
392 .. _`ReadWritePropertyMap`: ../../../property_map/doc/ReadWritePropertyMap.html
393 .. _`ReadablePropertyMap`: ../../../property_map/doc/ReadablePropertyMap.html
395 Don't be intimidated by the information in the second and third columns
396 above. For the purposes of this exercise, you don't need to understand
399 Defining the Keywords
400 =====================
402 The point of this exercise is to make it possible to call
403 ``depth_first_search`` with named arguments, leaving out any
404 arguments for which the default is appropriate:
408 graphs::depth_first_search(g, **color_map_=my_color_map**);
412 To make that syntax legal, there needs to be an object called
413 “\ ``color_map_``\ ” whose assignment operator can accept a
414 ``my_color_map`` argument. In this step we'll create one such
415 **keyword object** for each parameter. Each keyword object will be
416 identified by a unique **keyword tag type**.
420 We're going to define our interface in namespace ``graphs``. Since users
421 need access to the keyword objects, but not the tag types, we'll define
422 the keyword objects so they're accessible through ``graphs``, and we'll
423 hide the tag types away in a nested namespace, ``graphs::tag``. The
424 library provides a convenient macro for that purpose.
426 We're going to define our interface in namespace ``graphs``. The
427 library provides a convenient macro for defining keyword objects::
429 #include <boost/parameter/name.hpp>
433 BOOST_PARAMETER_NAME(graph) // Note: no semicolon
434 BOOST_PARAMETER_NAME(visitor)
435 BOOST_PARAMETER_NAME(root_vertex)
436 BOOST_PARAMETER_NAME(index_map)
437 BOOST_PARAMETER_NAME(color_map)
442 The declaration of the ``graph`` keyword you see here is equivalent to::
450 typedef boost::parameter::forward_reference qualifier;
456 // A reference to the keyword object
457 boost::parameter::keyword<tag::graph> const& _graph
458 = boost::parameter::keyword<tag::graph>::instance;
462 .. @example.prepend('#include <boost/parameter/keyword.hpp>')
465 It defines a *keyword tag type* named ``tag::graph`` and a *keyword object*
466 reference named ``_graph``.
468 This “fancy dance” involving an unnamed namespace and references is all done
469 to avoid violating the One Definition Rule (ODR) [#odr]_ when the named
470 parameter interface is used by function templates that are instantiated in
471 multiple translation units (MSVC6.x users see `this note`__).
473 __ `Compiler Can't See References In Unnamed Namespace`_
478 Now that we have our keywords defined, the function template definition
479 follows a simple pattern using the ``BOOST_PARAMETER_FUNCTION`` macro::
481 #include <boost/parameter/preprocessor.hpp>
485 BOOST_PARAMETER_FUNCTION(
486 (void), // 1. parenthesized return type
487 depth_first_search, // 2. name of the function template
488 tag, // 3. namespace of tag types
489 (required (graph, *) ) // 4. one required parameter, and
490 (optional // four optional parameters,
492 (visitor, *, boost::dfs_visitor<>())
493 (root_vertex, *, *vertices(graph).first)
494 (index_map, *, get(boost::vertex_index,graph))
496 default_color_map(num_vertices(graph), index_map)
501 // ... body of function goes here...
502 // use graph, visitor, index_map, and color_map
506 .. @example.prepend('''
507 #include <boost/parameter/name.hpp>
509 BOOST_PARAMETER_NAME(graph)
510 BOOST_PARAMETER_NAME(visitor)
511 BOOST_PARAMETER_NAME(in(root_vertex))
512 BOOST_PARAMETER_NAME(in(index_map))
513 BOOST_PARAMETER_NAME(in_out(color_map))
517 template <typename T = int>
522 int vertex_index = 0;
528 The arguments to ``BOOST_PARAMETER_FUNCTION`` are:
530 1. The return type of the resulting function template. Parentheses around
531 the return type prevent any commas it might contain from confusing the
532 preprocessor, and are always required.
534 2. The name of the resulting function template.
536 3. The name of a namespace where we can find tag types whose names match the
537 function's parameter names.
539 4. The function signature.
544 Function signatures are described as one or two adjacent parenthesized terms
545 (a Boost.Preprocessor_ sequence_) describing the function's parameters in the
546 order in which they'd be expected if passed positionally. Any required
547 parameters must come first, but the ``(required … )`` clause can be omitted
548 when all the parameters are optional.
550 .. _Boost.Preprocessor: ../../../preprocessor/doc/index.html
551 .. _sequence: http://boost-consulting.com/mplbook/preprocessor.html#sequences
558 Required parameters are given first—nested in a ``(required … )``
559 clause—as a series of two-element tuples describing each parameter name
560 and any requirements on the argument type. In this case there is only a
561 single required parameter, so there's just a single tuple:
565 (required **(graph, \*)** )
567 Since ``depth_first_search`` doesn't require any particular type for its
568 ``graph`` parameter, we use an asterix to indicate that any type is
569 allowed. Required parameters must always precede any optional parameters
570 in a signature, but if there are *no* required parameters, the
571 ``(required … )`` clause can be omitted entirely.
573 .. @example.prepend('''
574 #include <boost/parameter.hpp>
576 BOOST_PARAMETER_NAME(graph)
578 BOOST_PARAMETER_FUNCTION((void), f, tag,
581 .. @example.append(') {}')
589 Optional parameters—nested in an ``(optional … )`` clause—are given as a
590 series of adjacent *three*\ -element tuples describing the parameter name,
591 any requirements on the argument type, *and* and an expression
592 representing the parameter's default value:
597 **(visitor, \*, boost::dfs_visitor<>())
598 (root_vertex, \*, \*vertices(graph).first)
599 (index_map, \*, get(boost::vertex_index,graph))
601 default_color_map(num_vertices(graph), index_map)
605 .. @example.prepend('''
606 #include <boost/parameter.hpp>
610 int vertex_index = 0;
612 template <typename T = int>
618 BOOST_PARAMETER_NAME(graph)
619 BOOST_PARAMETER_NAME(visitor)
620 BOOST_PARAMETER_NAME(in(root_vertex))
621 BOOST_PARAMETER_NAME(in(index_map))
622 BOOST_PARAMETER_NAME(in_out(color_map))
624 BOOST_PARAMETER_FUNCTION((void), f, tag,
625 (required (graph, \*))
628 .. @example.append(') {}')
631 Handling “In”, “Out”, “Consume / Move-From”, and “Forward” Parameters
632 ---------------------------------------------------------------------
636 By default, Boost.Parameter treats all parameters as if they were
637 *forward* `parameters`_, which functions would take in by rvalue reference
638 and only ``std::forward`` or ``boost::forward`` to other functions. Such
639 parameters can be ``const`` lvalues, mutable lvalues, ``const`` rvalues,
640 or mutable rvalues. Therefore, the default configuration grants the most
641 flexibility to user code. However:
643 * Users can configure one or more parameters to be *in* `parameters`_,
644 which can fall into the same categories as *forward* `parameters`_ but
645 are now passed by ``const`` lvalue reference and so must only be read
646 from. Continuing from the previous example, to indicate that
647 ``root_vertex`` and ``index_map`` are read-only, we wrap their names
650 * Users can configure one or more parameters to be either *out*
651 `parameters`_, which functions would strictly write to, or *in-out*
652 `parameters`_, which functions would both read from and write
653 to. Such parameters can only be mutable lvalues. In the example, to
654 indicate that ``color_map`` is read-write, we wrap its name in
655 ``in_out(…)``. Note that Boost.Parameter sees no functional
656 difference between ``out(…)`` and ``in_out(…)``, so you may choose
657 whichever makes your interfaces more self-documenting.
659 * Users can configure one or more parameters to be *consume* or
660 *move-from* `parameters`_, which functions would take in by mutable
661 rvalue reference and ``std::move`` or ``boost::move`` as the last
662 access step. Such parameters can only be mutable
663 rvalues. Boost.Parameter supports wrapping the corresponding names in
664 ``consume(…)`` or ``move_from(…)``.
668 BOOST_PARAMETER_NAME(graph)
669 BOOST_PARAMETER_NAME(visitor)
670 BOOST_PARAMETER_NAME(**in(root_vertex)**)
671 BOOST_PARAMETER_NAME(**in(index_map)**)
672 BOOST_PARAMETER_NAME(**in_out(color_map)**)
674 In order to see what happens when parameters are bound to arguments that
675 violate their category constraints, attempt to compile the |compose_cpp|_
676 test program with either the ``LIBS_PARAMETER_TEST_COMPILE_FAILURE_0``
677 macro or the ``LIBS_PARAMETER_TEST_COMPILE_FAILURE_1`` macro
678 ``#defined``. You should encounter a compiler error caused by a specific
679 constraint violation.
681 .. @example.prepend('''
682 #include <boost/parameter.hpp>
686 int vertex_index = 0;
688 template <typename T = int>
695 .. @example.append('''
696 BOOST_PARAMETER_FUNCTION((void), f, tag,
697 (required (graph, \*))
699 (visitor, \*, boost::dfs_visitor<>())
700 (root_vertex, \*, \*vertices(graph).first)
701 (index_map, \*, get(boost::vertex_index, graph))
703 default_color_map(num_vertices(graph), index_map)
713 .. _`parameters`: http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters
714 .. |compose_cpp| replace:: compose.cpp
715 .. _compose_cpp: ../../test/compose.cpp
720 When arguments are passed positionally (without the use of keywords), they
721 will be mapped onto parameters in the order the parameters are given in the
722 signature, so for example in this call ::
724 graphs::depth_first_search(x, y);
728 ``x`` will always be interpreted as a graph and ``y`` will always be
729 interpreted as a visitor.
731 Default Expression Evaluation
732 -----------------------------
736 Note that in our example, the value of the graph parameter is used in the
737 default expressions for ``root_vertex``, ``index_map``, and ``color_map``.
741 (required (**graph**, \*) )
743 (visitor, \*, boost::dfs_visitor<>())
744 (root_vertex, \*, \*vertices(**graph**).first)
745 (index_map, \*, get(boost::vertex_index, **graph**))
747 default_color_map(num_vertices(**graph**), index_map)
753 A default expression is evaluated in the context of all preceding
754 parameters, so you can use any of their values by name.
758 A default expression is never evaluated—or even instantiated—if an actual
759 argument is passed for that parameter. We can actually demonstrate that
760 with our code so far by replacing the body of ``depth_first_search`` with
761 something that prints the arguments:
765 #include <boost/graph/depth_first_search.hpp> // for dfs_visitor
767 BOOST_PARAMETER_FUNCTION(
768 (bool), depth_first_search, tag
769 *…signature goes here…*
772 std::cout << "graph=" << graph;
773 std::cout << std::endl;
774 std::cout << "visitor=" << visitor;
775 std::cout << std::endl;
776 std::cout << "root_vertex=" << root_vertex;
777 std::cout << std::endl;
778 std::cout << "index_map=" << index_map;
779 std::cout << std::endl;
780 std::cout << "color_map=" << color_map;
781 std::cout << std::endl;
785 #include <boost/core/lightweight_test.hpp>
789 char const\* g = "1";
790 depth_first_search(1, 2, 3, 4, 5);
792 g, '2', _color_map = '5',
793 _index_map = "4", _root_vertex = "3"
795 return boost::report_errors();
798 Despite the fact that default expressions such as
799 ``vertices(graph).first`` are ill-formed for the given ``graph``
800 arguments, both calls will compile, and each one will print exactly the
803 .. @example.prepend('''
804 #include <boost/parameter.hpp>
807 BOOST_PARAMETER_NAME(graph)
808 BOOST_PARAMETER_NAME(visitor)
809 BOOST_PARAMETER_NAME(root_vertex)
810 BOOST_PARAMETER_NAME(index_map)
811 BOOST_PARAMETER_NAME(color_map)
814 .. @example.replace_emphasis('''
825 Signature Matching and Overloading
826 ----------------------------------
828 In fact, the function signature is so general that any call to
829 ``depth_first_search`` with fewer than five arguments will match our function,
830 provided we pass *something* for the required ``graph`` parameter. That might
831 not seem to be a problem at first; after all, if the arguments don't match the
832 requirements imposed by the implementation of ``depth_first_search``, a
833 compilation error will occur later, when its body is instantiated.
835 There are at least three problems with very general function signatures.
837 1. By the time our ``depth_first_search`` is instantiated, it has been
838 selected as the best matching overload. Some other ``depth_first_search``
839 overload might've worked had it been chosen instead. By the time we see a
840 compilation error, there's no chance to change that decision.
842 2. Even if there are no overloads, error messages generated at instantiation
843 time usually expose users to confusing implementation details. For
844 example, users might see references to names generated by
845 ``BOOST_PARAMETER_FUNCTION`` such as
846 ``graphs::detail::depth_first_search_with_named_params`` (or worse—think
847 of the kinds of errors you get from your STL implementation when you make
848 a mistake). [#ConceptsTS]_
850 3. The problems with exposing such permissive function template signatures
851 have been the subject of much discussion, especially in the presence of
852 `unqualified calls`__. If all we want is to avoid unintentional
853 argument-dependent lookup (ADL), we can isolate ``depth_first_search`` in
854 a namespace containing no types [#using]_, but suppose we *want* it to
857 __ http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225
859 It's usually a good idea to prevent functions from being considered for
860 overload resolution when the passed argument types aren't appropriate. The
861 library already does this when the required ``graph`` parameter is not
862 supplied, but we're not likely to see a depth first search that doesn't take a
863 graph to operate on. Suppose, instead, that we found a different depth first
864 search algorithm that could work on graphs that don't model
865 |IncidenceGraph|_? If we just added a simple overload, it would be
869 BOOST_PARAMETER_FUNCTION((void), depth_first_search, (tag),
870 (required (graph,*))( … )
873 // new algorithm implementation
879 depth_first_search(boost::adjacency_list<>(), 2, "hello");
883 Predicate Requirements
884 ......................
886 We really don't want the compiler to consider the original version of
887 ``depth_first_search`` because the ``root_vertex`` argument, ``"hello"``,
888 doesn't meet the requirement__ that it match the ``graph`` parameter's vertex
889 descriptor type. Instead, this call should just invoke our new overload. To
890 take the original ``depth_first_search`` overload out of contention, we first
891 encode this requirement as follows:
893 __ `parameter table`_
897 struct vertex_descriptor_predicate
899 template <typename T, typename Args>
902 boost::is_convertible<
904 , typename boost::graph_traits<
905 typename boost::parameter::value_type<
912 , boost::mpl::false\_
918 This encoding is an `MPL Binary Metafunction Class`__, a type with a nested
919 ``apply`` metafunction that takes in two template arguments. For the first
920 template argument, Boost.Parameter will pass in the type on which we will
921 impose the requirement. For the second template argument, Boost.Parameter
922 will pass in the entire argument pack, making it possible to extract the
923 type of each of the other ``depth_first_search`` parameters via the
924 ``value_type`` metafunction and the corresponding keyword tag type. The
925 result ``type`` of the ``apply`` metafunction will be equivalent to
926 ``boost::mpl::true_`` if ``T`` fulfills our requirement as imposed by the
927 ``boost::is_convertible`` statement; otherwise, the result will be
928 equivalent to ``boost::mpl::false_``.
930 __ ../../../mpl/doc/refmanual/metafunction-class.html
932 At this point, we can append the name of our metafunction class, in
933 parentheses, to the appropriate ``*`` element of the function signature.
938 , \*(**vertex_descriptor_predicate**)
939 , \*vertices(graph).first
944 Now the original ``depth_first_search`` will only be called when the
945 ``root_vertex`` argument can be converted to the graph's vertex descriptor
946 type, and our example that *was* ambiguous will smoothly call the new
949 We can encode the requirements on other arguments using the same concept; only
950 the implementation of the nested ``apply`` metafunction needs to be tweaked
951 for each argument. There's no space to give a complete description of graph
952 library details here, but suffice it to show that the next few metafunction
953 classes provide the necessary checks.
957 struct graph_predicate
959 template <typename T, typename Args>
961 : boost::mpl::eval_if<
962 boost::is_convertible<
963 typename boost::graph_traits<T>::traversal_category
964 , boost::incidence_graph_tag
967 boost::is_convertible<
968 typename boost::graph_traits<T>::traversal_category
969 , boost::vertex_list_graph_tag
972 , boost::mpl::false\_
979 struct index_map_predicate
981 template <typename T, typename Args>
983 : boost::mpl::eval_if<
985 typename boost::property_traits<T>::value_type
989 typename boost::property_traits<T>::key_type
990 , typename boost::graph_traits<
991 typename boost::parameter::value_type<
998 , boost::mpl::false\_
1005 struct color_map_predicate
1007 template <typename T, typename Args>
1011 typename boost::property_traits<T>::key_type
1012 , typename boost::graph_traits<
1013 typename boost::parameter::value_type<
1017 >::vertex_descriptor
1019 , boost::mpl::true\_
1020 , boost::mpl::false\_
1026 Likewise, computing the default value for the ``color_map`` parameter is no
1027 trivial matter, so it's best to factor the computation out to a separate
1032 template <typename Size, typename IndexMap>
1033 boost::iterator_property_map<
1034 std::vector<boost::default_color_type>::iterator
1036 , boost::default_color_type
1037 , boost::default_color_type&
1039 default_color_map(Size num_vertices, IndexMap const& index_map)
1041 static std::vector<boost::default_color_type> colors(num_vertices);
1042 static boost::iterator_property_map<
1043 std::vector<boost::default_color_type>::iterator
1045 , boost::default_color_type
1046 , boost::default_color_type&
1047 > m(colors.begin(), index_map);
1051 The signature encloses each predicate metafunction in parentheses *preceded
1052 by an asterix*, as follows:
1056 BOOST_PARAMETER_FUNCTION((void), depth_first_search, graphs,
1058 (graph, \*(**graph_predicate**))
1062 , \* // not easily checkable
1063 , boost::dfs_visitor<>()
1066 , (**vertex_descriptor_predicate**)
1067 , \*vertices(graph).first
1070 , \*(**index_map_predicate**)
1071 , get(boost::vertex_index, graph)
1074 , \*(**color_map_predicate**)
1075 , default_color_map(num_vertices(graph), index_map)
1080 .. @example.prepend('''
1081 #include <boost/parameter.hpp>
1082 #include <boost/graph/adjacency_list.hpp>
1083 #include <boost/graph/depth_first_search.hpp>
1084 #include <boost/graph/graph_traits.hpp>
1085 #include <boost/property_map/property_map.hpp>
1086 #include <boost/mpl/and.hpp>
1087 #include <boost/type_traits/is_convertible.hpp>
1088 #include <boost/type_traits/is_integral.hpp>
1089 #include <boost/type_traits/is_same.hpp>
1093 BOOST_PARAMETER_NAME((_graph, graphs) graph)
1094 BOOST_PARAMETER_NAME((_visitor, graphs) visitor)
1095 BOOST_PARAMETER_NAME((_root_vertex, graphs) in(root_vertex))
1096 BOOST_PARAMETER_NAME((_index_map, graphs) in(index_map))
1097 BOOST_PARAMETER_NAME((_color_map, graphs) in_out(color_map))
1100 .. @example.append('''
1104 #include <boost/core/lightweight_test.hpp>
1105 #include <boost/graph/adjacency_list.hpp>
1110 typedef boost::adjacency_list<
1111 boost::vecS, boost::vecS, boost::directedS
1113 enum {u, v, w, x, y, z, N};
1114 typedef std::pair<int, int> E;
1116 E(u, v), E(u, x), E(x, v), E(y, x),
1117 E(v, y), E(w, y), E(w,z), E(z, z)
1119 G g(edges, edges + sizeof(edges) / sizeof(E), N);
1121 depth_first_search(g);
1122 depth_first_search(g, _root_vertex = static_cast<int>(x));
1123 return boost::report_errors();
1129 It usually isn't necessary to so completely encode the type requirements on
1130 arguments to generic functions. However, doing so is worth the effort: your
1131 code will be more self-documenting and will often provide a better user
1132 experience. You'll also have an easier transition to the C++20 standard with
1133 `language support for constraints and concepts`__.
1137 More on Type Requirements
1138 .........................
1140 Encoding type requirements onto a function's parameters is essential for
1141 enabling the function to have deduced parameter interface. Let's revisit the
1142 ``new_window`` example for a moment:
1146 window\* w = new_window(
1150 window\* w = new_window(
1157 The goal this time is to be able to invoke the ``new_window`` function without
1158 specifying the keywords. For each parameter that has a required type, we can
1159 enclose that type in parentheses, then *replace* the ``*`` element of the
1160 parameter signature:
1164 BOOST_PARAMETER_NAME((name\_, keywords) name)
1165 BOOST_PARAMETER_NAME((movable\_, keywords) movable)
1167 BOOST_PARAMETER_FUNCTION((window\*), new_window, keywords,
1170 (name, *(char const\*)*)
1181 The following statements will now work and are equivalent to each other as
1182 well as the previous statements:
1186 window\* w = new_window(false, "alert box");
1187 window\* w = new_window("alert box", false);
1194 To further illustrate deduced parameter support, consider the example of the
1195 |def|_ function from Boost.Python_. Its signature is roughly as follows:
1201 , typename KeywordExpression
1202 , typename CallPolicies
1205 // Required parameters
1206 char const\* name, Function func
1208 // Optional, deduced parameters
1209 , char const\* docstring = ""
1210 , KeywordExpression keywords = no_keywords()
1211 , CallPolicies policies = default_call_policies()
1216 Try not to be too distracted by the use of the term “keywords” in this
1217 example: although it means something analogous in Boost.Python to what
1218 it means in the Parameter library, for the purposes of this exercise
1219 you can think of it as being completely different.
1221 When calling ``def``, only two arguments are required. The association
1222 between any additional arguments and their parameters can be determined by the
1223 types of the arguments actually passed, so the caller is neither required to
1224 remember argument positions or explicitly specify parameter names for those
1225 arguments. To generate this interface using ``BOOST_PARAMETER_FUNCTION``, we
1226 need only enclose the deduced parameters in a ``(deduced …)`` clause, as
1231 char const*& blank_char_ptr()
1233 static char const* larr = "";
1237 BOOST_PARAMETER_FUNCTION(
1240 (required (name, (char const\*)) (func,\*) ) // nondeduced
1244 (docstring, (char const\*), "")
1247 // see [#is_keyword_expression]_
1248 , \*(is_keyword_expression<boost::mpl::_>)
1254 boost::mpl::eval_if<
1255 boost::is_convertible<boost::mpl::_,char const\*>
1256 , boost::mpl::false\_
1258 // see [#is_keyword_expression]_
1259 is_keyword_expression<boost::mpl::_>
1260 , boost::mpl::false\_
1261 , boost::mpl::true\_
1265 , default_call_policies()
1274 .. @example.replace_emphasis('return true;')
1276 .. @example.prepend('''
1277 #include <boost/parameter.hpp>
1279 BOOST_PARAMETER_NAME(name)
1280 BOOST_PARAMETER_NAME(func)
1281 BOOST_PARAMETER_NAME(docstring)
1282 BOOST_PARAMETER_NAME(keywords)
1283 BOOST_PARAMETER_NAME(policies)
1285 struct default_call_policies
1297 template <typename T>
1298 struct is_keyword_expression
1299 : boost::mpl::false_
1304 struct is_keyword_expression<keywords>
1309 default_call_policies some_policies;
1315 #include <boost/mpl/placeholders.hpp>
1316 #include <boost/mpl/if.hpp>
1317 #include <boost/mpl/eval_if.hpp>
1318 #include <boost/type_traits/is_convertible.hpp>
1322 .. Admonition:: Syntax Note
1324 A ``(deduced …)`` clause always contains a ``(required …)`` and/or an
1325 ``(optional …)`` subclause, and must follow any ``(required …)`` or
1326 ``(optional …)`` clauses indicating nondeduced parameters at the outer
1329 With the declaration above, the following two calls are equivalent:
1333 char const\* f_name = "f";
1338 , **"Documentation for f"**
1343 , **"Documentation for f"**
1347 .. @example.prepend('''
1352 If the user wants to pass a ``policies`` argument that was also, for some
1353 reason, convertible to ``char const*``, she can always specify the parameter
1354 name explicitly, as follows:
1361 , **_policies = some_policies**
1362 , "Documentation for f"
1365 .. @example.append('}')
1366 .. @test('compile', howmany='all')
1368 The |deduced_cpp|_ and |deduced_dependent_predicate|_ test programs
1369 demonstrate additional usage of deduced parameter support.
1371 .. _Boost.Python: ../../../python/doc/index.html
1372 .. |def| replace:: ``def``
1373 .. _def: ../../../python/doc/v2/def.html
1374 .. |deduced_cpp| replace:: deduced.cpp
1375 .. _deduced_cpp: ../../test/deduced.cpp
1376 .. |deduced_dependent_predicate| replace:: deduced_dependent_predicate.cpp
1377 .. _deduced_dependent_predicate: ../../test/deduced_dependent_predicate.cpp
1379 Parameter-Dependent Return Types
1380 --------------------------------
1382 For some algorithms, the return type depends on at least one of the argument
1383 types. However, there is one gotcha to avoid when encoding this return type
1384 while using ``BOOST_PARAMETER_FUNCTION`` or other code generation macros. As
1385 an example, given the following definitions::
1387 BOOST_PARAMETER_NAME(x)
1388 BOOST_PARAMETER_NAME(y)
1389 BOOST_PARAMETER_NAME(z)
1393 Let our algorithm simply return one of its arguments. If we naïvely implement
1394 its return type in terms of ``parameter::value_type``::
1396 BOOST_PARAMETER_FUNCTION(
1397 (typename parameter::value_type<Args,tag::y>::type), return_y, tag,
1400 (x, (std::map<char const*,std::string>))
1414 Then using ``return_y`` in any manner other than with positional arguments
1415 will result in a compiler error::
1417 std::map<char const*,std::string> k2s;
1418 assert("foo" == return_y(2, k2s, "foo")); // error!
1422 The problem is that even though ``y`` is a required parameter,
1423 ``BOOST_PARAMETER_FUNCTION`` will generate certain overloads for which the
1424 argument pack type ``Args`` does not actually contain the keyword tag type
1425 ``tag::y``. The solution is to use SFINAE to preclude generation of those
1426 overloads. Since ``parameter::value_type`` is a metafunction, our tool for
1427 the job is ``lazy_enable_if``::
1429 BOOST_PARAMETER_FUNCTION(
1431 // Whenever using 'enable_if', 'disable_if', and so on,
1432 // do not add the 'typename' keyword in front.
1433 boost::lazy_enable_if<
1434 typename mpl::has_key<Args,tag::y>::type
1435 , parameter::value_type<Args,tag::y>
1437 // Whenever using 'enable_if', 'disable_if', and so on,
1438 // do not add '::type' here.
1442 (x, (std::map<char const*,std::string>))
1456 For a working demonstration, see |preprocessor_deduced_cpp|_.
1458 .. |preprocessor_deduced_cpp| replace:: preprocessor_deduced.cpp
1459 .. _preprocessor_deduced_cpp: ../../test/preprocessor_deduced.cpp
1461 ----------------------------------
1462 Parameter-Enabled Member Functions
1463 ----------------------------------
1465 The ``BOOST_PARAMETER_MEMBER_FUNCTION`` and
1466 ``BOOST_PARAMETER_CONST_MEMBER_FUNCTION`` macros accept exactly the same
1467 arguments as ``BOOST_PARAMETER_FUNCTION``, but are designed to be used within
1468 the body of a class::
1470 BOOST_PARAMETER_NAME(arg1)
1471 BOOST_PARAMETER_NAME(arg2)
1475 BOOST_PARAMETER_CONST_MEMBER_FUNCTION(
1476 (void), call, tag, (required (arg1,(int))(arg2,(int)))
1479 std::cout << arg1 << ", " << arg2;
1480 std::cout << std::endl;
1484 #include <boost/core/lightweight_test.hpp>
1489 callable2 const& c2_const = c2;
1490 c2_const.call(1, 2);
1491 return boost::report_errors();
1494 .. @example.prepend('''
1495 #include <boost/parameter.hpp>
1497 using namespace boost::parameter;
1502 These macros don't directly allow a function's interface to be separated from
1503 its implementation, but you can always forward arguments on to a separate
1504 implementation function::
1508 BOOST_PARAMETER_CONST_MEMBER_FUNCTION(
1509 (void), call, tag, (required (arg1,(int))(arg2,(int)))
1512 call_impl(arg1, arg2);
1516 void call_impl(int, int); // implemented elsewhere.
1519 .. @example.prepend('''
1520 #include <boost/parameter.hpp>
1522 BOOST_PARAMETER_NAME(arg1)
1523 BOOST_PARAMETER_NAME(arg2)
1524 using namespace boost::parameter;
1529 Static Member Functions
1530 =======================
1532 To expose a static member function, simply insert the keyword “``static``”
1533 before the function name:
1537 BOOST_PARAMETER_NAME(arg1)
1541 BOOST_PARAMETER_MEMBER_FUNCTION(
1542 (void), **static** f, tag, (optional (arg1,(int),0))
1545 std::cout << arg1 << std::endl;
1549 #include <boost/core/lightweight_test.hpp>
1555 return boost::report_errors();
1558 .. @example.prepend('''
1559 #include <boost/parameter.hpp>
1561 using namespace boost::parameter;
1566 -----------------------------------------
1567 Parameter-Enabled Function Call Operators
1568 -----------------------------------------
1570 The ``BOOST_PARAMETER_FUNCTION_CALL_OPERATOR`` and
1571 ``BOOST_PARAMETER_CONST_FUNCTION_CALL_OPERATOR`` macros accept the same
1572 arguments as the ``BOOST_PARAMETER_MEMBER_FUNCTION`` and
1573 ``BOOST_PARAMETER_CONST_MEMBER_FUNCTION`` macros except for the function name,
1574 because these macros allow instances of the enclosing classes to be treated as
1577 BOOST_PARAMETER_NAME(first_arg)
1578 BOOST_PARAMETER_NAME(second_arg)
1582 BOOST_PARAMETER_CONST_FUNCTION_CALL_OPERATOR(
1583 (void), tag, (required (first_arg,(int))(second_arg,(int)))
1586 std::cout << first_arg << ", ";
1587 std::cout << second_arg << std::endl;
1591 #include <boost/core/lightweight_test.hpp>
1596 callable2 const& c2_const = c2;
1598 return boost::report_errors();
1601 .. @example.prepend('''
1602 #include <boost/parameter.hpp>
1604 using namespace boost::parameter;
1609 ------------------------------
1610 Parameter-Enabled Constructors
1611 ------------------------------
1613 The lack of a “delegating constructor” feature in C++
1614 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf)
1615 limits somewhat the quality of interface this library can provide
1616 for defining parameter-enabled constructors. The usual workaround
1617 for a lack of constructor delegation applies: one must factor the
1618 common logic into one or more base classes.
1620 Let's build a parameter-enabled constructor that simply prints its
1621 arguments. The first step is to write a base class whose
1622 constructor accepts a single argument known as an |ArgumentPack|_:
1623 a bundle of references to the actual arguments, tagged with their
1624 keywords. The values of the actual arguments are extracted from
1625 the |ArgumentPack| by *indexing* it with keyword objects::
1627 BOOST_PARAMETER_NAME(name)
1628 BOOST_PARAMETER_NAME(index)
1632 template <typename ArgumentPack>
1633 myclass_impl(ArgumentPack const& args)
1635 std::cout << "name = " << args[_name];
1636 std::cout << "; index = " << args[_index | 42];
1637 std::cout << std::endl;
1641 .. @example.prepend('''
1642 #include <boost/parameter.hpp>
1646 Note that the bitwise or (“\ ``|``\ ”) operator has a special meaning when
1647 applied to keyword objects that are passed to an |ArgumentPack|\ 's indexing
1648 operator: it is used to indicate a default value. In this case if there is no
1649 ``index`` parameter in the |ArgumentPack|, ``42`` will be used instead.
1651 Now we are ready to write the parameter-enabled constructor interface::
1653 struct myclass : myclass_impl
1655 BOOST_PARAMETER_CONSTRUCTOR(
1656 myclass, (myclass_impl), tag
1657 , (required (name,*)) (optional (index,*))
1661 Since we have supplied a default value for ``index`` but not for ``name``,
1662 only ``name`` is required. We can exercise our new interface as follows::
1664 myclass x("bob", 3); // positional
1665 myclass y(_index = 12, _name = "sally"); // named
1666 myclass z("june"); // positional/defaulted
1668 .. @example.wrap('''
1669 #include <boost/core/lightweight_test.hpp>
1672 ''', ' return boost::report_errors(); }')
1673 .. @test('run', howmany='all')
1675 For more on |ArgumentPack| manipulation, see the `Advanced Topics`_ section.
1677 ---------------------------------
1678 Parameter-Enabled Class Templates
1679 ---------------------------------
1681 In this section we'll use Boost.Parameter to build Boost.Python_\
1682 's `class_`_ template, whose “signature” is:
1687 ValueType, BaseList = bases<>
1688 , HeldType = ValueType, Copyable = void
1694 Only the first argument, ``ValueType``, is required.
1696 .. _class_: http://www.boost.org/libs/python/doc/v2/class.html#class_-spec
1698 Named Template Parameters
1699 =========================
1701 First, we'll build an interface that allows users to pass arguments
1702 positionally or by name:
1718 , **copyable<boost::noncopyable>**
1723 , **held_type<std::auto_ptr<D> >**
1724 , **base_list<bases<B> >**
1732 The first step is to define keywords for each template parameter::
1734 namespace boost { namespace python {
1736 BOOST_PARAMETER_TEMPLATE_KEYWORD(class_type)
1737 BOOST_PARAMETER_TEMPLATE_KEYWORD(base_list)
1738 BOOST_PARAMETER_TEMPLATE_KEYWORD(held_type)
1739 BOOST_PARAMETER_TEMPLATE_KEYWORD(copyable)
1742 .. @example.prepend('#include <boost/parameter.hpp>')
1745 The declaration of the ``class_type`` keyword you see here is equivalent to::
1747 namespace boost { namespace python {
1750 struct class_type; // keyword tag type
1753 template <typename T>
1755 : parameter::template_keyword<tag::class_type,T>
1760 .. @example.prepend('#include <boost/parameter.hpp>')
1763 It defines a keyword tag type named ``tag::class_type`` and a
1764 *parameter passing template* named ``class_type``.
1766 Class Template Skeleton
1767 -----------------------
1769 The next step is to define the skeleton of our class template, which has three
1770 optional parameters. Because the user may pass arguments in any order, we
1771 don't know the actual identities of these parameters, so it would be premature
1772 to use descriptive names or write out the actual default values for any of
1773 them. Instead, we'll give them generic names and use the special type
1774 ``boost::parameter::void_`` as a default:
1778 namespace boost { namespace python {
1782 , typename A1 = boost::parameter::void\_
1783 , typename A2 = boost::parameter::void\_
1784 , typename A3 = boost::parameter::void\_
1792 .. @example.prepend('#include <boost/parameter.hpp>')
1793 .. @example.replace_emphasis('')
1796 Class Template Signatures
1797 -------------------------
1799 Next, we need to build a type, known as a |ParameterSpec|_, describing the
1800 “signature” of ``boost::python::class_``. A |ParameterSpec|_ enumerates the
1801 required and optional parameters in their positional order, along with any
1802 type requirements (note that it does *not* specify defaults -- those will be
1803 dealt with separately)::
1805 namespace boost { namespace python {
1807 using boost::mpl::_;
1809 typedef parameter::parameters<
1810 required<tag::class_type, boost::is_class<_> >
1811 , parameter::optional<tag::base_list, mpl::is_sequence<_> >
1812 , parameter::optional<tag::held_type>
1813 , parameter::optional<tag::copyable>
1817 .. @example.prepend('''
1818 #include <boost/parameter.hpp>
1819 #include <boost/mpl/is_sequence.hpp>
1820 #include <boost/noncopyable.hpp>
1821 #include <boost/type_traits/is_class.hpp>
1824 using namespace boost::parameter;
1826 namespace boost { namespace python {
1828 BOOST_PARAMETER_TEMPLATE_KEYWORD(class_type)
1829 BOOST_PARAMETER_TEMPLATE_KEYWORD(base_list)
1830 BOOST_PARAMETER_TEMPLATE_KEYWORD(held_type)
1831 BOOST_PARAMETER_TEMPLATE_KEYWORD(copyable)
1833 template <typename B = int>
1840 .. |ParameterSpec| replace:: :concept:`ParameterSpec`
1842 .. _ParameterSpec: reference.html#parameterspec
1846 Argument Packs and Parameter Extraction
1847 ---------------------------------------
1849 Next, within the body of ``class_`` , we use the |ParameterSpec|\ 's
1850 nested ``::bind< … >`` template to bundle the actual arguments into an
1851 |ArgumentPack|_ type, and then use the library's ``value_type< … >``
1852 metafunction to extract “logical parameters”. ``value_type< … >`` is
1853 a lot like ``binding< … >``, but no reference is added to the actual
1854 argument type. Note that defaults are specified by passing it an
1855 optional third argument::
1857 namespace boost { namespace python {
1861 , typename A1 = boost::parameter::void_
1862 , typename A2 = boost::parameter::void_
1863 , typename A3 = boost::parameter::void_
1867 // Create ArgumentPack
1868 typedef typename class_signature::template bind<
1872 // Extract first logical parameter.
1873 typedef typename parameter::value_type<
1874 args, tag::class_type
1877 typedef typename parameter::value_type<
1878 args, tag::base_list, bases<>
1881 typedef typename parameter::value_type<
1882 args, tag::held_type, class_type
1885 typedef typename parameter::value_type<
1886 args, tag::copyable, void
1891 .. |ArgumentPack| replace:: :concept:`ArgumentPack`
1892 .. _ArgumentPack: reference.html#argumentpack
1894 Exercising the Code So Far
1895 ==========================
1899 Revisiting our original examples, ::
1901 typedef boost::python::class_<
1902 class_type<B>, copyable<boost::noncopyable>
1905 typedef boost::python::class_<
1907 , held_type<std::auto_ptr<D> >
1908 , base_list<bases<B> >
1911 .. @example.prepend('''
1912 using boost::python::class_type;
1913 using boost::python::copyable;
1914 using boost::python::held_type;
1915 using boost::python::base_list;
1916 using boost::python::bases;
1927 we can now examine the intended parameters::
1929 BOOST_MPL_ASSERT((boost::is_same<c1::class_type, B>));
1930 BOOST_MPL_ASSERT((boost::is_same<c1::base_list, bases<> >));
1931 BOOST_MPL_ASSERT((boost::is_same<c1::held_type, B>));
1933 boost::is_same<c1::copyable, boost::noncopyable>
1936 BOOST_MPL_ASSERT((boost::is_same<c2::class_type, D>));
1937 BOOST_MPL_ASSERT((boost::is_same<c2::base_list, bases<B> >));
1939 boost::is_same<c2::held_type, std::auto_ptr<D> >
1941 BOOST_MPL_ASSERT((boost::is_same<c2::copyable, void>));
1943 .. @test('compile', howmany='all')
1945 Deduced Template Parameters
1946 ===========================
1948 To apply a deduced parameter interface here, we need only make the type
1949 requirements a bit tighter so the ``held_type`` and ``copyable`` parameters
1950 can be crisply distinguished from the others. Boost.Python_ does this by
1951 requiring that ``base_list`` be a specialization of its ``bases< … >``
1952 template (as opposed to being any old MPL sequence) and by requiring that
1953 ``copyable``, if explicitly supplied, be ``boost::noncopyable``. One easy way
1954 of identifying specializations of ``bases< … >`` is to derive them all from
1955 the same class, as an implementation detail:
1959 namespace boost { namespace python {
1968 typename A0 = void, typename A1 = void, typename A2 = void *…*
1970 struct bases **: detail::bases_base**
1975 .. @example.replace_emphasis('')
1976 .. @example.prepend('''
1977 #include <boost/parameter.hpp>
1978 #include <boost/mpl/is_sequence.hpp>
1979 #include <boost/noncopyable.hpp>
1982 using namespace boost::parameter;
1983 using boost::mpl::_;
1985 namespace boost { namespace python {
1987 BOOST_PARAMETER_TEMPLATE_KEYWORD(class_type)
1988 BOOST_PARAMETER_TEMPLATE_KEYWORD(base_list)
1989 BOOST_PARAMETER_TEMPLATE_KEYWORD(held_type)
1990 BOOST_PARAMETER_TEMPLATE_KEYWORD(copyable)
1994 Now we can rewrite our signature to make all three optional parameters
1997 typedef parameter::parameters<
1998 required<tag::class_type, is_class<_> >
2000 , parameter::optional<
2001 deduced<tag::base_list>
2002 , is_base_and_derived<detail::bases_base,_>
2005 , parameter::optional<
2006 deduced<tag::held_type>
2009 is_base_and_derived<detail::bases_base,_>
2010 , is_same<noncopyable,_>
2015 , parameter::optional<
2016 deduced<tag::copyable>
2017 , is_same<noncopyable,_>
2022 .. @example.prepend('''
2023 #include <boost/type_traits/is_class.hpp>
2024 namespace boost { namespace python {
2027 .. @example.append('''
2030 , typename A1 = boost::parameter::void_
2031 , typename A2 = boost::parameter::void_
2032 , typename A3 = boost::parameter::void_
2036 // Create ArgumentPack
2037 typedef typename class_signature::bind<
2041 // Extract first logical parameter.
2042 typedef typename parameter::value_type<
2043 args, tag::class_type
2046 typedef typename parameter::value_type<
2047 args, tag::base_list, bases<>
2050 typedef typename parameter::value_type<
2051 args, tag::held_type, class_type
2054 typedef typename parameter::value_type<
2055 args, tag::copyable, void
2061 It may seem like we've added a great deal of complexity, but the benefits to
2062 our users are greater. Our original examples can now be written without
2063 explicit parameter names:
2067 typedef boost::python::class_<**B**, **boost::noncopyable**> c1;
2069 typedef boost::python::class_<
2070 **D**, **std::auto_ptr<D>**, **bases<B>**
2073 .. @example.prepend('''
2082 using boost::python::bases;
2085 .. @example.append('''
2086 BOOST_MPL_ASSERT((boost::is_same<c1::class_type, B>));
2087 BOOST_MPL_ASSERT((boost::is_same<c1::base_list, bases<> >));
2088 BOOST_MPL_ASSERT((boost::is_same<c1::held_type, B>));
2090 boost::is_same<c1::copyable, boost::noncopyable>
2093 BOOST_MPL_ASSERT((boost::is_same<c2::class_type, D>));
2094 BOOST_MPL_ASSERT((boost::is_same<c2::base_list, bases<B> >));
2096 boost::is_same<c2::held_type, std::auto_ptr<D> >
2098 BOOST_MPL_ASSERT((boost::is_same<c2::copyable, void>));
2101 .. @test('compile', howmany='all')
2107 At this point, you should have a good grasp of the basics. In this section
2108 we'll cover some more esoteric uses of the library.
2110 -------------------------
2111 Fine-Grained Name Control
2112 -------------------------
2114 If you don't like the leading-underscore naming convention used to refer to
2115 keyword objects, or you need the name ``tag`` for something other than the
2116 keyword type namespace, there's another way to use ``BOOST_PARAMETER_NAME``:
2120 BOOST_PARAMETER_NAME(
2123 **,** *tag-namespace*
2124 **)** *parameter-name*
2129 Here is a usage example:
2133 BOOST_PARAMETER_NAME(
2135 **pass_foo**, **keywords**
2139 BOOST_PARAMETER_FUNCTION(
2141 **keywords**, (required (**foo**, \*))
2147 int x = f(**pass_foo** = 41);
2149 .. @example.prepend('#include <boost/parameter.hpp>')
2150 .. @example.append('''
2158 Before you use this more verbose form, however, please read the section on
2159 `best practices for keyword object naming`__.
2161 __ `Keyword Naming`_
2163 ----------------------
2164 More |ArgumentPack|\ s
2165 ----------------------
2167 We've already seen |ArgumentPack|\ s when we looked at
2168 `parameter-enabled constructors`_ and `class templates`__. As you
2169 might have guessed, |ArgumentPack|\ s actually lie at the heart of
2170 everything this library does; in this section we'll examine ways to
2171 build and manipulate them more effectively.
2175 Building |ArgumentPack|\ s
2176 ==========================
2178 The simplest |ArgumentPack| is the result of assigning into a keyword object::
2180 BOOST_PARAMETER_NAME(index)
2182 template <typename ArgumentPack>
2183 int print_index(ArgumentPack const& args)
2185 std::cout << "index = " << args[_index];
2186 std::cout << std::endl;
2190 int x = print_index(_index = 3); // prints "index = 3"
2192 .. @example.prepend('''
2193 #include <boost/parameter.hpp>
2197 Also, |ArgumentPack|\ s can be composed using the comma operator. The extra
2198 parentheses below are used to prevent the compiler from seeing two separate
2199 arguments to ``print_name_and_index``::
2201 BOOST_PARAMETER_NAME(name)
2203 template <typename ArgumentPack>
2204 int print_name_and_index(ArgumentPack const& args)
2206 std::cout << "name = " << args[_name];
2208 return print_index(args);
2211 int y = print_name_and_index((_index = 3, _name = "jones"));
2213 The |compose_cpp|_ test program shows more examples of this feature.
2215 To build an |ArgumentPack| with positional arguments, we can use a
2216 |ParameterSpec|_. As introduced described in the section on `Class Template
2217 Signatures`_, a |ParameterSpec| describes the positional order of parameters
2218 and any associated type requirements. Just as we can build an |ArgumentPack|
2219 *type* with its nested ``::bind< … >`` template, we can build an
2220 |ArgumentPack| *object* by invoking its function call operator:
2224 parameter::parameters<
2225 required<tag::\ name, is_convertible<_,char const*> >
2226 , optional<tag::\ index, is_convertible<_,int> >
2229 char const sam[] = "sam";
2232 int z0 = print_name_and_index(
2233 **spec(** sam, twelve **)**
2236 int z1 = print_name_and_index(
2237 **spec(** _index=12, _name="sam" **)**
2240 .. @example.prepend('''
2241 namespace parameter = boost::parameter;
2242 using parameter::required;
2243 using parameter::optional;
2244 using boost::is_convertible;
2245 using boost::mpl::_;
2248 .. @example.append('''
2255 .. @test('run', howmany='all')
2257 Extracting Parameter Types
2258 ==========================
2260 If we want to know the types of the arguments passed to
2261 ``print_name_and_index``, we have a couple of options. The
2262 simplest and least error-prone approach is to forward them to a
2263 function template and allow *it* to do type deduction::
2265 BOOST_PARAMETER_NAME(name)
2266 BOOST_PARAMETER_NAME(index)
2268 template <typename Name, typename Index>
2269 int deduce_arg_types_impl(Name&& name, Index&& index)
2271 // we know the types
2272 Name&& n2 = boost::forward<Name>(name);
2273 Index&& i2 = boost::forward<Index>(index);
2277 template <typename ArgumentPack>
2278 int deduce_arg_types(ArgumentPack const& args)
2280 return deduce_arg_types_impl(args[_name], args[_index | 42]);
2283 .. @example.prepend('''
2284 #include <boost/parameter.hpp>
2287 .. @example.append('''
2288 #include <boost/core/lightweight_test.hpp>
2292 int a1 = deduce_arg_types((_name = "foo"));
2293 int a2 = deduce_arg_types((_name = "foo", _index = 3));
2294 BOOST_TEST_EQ(a1, 42);
2295 BOOST_TEST_EQ(a2, 3);
2296 return boost::report_errors();
2302 Occasionally one needs to deduce argument types without an extra layer of
2303 function call. For example, suppose we wanted to return twice the value of
2304 the ``index`` parameter? In that case we can use the ``value_type< … >``
2305 metafunction introduced `earlier`__::
2307 BOOST_PARAMETER_NAME(index)
2309 template <typename ArgumentPack>
2310 typename boost::parameter::value_type<ArgumentPack,tag::index,int>::type
2311 twice_index(ArgumentPack const& args)
2313 return 2 * args[_index | 42];
2316 .. @example.prepend('''
2317 #include <boost/parameter.hpp>
2320 .. @example.append('''
2321 #include <boost/core/lightweight_test.hpp>
2325 int six = twice_index(_index = 3);
2326 BOOST_TEST_EQ(six, 6);
2327 return boost::report_errors();
2331 .. @test('run', howmany='all')
2333 Note that if we had used ``binding< … >`` rather than ``value_type< … >``, we
2334 would end up returning a reference to the temporary created in the ``2 * …``
2339 Lazy Default Computation
2340 ========================
2342 When a default value is expensive to compute, it would be preferable to avoid
2343 it until we're sure it's absolutely necessary. ``BOOST_PARAMETER_FUNCTION``
2344 takes care of that problem for us, but when using |ArgumentPack|\ s
2345 explicitly, we need a tool other than ``operator|``::
2347 BOOST_PARAMETER_NAME(s1)
2348 BOOST_PARAMETER_NAME(s2)
2349 BOOST_PARAMETER_NAME(s3)
2351 template <typename ArgumentPack>
2352 std::string f(ArgumentPack const& args)
2354 std::string const& s1 = args[_s1];
2355 std::string const& s2 = args[_s2];
2356 typename parameter::binding<
2357 ArgumentPack,tag::s3,std::string
2358 >::type s3 = args[_s3 | (s1 + s2)]; // always constructs s1 + s2
2363 _s1="hello,", _s2=" world", _s3="hi world"
2366 .. @example.prepend('''
2367 #include <boost/parameter.hpp>
2370 namespace parameter = boost::parameter;
2373 .. @example.append('''
2382 In the example above, the string ``"hello, world"`` is constructed despite the
2383 fact that the user passed us a value for ``s3``. To remedy that, we can
2384 compute the default value *lazily* (that is, only on demand), by using
2385 ``boost::bind()`` to create a function object.
2387 .. danielw: I'm leaving the text below in the source, because we might
2388 .. want to change back to it after 1.34, and if I remove it now we
2389 .. might forget about it.
2391 .. by combining the logical-or (“``||``”) operator
2392 .. with a function object built by the Boost Lambda_ library: [#bind]_
2396 typename parameter::binding<
2397 ArgumentPack,tag::s3,std::string
2399 _s3 **|| boost::bind(
2400 std::plus<std::string>(), boost::ref(s1), boost::ref(s2)
2404 .. @example.prepend('''
2405 #include <boost/bind.hpp>
2406 #include <boost/ref.hpp>
2407 #include <boost/parameter.hpp>
2409 #include <functional>
2411 namespace parameter = boost::parameter;
2413 BOOST_PARAMETER_NAME(s1)
2414 BOOST_PARAMETER_NAME(s2)
2415 BOOST_PARAMETER_NAME(s3)
2417 template <typename ArgumentPack>
2418 std::string f(ArgumentPack const& args)
2420 std::string const& s1 = args[_s1];
2421 std::string const& s2 = args[_s2];
2424 .. @example.append('''
2428 std::string x = f((_s1="hello,", _s2=" world", _s3="hi world"));
2438 .. .. _Lambda: ../../../lambda/index.html
2440 .. sidebar:: Mnemonics
2442 To remember the difference between ``|`` and ``||``, recall that ``||``
2443 normally uses short-circuit evaluation: its second argument is only
2444 evaluated if its first argument is ``false``. Similarly, in
2445 ``color_map[param || f]``, ``f`` is only invoked if no ``color_map``
2446 argument was supplied.
2448 The expression ``bind(std::plus<std::string>(), ref(s1), ref(s2))`` yields a
2449 *function object* that, when invoked, adds the two strings together. That
2450 function will only be invoked if no ``s3`` argument is supplied by the caller.
2452 .. The expression ``lambda::var(s1) + lambda::var(s2)`` yields a
2453 .. *function object* that, when invoked, adds the two strings
2454 .. together. That function will only be invoked if no ``s3`` argument
2455 .. is supplied by the caller.
2461 By now you should have a fairly good idea of how to use the Parameter
2462 library. This section points out a few more-marginal issues that will help
2463 you use the library more effectively.
2469 ``BOOST_PARAMETER_NAME`` prepends a leading underscore to the names of all our
2470 keyword objects in order to avoid the following usually-silent bug:
2480 typedef boost::parameter::forward_reference qualifier;
2485 typedef boost::parameter::forward_reference qualifier;
2489 namespace // unnamed
2491 boost::parameter::keyword<tag::name>& **name**
2492 = boost::parameter::keyword<tag::name>::instance;
2493 boost::parameter::keyword<tag::age>& **age**
2494 = boost::parameter::keyword<tag::age>::instance;
2497 BOOST_PARAMETER_FUNCTION(
2498 (void), g, tag, (optional (name, \*, "bob")(age, \*, 42))
2501 std::cout << name << ":" << age;
2511 g(**age** = 3); // whoops!
2517 Although in the case above, the user was trying to pass the value ``3`` as the
2518 ``age`` parameter to ``g``, what happened instead was that ``f``\ 's ``age``
2519 argument got reassigned the value 3, and was then passed as a positional
2520 argument to ``g``. Since ``g``'s first positional parameter is ``name``, the
2521 default value for ``age`` is used, and g prints ``3:42``. Our leading
2522 underscore naming convention makes this problem less likely to occur.
2524 In this particular case, the problem could have been detected if f's ``age``
2525 parameter had been made ``const``, which is always a good idea whenever
2526 possible. Finally, we recommend that you use an enclosing namespace for all
2527 your code, but particularly for names with leading underscores. If we were to
2528 leave out the ``people`` namespace above, names in the global namespace
2529 beginning with leading underscores—which are reserved to your C++
2530 compiler—might become irretrievably ambiguous with those in our
2537 In our examples we've always declared keyword objects in (an unnamed namespace
2538 within) the same namespace as the Boost.Parameter-enabled functions using
2545 **BOOST_PARAMETER_NAME(name)
2546 BOOST_PARAMETER_NAME(index)**
2548 BOOST_PARAMETER_FUNCTION(
2550 (optional (name,*,"bob")(index,(int),1))
2553 std::cout << name << ":" << index;
2554 std::cout << std::endl;
2559 .. @example.prepend('''
2560 #include <boost/parameter.hpp>
2563 .. @namespace_setup = str(example)
2566 Users of these functions have a few choices:
2568 1. Full qualification:
2572 int x = **lib::**\ f(
2573 **lib::**\ _name = "jill"
2574 , **lib::**\ _index = 1
2577 This approach is more verbose than many users would like.
2579 .. @example.prepend(namespace_setup)
2580 .. @example.append('int main() { return 0; }')
2583 2. Make keyword objects available through *using-declarations*:
2588 using lib::_index;**
2590 int x = lib::f(_name = "jill", _index = 1);
2592 This version is much better at the actual call site, but the
2593 *using-declarations* themselves can be verbose and hard to manage.
2595 .. @example.prepend(namespace_setup)
2596 .. @example.append('int main() { return 0; }')
2599 3. Bring in the entire namespace with a *using-directive*:
2603 **using namespace lib;**
2604 int x = **f**\ (_name = "jill", _index = 3);
2606 This option is convenient, but it indiscriminately makes the *entire*
2607 contents of ``lib`` available without qualification.
2609 .. @example.prepend(namespace_setup)
2610 .. @example.append('int main() { return 0; }')
2613 If we add an additional namespace around keyword declarations, though, we can
2614 give users more control:
2619 **namespace keywords {**
2621 BOOST_PARAMETER_NAME(name)
2622 BOOST_PARAMETER_NAME(index)
2625 BOOST_PARAMETER_FUNCTION(
2626 (int), f, **keywords::**\ tag,
2627 (optional (name,*,"bob")(index,(int),1))
2630 std::cout << name << ":" << index;
2631 std::cout << std::endl;
2636 .. @example.prepend('''
2637 #include <boost/parameter.hpp>
2641 Now users need only a single *using-directive* to bring in just the names of
2642 all keywords associated with ``lib``:
2646 **using namespace lib::keywords;**
2647 int y = lib::f(_name = "bob", _index = 2);
2649 .. @example.append('int main() { return 0; }')
2650 .. @test('run', howmany='all')
2656 The interface idioms enabled by Boost.Parameter are completely new (to C++),
2657 and as such are not served by pre-existing documentation conventions.
2659 .. Note:: This space is empty because we haven't settled on any best practices
2660 yet. We'd be very pleased to link to your documentation if you've got a
2661 style that you think is worth sharing.
2663 ==========================
2664 Portability Considerations
2665 ==========================
2667 Use the `regression test results`_ for the latest Boost release of
2668 the Parameter library to see how it fares on your favorite
2669 compiler. Additionally, you may need to be aware of the following
2670 issues and workarounds for particular compilers.
2672 .. _`regression test results`: http\://www.boost.org/regression/release/user/parameter.html
2674 --------------------------
2675 Perfect Forwarding Support
2676 --------------------------
2678 If your compiler supports `perfect forwarding`_, then the Parameter library
2679 will ``#define`` the macro ``BOOST_PARAMETER_HAS_PERFECT_FORWARDING`` unless
2680 you disable it manually. If your compiler does not provide this support, then
2681 ``parameter::parameters::operator()`` will treat rvalue references as lvalue
2682 ``const`` references to work around the `forwarding problem`_, so in certain
2683 cases you must wrap |boost_ref|_ or |std_ref|_ around any arguments that will
2684 be bound to out parameters. The |evaluate_category|_ and
2685 |preprocessor_eval_category|_ test programs demonstrate this support.
2687 .. _`perfect forwarding`: http\://www.justsoftwaresolutions.co.uk/cplusplus/rvalue_references_and_perfect_forwarding.html
2688 .. _`forwarding problem`: http\://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm
2689 .. |boost_ref| replace:: ``boost::ref``
2690 .. _boost_ref: ../../../core/doc/html/core/ref.html
2691 .. |std_ref| replace:: ``std::ref``
2692 .. _std_ref: http://en.cppreference.com/w/cpp/utility/functional/ref
2693 .. |evaluate_category| replace:: evaluate_category.cpp
2694 .. _evaluate_category: ../../test/evaluate_category.cpp
2695 .. |preprocessor_eval_category| replace:: preprocessor_eval_category.cpp
2696 .. _preprocessor_eval_category: ../../test/preprocessor_eval_category.cpp
2702 If your compiler is sufficiently compliant with the C++11 standard, then the
2703 Parameter library will ``#define`` the macro ``BOOST_PARAMETER_CAN_USE_MP11``
2704 unless you disable it manually. The |singular_cpp|_, |compose_cpp|_,
2705 |optional_deduced_sfinae_cpp|_, and |deduced_dep_pred_cpp|_ test programs
2706 demonstrate support for `Boost.MP11`_.
2708 .. _`Boost.MP11`: ../../../mp11/doc/html/mp11.html
2709 .. |singular_cpp| replace:: singular.cpp
2710 .. _singular_cpp: ../../test/singular.cpp
2711 .. |optional_deduced_sfinae_cpp| replace:: optional_deduced_sfinae.cpp
2712 .. _optional_deduced_sfinae_cpp: ../../test/optional_deduced_sfinae.cpp
2713 .. |deduced_dep_pred_cpp| replace:: deduced_dependent_predicate.cpp
2714 .. _deduced_dep_pred_cpp: ../../test/deduced_dependent_predicate.cpp
2720 Some older compilers don't support SFINAE. If your compiler meets that
2721 criterion, then Boost headers will ``#define`` the preprocessor symbol
2722 ``BOOST_NO_SFINAE``, and parameter-enabled functions won't be removed
2723 from the overload set based on their signatures. The |sfinae_cpp|_ and
2724 |optional_deduced_sfinae|_ test programs demonstrate SFINAE support.
2726 .. |sfinae_cpp| replace:: sfinae.cpp
2727 .. _sfinae_cpp: ../../test/sfinae.cpp
2728 .. |optional_deduced_sfinae| replace:: optional_deduced_sfinae.cpp
2729 .. _optional_deduced_sfinae: ../../test/optional_deduced_sfinae.cpp
2731 ---------------------------
2732 No Support for |result_of|_
2733 ---------------------------
2735 .. |result_of| replace:: ``result_of``
2737 .. _result_of: ../../../utility/utility.htm#result_of
2739 `Lazy default computation`_ relies on the |result_of| class template to
2740 compute the types of default arguments given the type of the function object
2741 that constructs them. On compilers that don't support |result_of|,
2742 ``BOOST_NO_RESULT_OF`` will be ``#define``\ d, and the compiler will expect
2743 the function object to contain a nested type name, ``result_type``, that
2744 indicates its return type when invoked without arguments. To use an ordinary
2745 function as a default generator on those compilers, you'll need to wrap it in
2746 a class that provides ``result_type`` as a ``typedef`` and invokes the
2747 function via its ``operator()``.
2750 Can't Declare |ParameterSpec| via ``typedef``
2751 =============================================
2753 In principle you can declare a |ParameterSpec| as a ``typedef`` for a
2754 specialization of ``parameters<…>``, but Microsoft Visual C++ 6.x has been
2755 seen to choke on that usage. The workaround is to use inheritance and
2756 declare your |ParameterSpec| as a class:
2760 **struct dfs_parameters
2761 :** parameter::parameters<
2762 tag::graph, tag::visitor, tag::root_vertex
2763 , tag::index_map, tag::color_map
2768 Default Arguments Unsupported on Nested Templates
2769 =============================================
2771 As of this writing, Borland compilers don't support the use of default
2772 template arguments on member class templates. As a result, you have to
2773 supply ``BOOST_PARAMETER_MAX_ARITY`` arguments to every use of
2774 ``parameters<…>::match``. Since the actual defaults used are unspecified,
2775 the workaround is to use |BOOST_PARAMETER_MATCH|_ to declare default
2776 arguments for SFINAE.
2778 .. |BOOST_PARAMETER_MATCH| replace:: ``BOOST_PARAMETER_MATCH``
2780 --------------------------------------------------
2781 Compiler Can't See References In Unnamed Namespace
2782 --------------------------------------------------
2784 If you use Microsoft Visual C++ 6.x, you may find that the compiler has
2785 trouble finding your keyword objects. This problem has been observed, but
2786 only on this one compiler, and it disappeared as the test code evolved, so
2787 we suggest you use it only as a last resort rather than as a preventative
2788 measure. The solution is to add *using-declarations* to force the names
2789 to be available in the enclosing namespace without qualification::
2793 using graphs::graph;
2794 using graphs::visitor;
2795 using graphs::root_vertex;
2796 using graphs::index_map;
2797 using graphs::color_map;
2804 .. _python: python.html
2806 Follow `this link`__ for documentation on how to expose
2807 Boost.Parameter-enabled functions to Python with `Boost.Python`_.
2809 __ ../../../parameter_python/doc/html/index.html
2815 .. _reference: reference.html
2817 Follow `this link`__ to the Boost.Parameter reference documentation.
2827 -------------------------------
2828 Argument (or “actual argument”)
2829 -------------------------------
2831 the value actually passed to a function or class template.
2835 ---------------------------------
2836 Parameter (or “formal parameter”)
2837 ---------------------------------
2839 the name used to refer to an argument within a function or class
2840 template. For example, the value of ``f``'s *parameter* ``x`` is given by the
2845 int f(int x) { return x + 1; }
2852 The authors would like to thank all the Boosters who participated in the
2853 review of this library and its documentation, most especially our review
2854 manager, Doug Gregor.
2856 --------------------------
2858 .. [#old_interface] As of Boost 1.33.0 the Graph library was still using an
2859 `older named parameter mechanism`__, but there are plans to change it to
2860 use Boost.Parameter (this library) in an upcoming release, while keeping
2861 the old interface available for backward-compatibility.
2863 __ ../../../graph/doc/bgl_named_params.html
2865 .. [#odr] The **One Definition Rule** says that any given entity in a C++
2866 program must have the same definition in all translation units (object
2867 files) that make up a program.
2869 .. [#vertex_descriptor] If you're not familiar with the Boost Graph Library,
2870 don't worry about the meaning of any Graph-library-specific details you
2871 encounter. In this case you could replace all mentions of vertex
2872 descriptor types with ``int`` in the text, and your understanding of the
2873 Parameter library wouldn't suffer.
2875 .. [#ConceptsTS] This is a major motivation behind `C++20 constraints`_.
2877 .. _`C++20 constraints`: http://en.cppreference.com/w/cpp/language/constraints
2879 .. .. [#bind] The Lambda library is known not to work on `some
2880 .. less-conformant compilers`__. When using one of those you could
2881 .. use `Boost.Bind`_ to generate the function object\:\:
2883 .. boost\:\:bind(std\:\:plus<std\:\:string>(),s1,s2)
2885 .. [#is_keyword_expression] Here we're assuming there's a predicate
2886 metafunction ``is_keyword_expression`` that can be used to identify
2887 models of Boost.Python's KeywordExpression concept.
2889 .. .. __ http://www.boost.org/regression/release/user/lambda.html
2890 .. _Boost.Bind: ../../../bind/index.html
2892 .. [#using] You can always give the illusion that the function
2893 lives in an outer namespace by applying a *using-declaration*::
2895 namespace foo_overloads {
2897 // foo declarations here
2901 using foo_overloads::foo;
2903 This technique for avoiding unintentional argument-dependent lookup is due
2906 .. [#sfinae] This capability depends on your compiler's support for
2907 SFINAE. **SFINAE**: **S**\ ubstitution **F**\ ailure **I**\ s **N**\ ot
2908 **A**\ n **E**\ rror. If type substitution during the instantiation of a
2909 function template results in an invalid type, no compilation error is
2910 emitted; instead the overload is removed from the overload set. By
2911 producing an invalid type in the function signature depending on the
2912 result of some condition, we can decide whether or not an overload is
2913 considered during overload resolution. The technique is formalized in the
2914 |enable_if|_ utility. Most recent compilers support SFINAE; on compilers
2915 that don't support it, the Boost config library will ``#define`` the
2916 symbol ``BOOST_NO_SFINAE``. See
2917 http://www.semantics.org/once_weakly/w02_SFINAE.pdf for more information
2920 .. |enable_if| replace:: ``enable_if``
2921 .. _enable_if: ../../../core/doc/html/core/enable_if.html