What is unreasonable in the code

class AbsLess {
public: static operator()(signed i1, signed i2) {
return abs(i1) < abs(i2);
};

where an object of class AbsLess is to be used a predicate?  This
restriction seems arbitrary and unmotivated to me.  Please answer if you
happen to know the motivation.
Chris


---
[ 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                       ]

In article <d64jn6$ovb$1@sklad.atcom.net.pl>, Krzysztof =AFelechowski=20
<yecril@bluebottle.com.invalid> writes
>What is unreasonable in the code
>
>class AbsLess {
>public: static operator()(signed i1, signed i2) {
>return abs(i1) < abs(i2);
>};
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

bool AbsLess(int i1, int i2){
   return abs(i1) < abs(i2);
}


I just cannot see what you think operator() would buy as a static member=20
function.


--=20
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/pr=
ojects

---
[ 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                       ]

The whole point of the functor concept is that you have an object that
behaves like a function. If you make the operator() static, it doesn't
need an object to be called. Without any object, it becomes just a
normal function, so it would be better off *declared* as a normal
function (passed into a wrapper class if corresponding functor is
needed).

Samee

---
[ 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                       ]

Lets see what adding operator() (and lets throw in operator[],
operator->, and maybe the cast operators and whichever ones I missed
since they can be argued about the same way):

1. It's a static function and can be used anywhere regular function
pointers are used. Possibily useful for interfacing C++ code with C
code but somewhat a pain in the ass to take the address of it,
especially with overloads and derivation thrown in for good measure. It
would be nice if it were allowed but I've never been inconvenienced by
this in my history of using C++.
2. You don't have to pass a this pointer around. Doing this is just an
optimization on code any remotely decent C++ compiler has no problem
inlining away. I argue that these operators are either usually trivial
to inline away (either they're simple expressions or a call to a
(possibly static) workhorse function) or are complicated but maintain
some internal state anyway. All of the code I have looked at agrees
with me except for maybe the few expression templates that don't
maintain some sort of state, but in this case you *really want* the
compiler to inline all of the code anyway.
3. Document that it doesn't modify internal class state (except for
static members of course). Making it a const member function already
does this though.

For the little benefit this buys you, you would have to add an extra
step to the already complicated lookup rules in the language. Unless
you wanted to make these operators a special case and have them only be
defined inside a class definition, in which case you get little benefit
with who knows what kind of complications to the language.

---
[ 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                       ]

===================================== MODERATOR'S COMMENT:
 It's not clear from the formatting who is the parent poster and who is the followup poster.  Please quote replies.


===================================== END OF MODERATOR'S COMMENT

Uzytkownik "James Dennett" <jdennett@acm.org> napisal w wiadomosci
news:qIthe.6118$eU.4826@fed1read07...

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

Well certainly, I did not call for a modification of the standard.  I just
asked for an explanation for this restriction from someone who knew what the
designer had in mind because the rule seems arbitrary to me.

Regarding your remark about references and this pointer: sometimes I write
code like

X *p = 00;
p->f();

where X::f() checks whether this is valid.  I find this idiom quite useful
when an object can be empty and needs to be dynamically allocated anyhow.

Chris


---
[ 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                       ]

samee.zahur@gmail.com (Samee Zahur) wrote (abridged):
> The whole point of the functor concept is that you have an object that
> behaves like a function. If you make the operator() static, it doesn't
> need an object to be called.

It needs a type. Part of the point is to get static dispatch. The object
is still needed as a convenient way of passing the object's type around
(that is, with syntax consistent with the non-static cases).


> Without any object, it becomes just a normal function, so it would
> be better off *declared* as a normal function (passed into a
> wrapper class if corresponding functor is needed).

I think you mean "declared as a function pointer". A pointer-to-function
has a level of indirection. A functor can circumvent that, making it
potentially more efficient.

-- Dave Harris, Nottingham, UK.

---
[ 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                       ]

Uzytkownik "Samee Zahur" <samee.zahur@gmail.com> napisal w wiadomosci
news:1116147515.726447.106560@g44g2000cwa.googlegroups.com...
> The whole point of the functor concept is that you have an object that
> behaves like a function. If you make the operator() static, it doesn't
> need an object to be called. Without any object, it becomes just a
> normal function, so it would be better off *declared* as a normal
> function (passed into a wrapper class if corresponding functor is
> needed).

You cannot pass an overloaded function when you need all the overloads with
it.  I need to compare int * to char *; it is my problem why, how and what
for, but the algorithms want the predicate arguments to be formally
interchangeable, notably after the advent of Microsoft's debugging iterators
which broke my code formed according to your suggestion.  I can declare a
function to understand less(int *, char *) and less(char *, int*) and
less(char *, char *) and less(int *, int *), but I cannot pass this function
to the algorithm; I have to choose one signature to form a function pointer.

Chris



---
[ 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                       ]

Uzytkownik "Me" <anti_spam_email2003@yahoo.com> napisal w wiadomosci
news:1116203817.601740.268300@g47g2000cwa.googlegroups.com...
> Lets see what adding operator() (and lets throw in operator[],
> operator->, and maybe the cast operators and whichever ones I missed
> since they can be argued about the same way):
>
> 2. You don't have to pass a this pointer around. Doing this is just an
> optimization on code any remotely decent C++ compiler has no problem
> inlining away. I argue that these operators are either usually trivial
> to inline away (either they're simple expressions or a call to a
> (possibly static) workhorse function) or are complicated but maintain
> some internal state anyway. All of the code I have looked at agrees
> with me except for maybe the few expression templates that don't
> maintain some sort of state, but in this case you *really want* the
> compiler to inline all of the code anyway.

Let me rephrase what you said.  Inline static member functions are not
needed at all; the compiler can do without them.  Is this the case?
I still cannot see what is so special about the function call operator that
it is not allowed to be static though.  If you can get a pointer to the
static operator, you can get a member pointer to an operator as well; the
syntax for the latter is even more complicated.  But what is complicated for
a human being to read need not be complicated for the compiler, and vice
versa.

> For the little benefit this buys you, you would have to add an extra
> step to the already complicated lookup rules in the language. Unless
> you wanted to make these operators a special case and have them only be
> defined inside a class definition, in which case you get little benefit
> with who knows what kind of complications to the language.

I do not write compilers so I do not know.  I wanted to get an answer for
somebody who knows.

Chris


---
[ 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                       ]