...one of the most highly
regarded and expertly designed C++ library projects in the
world.
— Herb Sutter and Andrei
Alexandrescu, C++
Coding Standards
In this section, we explain how to extend the return type deduction system
to cover user defined operators.
In many cases this is not necessary,
as the BLL defines default return types for operators.
For example, the default return type for all comparison operators is
bool
, and as long as the user defined comparison operators
have a bool return type, there is no need to write new specializations
for the return type deduction classes.
Sometimes this cannot be avoided, though.
The overloadable user defined operators are either unary or binary.
For each arity, there are two traits templates that define the
return types of the different operators.
Hence, the return type system can be extended by providing more
specializations for these templates.
The templates for unary functors are
plain_return_type_1<Action, A>
and
return_type_1<Action, A>
, and
plain_return_type_2<Action, A, B>
and
return_type_2<Action, A, B>
respectively for binary functors.
The first parameter (Action
) to all these templates
is the action class, which specifies the operator.
Operators with similar return type rules are grouped together into
action groups,
and only the action class and action group together define the operator
unambiguously.
As an example, the action type
arithmetic_action<plus_action>
stands for
operator+
.
The complete listing of different action types is shown in
Table 20.2, “Action types”.
The latter parameters, A
in the unary case,
or A
and B
in the binary case,
stand for the argument types of the operator call.
The two sets of templates,
plain_return_type_
and
n
return_type_
(n
n
is 1 or 2) differ in the way how parameter types
are presented to them.
For the former templates, the parameter types are always provided as
non-reference types, and do not have const or volatile qualifiers.
This makes specializing easy, as commonly one specialization for each
user defined operator, or operator group, is enough.
On the other hand, if a particular operator is overloaded for different
cv-qualifications of the same argument types,
and the return types of these overloaded versions differ, a more fine-grained control is needed.
Hence, for the latter templates, the parameter types preserve the
cv-qualifiers, and are non-reference types as well.
The downside is, that for an overloaded set of operators of the
kind described above, one may end up needing up to
16 return_type_2
specializations.
Suppose the user has overloaded the following operators for some user defined
types X
, Y
and Z
:
Z operator+(const X&, const Y&); Z operator-(const X&, const Y&);
Now, one can add a specialization stating, that if the left hand argument
is of type X
, and the right hand one of type
Y
, the return type of all such binary arithmetic
operators is Z
:
namespace boost { namespace lambda { template<class Act> struct plain_return_type_2<arithmetic_action<Act>, X, Y> { typedef Z type; }; } }
Having this specialization defined, BLL is capable of correctly
deducing the return type of the above two operators.
Note, that the specializations must be in the same namespace,
::boost::lambda
, with the primary template.
For brevity, we do not show the namespace definitions in the examples below.
It is possible to specialize on the level of an individual operator as well,
in addition to providing a specialization for a group of operators.
Say, we add a new arithmetic operator for argument types X
and Y
:
X operator*(const X&, const Y&);
Our first rule for all arithmetic operators specifies that the return
type of this operator is Z
,
which obviously is not the case.
Hence, we provide a new rule for the multiplication operator:
template<> struct plain_return_type_2<arithmetic_action<multiply_action>, X, Y> { typedef X type; };
The specializations can define arbitrary mappings from the argument types to the return type. Suppose we have some mathematical vector type, templated on the element type:
template <class T> class my_vector;
Suppose the addition operator is defined between any two
my_vector
instantiations,
as long as the addition operator is defined between their element types.
Furthermore, the element type of the resulting my_vector
is the same as the result type of the addition between the element types.
E.g., adding my_vector<int>
and
my_vector<double>
results in
my_vector<double>
.
The BLL has traits classes to perform the implicit built-in and standard
type conversions between integral, floating point, and complex classes.
Using BLL tools, the addition operator described above can be defined as:
template<class A, class B> my_vector<typename return_type_2<arithmetic_action<plus_action>, A, B>::type> operator+(const my_vector<A>& a, const my_vector<B>& b) { typedef typename return_type_2<arithmetic_action<plus_action>, A, B>::type res_type; return my_vector<res_type>(); }
To allow BLL to deduce the type of my_vector
additions correctly, we can define:
template<class A, class B> class plain_return_type_2<arithmetic_action<plus_action>, my_vector<A>, my_vector<B> > { typedef typename return_type_2<arithmetic_action<plus_action>, A, B>::type res_type; public: typedef my_vector<res_type> type; };
Note, that we are reusing the existing specializations for the
BLL return_type_2
template,
which require that the argument types are references.
Table 20.2. Action types
+ |
arithmetic_action<plus_action> |
- |
arithmetic_action<minus_action> |
* |
arithmetic_action<multiply_action> |
/ |
arithmetic_action<divide_action> |
% |
arithmetic_action<remainder_action> |
+ |
unary_arithmetic_action<plus_action> |
- |
unary_arithmetic_action<minus_action> |
& |
bitwise_action<and_action> |
| |
bitwise_action<or_action> |
~ |
bitwise_action<not_action> |
^ |
bitwise_action<xor_action> |
<< |
bitwise_action<leftshift_action_no_stream> |
>> |
bitwise_action<rightshift_action_no_stream> |
&& |
logical_action<and_action> |
|| |
logical_action<or_action> |
! |
logical_action<not_action> |
< |
relational_action<less_action> |
> |
relational_action<greater_action> |
<= |
relational_action<lessorequal_action> |
>= |
relational_action<greaterorequal_action> |
== |
relational_action<equal_action> |
!= |
relational_action<notequal_action> |
+= |
arithmetic_assignment_action<plus_action> |
-= |
arithmetic_assignment_action<minus_action> |
*= |
arithmetic_assignment_action<multiply_action> |
/= |
arithmetic_assignment_action<divide_action> |
%= |
arithmetic_assignment_action<remainder_action> |
&= |
bitwise_assignment_action<and_action> |
=| |
bitwise_assignment_action<or_action> |
^= |
bitwise_assignment_action<xor_action> |
<<= |
bitwise_assignment_action<leftshift_action> |
>>= |
bitwise_assignment_action<rightshift_action> |
++ |
pre_increment_decrement_action<increment_action> |
-- |
pre_increment_decrement_action<decrement_action> |
++ |
post_increment_decrement_action<increment_action> |
-- |
post_increment_decrement_action<decrement_action> |
& |
other_action<address_of_action> |
* |
other_action<contents_of_action> |
, |
other_action<comma_action> |
->* |
other_action<member_pointer_action> |