Re: [boost] Ready to add dlw_oprs.zip?

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-20 09:23:28

----- Original Message -----
From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
> "What the names of the library's class templates are supposed to reflect?
What
> is their uniform semantics?"
>
> And I am afraid, that at current moment there is no one. See, some of the
> class templates, such as 'negatable', indicate the concept (operator(s)),
> which will be supported by some class A _after_ that operator's class
template
> will be applied to it (i.e. A will support 'operator!' only after A will
be
> derived from 'negatable') ; some other library's templates, and
> 'less_than_comparable' is one of them, work in the opposite way - if A is
> _already_ LessThanComparable, i.e. it defines 'operator<', which returns
type
> convertible to 'bool' and defines a strict weak ordering relation, then
our
> 'less_than_comparable' template will add another 3 relational operators to
it
> and make the class to suppport another, less (or is it more?) restrictive
> concept that Jeremy calls 'Comparable'; and yet other ones, such as
'addable',
> are something in between: there are no standard 'Addable' concept, but I
> assume that if it exist it would require both 'operator+=' and 'operator+'
for
> the class to be defined; assuming that, I'd interpret the semantics of our
> 'addable' template in this way: if you want the 'Addable' concept to be
> supported, you need to implement a particular part of it, 'operator+=', by
> yourself, and then the 'boost::addable' operator's class template will do
the
> rest of the job for you. Nothing wrong with it, of course, but it's the
3-rd
> kind of semantics associated with the these class templates' names.
>
> That's why I said that I think that 'less_than_comparable' does not match
the
> standard definition - I just thought that it was supposed to have the
> semantics of 'negatable' (which, I thought was the only one possible :),
and
> no wonder the whole thing seemed wrong to me.

You're right. I have been trying to avoid bringing that conclusion out into
the open for days now ;-)

> Well, did I really clarified anything? ;)

At least you clarified that we have a problem. What would be really clear
would be a proposal for a consistent naming scheme. Looking at the names we
currently have, what most have in common is that the templates "complete the
concept" they're describing by filling in missing operators. I don't think
it's a problem that we don't have standard Concepts for most of these
things. We shouldn't be trying to define them here, either. Let's think in
terms of "concepts" with a small "c". Here's the list of names I extracted
from v15 of dlw_oprs, for reference (a few may be missing; I used automated
seaarch/replace tools):

less_than_comparable
equality_comparable
multipliable
addable
subtractable
dividable
modable
xorable
andable
orable
incrementable
decrementable
dereferenceable
indexable
left_shiftable
right_shiftable
idempotent
logically_invertable
totally_ordered
additive
multiplicative
integer_multiplicative
arithmetic
integer_arithmetic
bitwise_combinable
unit_steppable
floating_operators
integral_operators
place_value_integral_operators
input_iterator_operators
bidirectional_iterator_operators
operators
bidirectional_iterator_helper