Boost logo

Boost :

Subject: Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Daniel Herring (dherring_at_[hidden])
Date: 2011-03-29 12:08:51


On Tue, 29 Mar 2011, Frédéric Bron wrote:

>> I like can_can_operator_XXXX. Have you considered can_call_XXXX_operator?
>> BTW, I don't see in the review result any constraint on the names for XXXX. I'm designing Boost.Opaque that provides some meta-function to forward the operators from the opaque class to the underlying type such as using_XXXX, hiding_XXXX and I would want to use the same as in your library. Please, could you give the list of XXXX that will be provided by the library?
>
> I have updated this page for this (last column of the table):
> https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
> This is my current proposal which is very close to Boost.Proto apart
> for pre/_inc/dec->pre/post_increment/decrement and negate->unary_minus
> (to keep symmetry with unary_plus).

Those names are a bit long... Here are some brainstormed names. I
reduced "operator" to "op" for uniform brevity.

assert_op_equal_to
affirm_op_equal_to
can_call_op_equal_to
check_op_equal_to
confirm_op_equal_to
detect_op_equal_to
find_op_equal_to
has_op_equal_to // implies the operator belongs to a class..
have_op_equal_to // better form of the verb
probe_op_equal_to
test_op_equal_to
trait_op_equal_to
verify_op_equal_to

Reducing underscore counts is good for the fingers. Here are a few
options there. I picked "check" for uniformity. Most of the prefixes
above would also work.

check_op_equal_to // base X_op_Y form

check_opequal_to

opcheck_equal_to
checkop_equal_to

check::op_equal_to
check_op::equal_to

Again, I'm still not seeing the predicates for operators like "," and
"->". Was that by design? (Sorry; I missed most of the conversation.)

- Daniel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk