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

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-01-04 12:38:37

Daryle Walker wrote:

> Aleksey Gurtovoy wrote:
> > 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?

Yes, I think it is an unnecessary one. The less code we have, the better ;)
(given that it provides the same functionality)

> I almost always define it for my classes (as appropriate, of course).

I know that that's a matter of style, but for me writing additional code which
duplicates a behavior/functionality already guaranteed by the language
definition seems as a questionable practice because:
  a) no matter how simple the behavior/functionality is, having a code which
implements it by hand means that there is always a chance that at some point
it will do a wrong thing; for example, defining a copy assignment operator for
a class, for which the implicitly-defined one would be perfectly ok, is a bad
thing because there is a chance that later someone will add a member to this
class and forget to modify the copying code.
  b) even if you can guarantee that the code will always do what is expected
(e.g. you have tools which help you to insure this), an additional code means
additional maintenance efforts, and you should always try to minimize the
latter.
  c) additional code can increase compilation time and, in some cases, visibly
decrease an amount of available compiler's internal resources, thus preventing
from compiling a code which compiler would be able to handle overwise; for
example, inheriting from 'negatable' operator template will result in
requiring the compiler to be able to handle at least 2 more levels of
recursively nested template instantiations.
  d) unnecessary code clutters the big picture (class definition) and makes
programmers spend their time finding out why the code exists and what does it
do; of course programmers should do the latter for any line of code they don't
understand, but if the code is unnecessary, this activity is just waste of
time and IMO a reliable way to make some programmers angry ;) (it forces you
to look up and analyze the definition of member function(s) only to find out
that it does the same thing as the generated by compiler version would).

> 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.

For me 'operator bool()' is already "complete", as you are not required to
define anything else to make things work properly. IMO term "completeness" is
more appropriate for describing relationships between something like
(necessary) copy constructor, copy assignment operator and destructor, where
often missing one of the components leads to unreasonable limitations on class
usage.

> > 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).

Well, the operators' naming scheme says that "A name of each operator class
template indicates a concept, which will be supported by a target class after
applying that template to it", and IMO 'plusable' does fit that definition.
Can't say anything about funny sounding, though - for non-native speaker it's
not much different from 'addable' ;).

--Aleksey