Re: Ready to add dlw_oprs.zip?

From: Daryle Walker (darylew_at_[hidden])
Date: 2000-12-23 22:25:36

on 12/21/00 9:12 AM, Aleksey Gurtovoy at alexy_at_[hidden] wrote:

> Dave Abrahams wrote:
>> 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.

> I agree.

>> Let's think in terms of "concepts" with a small "c".

> I like this one. We can make a slogan from it, you know :).

> BTW, I just realized that 'negatable' class template is pretty much useless,
> because if some class is already convertible to 'bool' (which is the
> requirement of the template), you already can write 'if (!some_class())' - no
> need to inherit from 'negatable'. It's a pity, because it was a pretty name
> ;).

Are you implying that it should be removed?  Because it's staying for now.
I almost always define it for my classes (as appropriate, of course).  Even
if this automatic use of Boolean conversions can indirectly synthesize a
version of operator!(), you are still free to directly define operator!()
anyway.  It's nice to have for completeness.

However, I don't define the other logical functions, operator&&() and
operator||().  The problem is that the short-circuit evaluation rule only
works both operands are of a built-in type or an user-defined type that can
be converted to a built-in type.  Adding direct definitions of the binary
logical operators for a class disables short-circuit evaluation, because
those overloaded operators get converted to secret function calls, which
must have all their arguments evaluated.

> But, on the other hand, now we have only two kinds of operators names'
> semantics ('cause I believe that 'negatable' was the only pure representative
> of "implement the concept from scratch" kind of templates), so if things will
> continue to go in this way, soon there will be no problem :). On second
> thought, actually 'idempotent' template is even more pure, because it does not
> require _anything_ from the class it is applied to; but by its name it should
> be categorized to the same category as 'less_than_comparable', so still 2
> categories remain :)

It's still 3 categories for now.

> As for a proposal for a consistent naming scheme - I am not sure that the
> following is quite that, but at least it's something ;) :

[SNIP scheme]

I wasn't planning on changing the names of existing classes, so previous
users won't have their code break.  What about backwards compatibility?

> Given that all the above makes sense, I believe that 'less_then_comparable'
> and 'equality_comparable' templates are the only ones left <g> :) which does
> not match the described principles. What do you think?

> Ok, the last remark, what do you think of 'plusable' as a replacement of
> 'idempotent'? (in the light of the above, of course :)

I rejected that quickly when determining the template's name.  It sounds
funny (bad) and gives the wrong connotation, since the template gives an
identity operation, not one that combines (i.e. confusion with addable).

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com