Francis Glassborow wrote:

> In article <d64jn6$ovb$1@sklad.atcom.net.pl>, Krzysztof =AFelechowski=20
> <yecril@bluebottle.com.invalid> writes
>=20
>> What is unreasonable in the code
>>
>> class AbsLess {
>> public: static operator()(signed i1, signed i2) {
>> return abs(i1) < abs(i2);
>> };
>=20
> Well to start with operator() needs a return type. However, more to the=
=20
> point, how do you intend to use it which would different from writing
>=20
> bool AbsLess(int i1, int i2){
>   return abs(i1) < abs(i2);
> }
>=20
>=20
> I just cannot see what you think operator() would buy as a static membe=
r=20
> function.

In terms of maintanability, it would document that the
function does not depend on *this.

In terms of performance, it would avoid the need to pass
the this argument to the function.  (However, it's often
possible for that, and the function call overhead, to be
completely optimized away.  Just not always.)

One thing, though, that's reasonable is that when code
invokes
   object(arg1,arg2)
we should expect to pass three arguments to some operator(),
specifically &object, arg1, and arg2.  (And if C++ had
had references earlier in its life, this might have been
a reference, and we'd be passing object, arg1, and arg2.)
On the other hand, we can invoke other static member
functions as object.function(arg1,arg2) where the compiler
evaluates object only for side-effects and does not pass
it to function.

I can see arguments for and against disallowing "static"
in this context, but don't see there being anywhere near
enough reason to change the existing rule.  The cost of
changing it far outweighs any possible benefit.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]