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?
> 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
> will be applied to it (i.e. A will support 'operator!' only after A will
> 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
> convertible to 'bool' and defines a strict weak ordering relation, then
> 'less_than_comparable' template will add another 3 relational operators to
> and make the class to suppport another, less (or is it more?) restrictive
> concept that Jeremy calls 'Comparable'; and yet other ones, such as
> are something in between: there are no standard 'Addable' concept, but I
> assume that if it exist it would require both 'operator+=' and 'operator+'
> 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
> rest of the job for you. Nothing wrong with it, of course, but it's the
> 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
> standard definition - I just thought that it was supposed to have the
> semantics of 'negatable' (which, I thought was the only one possible :),
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk