status of type traits addition (has_operator_xxx)
13 Jan
2011
13 Jan
'11
8:09 p.m.
Here is the status of the type-traits addition: - I added the following operators: +=, *=, -=, /*, %=, &=, |=, ^=, <<, >>, >>=, <<=, prefix ++, prefix --, postfix ++, postfix -- so that the covered operators are now: - I added in the doc. the fact that private operators are not covered and lead to compile time errors - for operators on built-in types that require integer arguments (%, bitwise op.): I replaced a long list of specialiazation by an automatic detection Remaining work: 1. check what happens for pointer arguments, 2. implement trait for: . operator= . has_address_of_op<T> . has_dereference_op<T> . has_member_access_op<T> . has_subscript_op<T1 [,T2]> . has_pointer_to_member_op<T1 [,T2]> . has_comma_op<T1 [,T2]> . has_function_call_op<T,R [,P1, ...]> 3. have an MPL predicate for return value As I have only little time (full time work and 3 young children...), I will: - certainly do 1., - I will certainly leave 3. to somebody else in the future because I am not enough agile with MPL, - as for 2., 3 possibilities: (i) I do it but it will probably postpone the addition for a long time, (ii) I just leave it and I know is is a shame not to provide all operator detection (nobody's perfect) or (iii) somebody else agrees to add them and have them reviewed at the same time. Frédéric
13 Jan
13 Jan
10:25 p.m.
On 1/13/2011 3:09 PM, Frédéric Bron wrote: > Here is the status of the type-traits addition: > - I added the following operators: +=, *=, -=, /*, %=,&=, |=, ^=,<<, >>> ,>>=,<<=, prefix ++, prefix --, postfix ++, postfix -- so that the > covered operators are now: > - I added in the doc. the fact that private operators are not covered > and lead to compile time errors > - for operators on built-in types that require integer arguments (%, > bitwise op.): I replaced a long list of specialiazation by an > automatic detection > > Remaining work: > 1. check what happens for pointer arguments, > 2. implement trait for: > . operator= > . has_address_of_op<T> > . has_dereference_op<T> > . has_member_access_op<T> > . has_subscript_op<T1 [,T2]> > . has_pointer_to_member_op<T1 [,T2]> > . has_comma_op<T1 [,T2]> > . has_function_call_op<T,R [,P1, ...]> > 3. have an MPL predicate for return value > > As I have only little time (full time work and 3 young children...), I will: > - certainly do 1., > - I will certainly leave 3. to somebody else in the future because I > am not enough agile with MPL, > - as for 2., 3 possibilities: > (i) I do it but it will probably postpone the addition for a long time, > (ii) I just leave it and I know is is a shame not to provide all > operator detection (nobody's perfect) or > (iii) somebody else agrees to add them and have them reviewed at the > same time. Your work on this library is very much appreciated by me. I will look at items 2. and 3. some time in the next week to see if I can help.
14 Jan
14 Jan
1:27 a.m.
On 1/13/2011 12:09 PM, Frédéric Bron wrote: > Here is the status of the type-traits addition: > - I added the following operators: +=, *=, -=, /*, %=,&=, |=, ^=,<<, >>> ,>>=,<<=, prefix ++, prefix --, postfix ++, postfix -- so that the > covered operators are now: > - I added in the doc. the fact that private operators are not covered > and lead to compile time errors > - for operators on built-in types that require integer arguments (%, > bitwise op.): I replaced a long list of specialiazation by an > automatic detection Sounds good. > Remaining work: [...] > 3. have an MPL predicate for return value > > As I have only little time (full time work and 3 young children...), I will: [...] > - I will certainly leave 3. to somebody else in the future because I > am not enough agile with MPL, [...] Interface decisions aside, the mechanism to implement 3. is not *too* hard (but can be rather tedious) relative to the infrastructure you've developed to this point. The most you'll need from Boost.MPL for the implementation is mpl::apply (and maybe mpl::always for the default predicate). In the end, it all boils down to determining if the type of an expression satisfies a given Boost.MPL predicate. This is relatively straightforward if you use decltype (I *think*; I have not actually tested it). For example, suppose that you want to determine if declval<T>() + declval<U>() has exactly the type V. Then static const bool value = boost::mpl::apply< boost::is_same< boost::mpl::_1, V >, decltype( declval<T>() + declval<U>() ) >::type::value; will set value to appropriately answer your query. Obviously, you can replace boost::is_same< boost::mpl::_1, V > with any Boost.MPL metafunction predicate (i.e., it should come from a template parameter), and declval<T>() + declval<U>() can be any C++ expression (i.e., it should depend on the specific operator trait in question). In the absence of C++0x decltype, it's still possible, but it's quite a bit more involved. One has to *first* determine whether the expression has a void type, and if it doesn't, one can deduce the type of the expression through a function template and communicate the result of applying the Boost.MPL metafunction predicate back via the sizeof trick. And one should aim to correctly distinguish rvalues and lvalues. Since (I believe) I originally suggested 3., I'll help out however you think I can. E.g., I can extract what I use currently and send you sample code privately, if you wish. - Jeff
5263
Age (days ago)
5264
Last active (days ago)
2 comments
3 participants
participants (3)
-
Edward Diener -
Frédéric Bron -
Jeffrey Lee Hellrung, Jr.