can the member function be compared?

for example, there is a class as below

struct Foo
{
void Func1()
{}
void Func2()
{}
};

As known, &Foo::Func1 != &Foo::Func2 is right, but &Foo::Func1 < &Foo::Func2
is illegal. So std::map< void ( Foo::* )() > can not be defined. Are there
some other ways to get the greater and less relationship between two member
functions?

Thanks!

Mark
Thu Oct 25 09:36:21 PDT 2007

Bill, Bill, Bill... *shaking head in disbelief*



"Bill Gates" <NO1@microsoft.com> wrote in message
news:u02y6DyFIHA.748@TK2MSFTNGP04.phx.gbl...
> for example, there is a class as below
>
> struct Foo
> {
> void Func1()
> {}
> void Func2()
> {}
> };
>
> As known, &Foo::Func1 != &Foo::Func2 is right, but &Foo::Func1 <
> &Foo::Func2
> is illegal. So std::map< void ( Foo::* )() > can not be defined. Are there
> some other ways to get the greater and less relationship between two
> member
> functions?
>
> Thanks!
>
>

Alex
Thu Oct 25 10:36:28 PDT 2007

"Bill Gates" wrote:
> for example, there is a class as below
>
> struct Foo
> {
> void Func1()
> {}
> void Func2()
> {}
> };
>
> As known, &Foo::Func1 != &Foo::Func2 is right, but
> &Foo::Func1 < &Foo::Func2
> is illegal. So std::map< void ( Foo::* )() > can not be
> defined. Are there
> some other ways to get the greater and less relationship
> between two member
> functions?

The "&Foo::Func1 < &Foo::Func2" expression is perfectly
legal if both `Func1' and `Func2' are within the same access
level block. I.e., if `Func1' and `Func2' are not separated
by "public", "protected" or "private" labels, then their
comparison is legal and valid.

Here's the quote from the Standard:

<quote>
5.9/2 Relational operators

? If two pointers point to nonstatic data members of the
same object, or to subobjects or array elements of such
members, recursively, the pointer to the later declared
member compares greater provided the two members are not
separated by an `access-specifier' label (11.1) and provided
their class is not a union.
? If two pointers point to nonstatic data members of the
same object separated by an `access-specifier' label (11.1)
the result is unspecified.
</quote>


Alex

Igor
Thu Oct 25 10:50:07 PDT 2007

Alex Blekhman <tkfx.REMOVE@yahoo.com> wrote:
> "Bill Gates" wrote:
>> for example, there is a class as below
>>
>> struct Foo
>> {
>> void Func1()
>> {}
>> void Func2()
>> {}
>> };
>>
>> As known, &Foo::Func1 != &Foo::Func2 is right, but
>> &Foo::Func1 < &Foo::Func2
>> is illegal. So std::map< void ( Foo::* )() > can not be
>> defined. Are there
>> some other ways to get the greater and less relationship
>> between two member
>> functions?
>
> The "&Foo::Func1 < &Foo::Func2" expression is perfectly
> legal if both `Func1' and `Func2' are within the same access
> level block. I.e., if `Func1' and `Func2' are not separated
> by "public", "protected" or "private" labels, then their
> comparison is legal and valid.
>
> Here's the quote from the Standard:
>
> <quote>
> 5.9/2 Relational operators
>
> If two pointers point to nonstatic data members of the
> same object, or to subobjects or array elements of such
> members, recursively, the pointer to the later declared
> member compares greater provided the two members are not
> separated by an `access-specifier' label (11.1) and provided
> their class is not a union.
> If two pointers point to nonstatic data members of the
> same object separated by an `access-specifier' label (11.1)
> the result is unspecified.
> </quote>

Note that this paragraph talks about regular pointers to data members.
It's not applicable to pointers-to-members. 5.9/1 is applicable though:

5.9/1 The operands shall have arithmetic, enumeration or pointer type.

Note further that, according to 3.9.2/1, pointer types and
pointers-to-member types are different kinds of types.

If you are still not convinced, look at the stadnard definition for
equality (==) operator:

5.10/1 The == (equal to) and the != (not equal to) operators have the
same semantic restrictions, conversions, and result type as the
relational operators...
5.10/2 In addition, pointers to members can be compared...

Bottom line - pointers-to-members cannot be compared for inequality.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Alex
Thu Oct 25 11:16:47 PDT 2007

"Igor Tandetnik" wrote:
>> The "&Foo::Func1 < &Foo::Func2" expression is perfectly
>> legal if both `Func1' and `Func2' are within the same
>> access
>> level block.
>> [...]
>
> Note that this paragraph talks about regular pointers to
> data members. It's not applicable to pointers-to-members.
> [...]
>
> Bottom line - pointers-to-members cannot be compared for
> inequality.

You're right. My bad. Somehow I mistook pointers-to-members
for regular pointers to data members. Hm..

Bill
Thu Oct 25 22:44:56 PDT 2007

Igor Tandetnik wrote:
> Alex Blekhman <tkfx.REMOVE@yahoo.com> wrote:
>> "Bill Gates" wrote:
>>> for example, there is a class as below
>>>
>>> struct Foo
>>> {
>>> void Func1()
>>> {}
>>> void Func2()
>>> {}
>>> };
>>>
>>> As known, &Foo::Func1 != &Foo::Func2 is right, but
>>> &Foo::Func1 < &Foo::Func2
>>> is illegal. So std::map< void ( Foo::* )() > can not be
>>> defined. Are there
>>> some other ways to get the greater and less relationship
>>> between two member
>>> functions?
>> The "&Foo::Func1 < &Foo::Func2" expression is perfectly
>> legal if both `Func1' and `Func2' are within the same access
>> level block. I.e., if `Func1' and `Func2' are not separated
>> by "public", "protected" or "private" labels, then their
>> comparison is legal and valid.
>>
>> Here's the quote from the Standard:
>>
>> <quote>
>> 5.9/2 Relational operators
>>
>> If two pointers point to nonstatic data members of the
>> same object, or to subobjects or array elements of such
>> members, recursively, the pointer to the later declared
>> member compares greater provided the two members are not
>> separated by an `access-specifier' label (11.1) and provided
>> their class is not a union.
>> If two pointers point to nonstatic data members of the
>> same object separated by an `access-specifier' label (11.1)
>> the result is unspecified.
>> </quote>
>
> Note that this paragraph talks about regular pointers to data members.
> It's not applicable to pointers-to-members. 5.9/1 is applicable though:
>
> 5.9/1 The operands shall have arithmetic, enumeration or pointer type.
>
> Note further that, according to 3.9.2/1, pointer types and
> pointers-to-member types are different kinds of types.
>
> If you are still not convinced, look at the stadnard definition for
> equality (==) operator:
>
> 5.10/1 The == (equal to) and the != (not equal to) operators have the
> same semantic restrictions, conversions, and result type as the
> relational operators...
> 5.10/2 In addition, pointers to members can be compared...
>
> Bottom line - pointers-to-members cannot be compared for inequality.

It seems that the greater or less relationship can not be gotten...
So another question is like below,
/*
struct Foo
{
void Func1(){}
void Func2(){}
};
*/
void* ptr = &( &Foo::Func1 );
Is the above line legal? And what dose the ptr pointer point to?

Thanks!

nathan
Thu Oct 25 23:16:02 PDT 2007

In article <eke7YN5FIHA.6068@TK2MSFTNGP05.phx.gbl>,
Bill Gates <NO1@microsoft.com> wrote:
>It seems that the greater or less relationship can not be gotten...

Maybe it would help if you explained out *precisely* what you're
trying to accomplish. Why the heck does it matter to you what order
functions lie in memory? Go mess with your linker options and generate
a .map file if you're somewhat curious.

Nathan Mates

--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein

Bill
Fri Oct 26 00:24:09 PDT 2007

Nathan Mates wrote:
> In article <eke7YN5FIHA.6068@TK2MSFTNGP05.phx.gbl>,
> Bill Gates <NO1@microsoft.com> wrote:
>> It seems that the greater or less relationship can not be gotten...
>
> Maybe it would help if you explained out *precisely* what you're
> trying to accomplish. Why the heck does it matter to you what order
> functions lie in memory? Go mess with your linker options and generate
> a .map file if you're somewhat curious.
>
> Nathan Mates
>
> --
> <*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
> # Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
> # NOT speaking for Pandemic Studios. "Care not what the neighbors
> # think. What are the facts, and to how many decimal places?" -R.A. Heinlein

In fact, I need search in a member functions collection. If the member
functions can be ordered, it will be quick to search with some
arithmetic like binary search. If not, I will have to find the target
member function one by one in the collection.

:>
Thanks

Alex
Fri Oct 26 01:07:16 PDT 2007

"Bill Gates" wrote:
> In fact, I need search in a member functions collection.
> If the member functions can be ordered, it will be quick
> to search with some arithmetic like binary search. If not,
> I will have to find the target member function one by one
> in the collection.

If this collection is not too big, then the difference will
be negligible. Even for thousands of elements you'll hardly
notice any difference on modern computers.

Alex

Bill
Fri Oct 26 02:59:49 PDT 2007

Alex Blekhman wrote:
> "Bill Gates" wrote:
>> In fact, I need search in a member functions collection. If the member
>> functions can be ordered, it will be quick to search with some
>> arithmetic like binary search. If not, I will have to find the target
>> member function one by one in the collection.
>
> If this collection is not too big, then the difference will be
> negligible. Even for thousands of elements you'll hardly notice any
> difference on modern computers.
>
> Alex
You are right. Thank you very much!
But I found, the code like the following line can be compiled
bool fRet = (void*)(&(&Foo::Func1)) < (void*)(&(&Foo::Func2));

So we can set a void pointer's value to be the reference of the member
function like below
void* ptr = ( void* )( &( &Foo::Func1 ) );
Now, I have a question about the pointer ptr. What dose the pointer ptr
point to?
In the standard, is this defined? (Sorry, I have no C++ ISO standard doc)

Thanks a lot!

Alex
Fri Oct 26 04:07:31 PDT 2007

"Bill Gates" wrote:
> But I found, the code like the following line can be
> compiled
> bool fRet = (void*)(&(&Foo::Func1)) <
> (void*)(&(&Foo::Func2));
>
> So we can set a void pointer's value to be the reference
> of the member function like below
> void* ptr = ( void* )( &( &Foo::Func1 ) );
> Now, I have a question about the pointer ptr. What dose
> the pointer ptr point to?
> In the standard, is this defined? (Sorry, I have no C++
> ISO standard doc)

The value of `ptr' is undefined. Pointer to member is not
like regular pointer. Think about it as a struct. It can be
different in size. Moreover, pointer to member may not
contain an address at all. The only requirement for pointer
to member is to be able to call class' method via operators
`.*' and `->*'. Also, it should be comparable to NULL.

I mistakenly assumed in my previous post that pointers to
member of the _same class_ can be compared one with another
anyway, since a compiler could infer the real address of
method's body. However, Igor corrected me.

If you need to distinguish between pointers to member
function, then you could make arbitrary index for them. Like
this:

struct X
{
enum OP { OP_A, OP_B, ... };

void opA(int param1, int param2);
void opB(int param1, int param2);
...

typedef std::map<OP, void (X::*)(int, int)> OPMap;

OPMap m_opMap;
};

Then you could populate the map like this:

m_opMap[OP_A] = &X::opA;
m_opMap[OP_B] = &X::opB;
...


HTH
Alex

Igor
Fri Oct 26 04:58:17 PDT 2007

"Bill Gates" <NO1@microsoft.com> wrote in message
news:eke7YN5FIHA.6068@TK2MSFTNGP05.phx.gbl
> /*
> struct Foo
> {
> void Func1(){}
> void Func2(){}
> };
> */
> void* ptr = &( &Foo::Func1 );
> Is the above line legal?

No more than

int x;
void* p = &(&x);

&x is an rvalue. You cannot take an address of an rvalue.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Igor
Fri Oct 26 05:01:24 PDT 2007

"Bill Gates" <NO1@microsoft.com> wrote in message
news:Oret1E6FIHA.1204@TK2MSFTNGP03.phx.gbl
> Nathan Mates wrote:
>> Maybe it would help if you explained out *precisely* what you're
>> trying to accomplish.
>
> In fact, I need search in a member functions collection.

Take another step back. _Why_ do you feel you need such a collection?
Describe the problem you are trying to solve, not the (hopeless, IMHO)
solution you came up with.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Ulrich
Fri Oct 26 05:25:24 PDT 2007

Bill Gates wrote:
> But I found, the code like the following line can be compiled
> bool fRet = (void*)(&(&Foo::Func1)) < (void*)(&(&Foo::Func2));

So what? Lot's of broken code can be compiled! You can decompose the above
code like this:

// pointers to memberfunctions
void (Foo::*tmp1)() = &Foo::Func1;
void (Foo::*tmp2)() = &Foo::Func2;
// pointers to local objects
void* ptr1 = &tmp1;
void* ptr2 = &tmp2;
// compare address of locals
bool fRet = ptr1 < ptr2;

The reason you need the casts is that (as was pointed out) the result of '&'
is an rvalue.

Seriously, I would suggest that you use memcmp() on the pointers instead. In
the unlikely case that they contain padding bytes you will get false
negatives, but if you put this into a suitable wrapper class, add according
unittest and make sure that is properly documented as a hack the next one
porting the code will not have too many problems. OTOH, then you can also
cast the function pointers to void* and compare those, it should work just
as well. Other than that, there simply is no way to compare function
pointers for anything but equality.

I could think up some more ways, but those would be unnecessarily
complicated, like e.g. mapping the function pointer (which can be a
template argument, I think) to an integral ID using a template class with a
static member. Still, it IMHO isn't worth the effort.

Uli

Jeff_Relf
Fri Oct 26 06:22:42 PDT 2007

You can build a sorted list of pointers ( to functions ).

Alexander
Fri Oct 26 07:47:13 PDT 2007

By the way, conversion, even cast, of a function pointer (even of a static
one) to void* is technically illegal by the standard.

"Ulrich Eckhardt" <eckhardt@satorlaser.com> wrote in message
news:lu29v4-ong.ln1@satorlaser.homedns.org...
> Bill Gates wrote:
>> But I found, the code like the following line can be compiled
>> bool fRet = (void*)(&(&Foo::Func1)) < (void*)(&(&Foo::Func2));
>
> So what? Lot's of broken code can be compiled! You can decompose the above
> code like this:
>
> // pointers to memberfunctions
> void (Foo::*tmp1)() = &Foo::Func1;
> void (Foo::*tmp2)() = &Foo::Func2;
> // pointers to local objects
> void* ptr1 = &tmp1;
> void* ptr2 = &tmp2;
> // compare address of locals
> bool fRet = ptr1 < ptr2;
>
> The reason you need the casts is that (as was pointed out) the result of
> '&'
> is an rvalue.
>
> Seriously, I would suggest that you use memcmp() on the pointers instead.
> In
> the unlikely case that they contain padding bytes you will get false
> negatives, but if you put this into a suitable wrapper class, add
> according
> unittest and make sure that is properly documented as a hack the next one
> porting the code will not have too many problems. OTOH, then you can also
> cast the function pointers to void* and compare those, it should work just
> as well. Other than that, there simply is no way to compare function
> pointers for anything but equality.
>
> I could think up some more ways, but those would be unnecessarily
> complicated, like e.g. mapping the function pointer (which can be a
> template argument, I think) to an integral ID using a template class with
> a
> static member. Still, it IMHO isn't worth the effort.
>
> Uli
>

Bill
Fri Oct 26 09:05:51 PDT 2007

Thank you very much! I have try that way like below and it works well

memcmp( &( &Foo::Func1 ), &( &Foo::Func2 ), sizeof( return_type (
Foo::* )( args ) ) );

and the memcmp returns explicit result in any case.
But as Alexander Grigoriev said, the conversion of a function pointer to
void* is illegal.
According to Igor Tandetnik and the others' answers, I have given up trying
to get greater
realationship between two member functions.
And I will find the standard to read. Thanks all :)

From this post, I have known much.

"Ulrich Eckhardt" <eckhardt@satorlaser.com> ????
news:lu29v4-ong.ln1@satorlaser.homedns.org...
> Bill Gates wrote:
> > But I found, the code like the following line can be compiled
> > bool fRet = (void*)(&(&Foo::Func1)) < (void*)(&(&Foo::Func2));
>
> So what? Lot's of broken code can be compiled! You can decompose the above
> code like this:
>
> // pointers to memberfunctions
> void (Foo::*tmp1)() = &Foo::Func1;
> void (Foo::*tmp2)() = &Foo::Func2;
> // pointers to local objects
> void* ptr1 = &tmp1;
> void* ptr2 = &tmp2;
> // compare address of locals
> bool fRet = ptr1 < ptr2;
>
> The reason you need the casts is that (as was pointed out) the result of
'&'
> is an rvalue.
>
> Seriously, I would suggest that you use memcmp() on the pointers instead.
In
> the unlikely case that they contain padding bytes you will get false
> negatives, but if you put this into a suitable wrapper class, add
according
> unittest and make sure that is properly documented as a hack the next one
> porting the code will not have too many problems. OTOH, then you can also
> cast the function pointers to void* and compare those, it should work just
> as well. Other than that, there simply is no way to compare function
> pointers for anything but equality.
>
> I could think up some more ways, but those would be unnecessarily
> complicated, like e.g. mapping the function pointer (which can be a
> template argument, I think) to an integral ID using a template class with
a
> static member. Still, it IMHO isn't worth the effort.
>
> Uli
>

Bill
Fri Oct 26 09:16:22 PDT 2007

In fact, I am just doing some C++ exercise. When learning function pointer,
I found the member function is different with global/static function. It can
be judged which one is less between two same type global functions. But it
can not do between two member functions. So I posted the question.:)

Thanks for you patient answering.

"Igor Tandetnik" <itandetnik@mvps.org> дÈëÓʼþ
news:OZV$vf8FIHA.6068@TK2MSFTNGP02.phx.gbl...
> "Bill Gates" <NO1@microsoft.com> wrote in message
> news:Oret1E6FIHA.1204@TK2MSFTNGP03.phx.gbl
> > Nathan Mates wrote:
> >> Maybe it would help if you explained out *precisely* what you're
> >> trying to accomplish.
> >
> > In fact, I need search in a member functions collection.
>
> Take another step back. _Why_ do you feel you need such a collection?
> Describe the problem you are trying to solve, not the (hopeless, IMHO)
> solution you came up with.
> --
> With best wishes,
> Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925
>
>

Igor
Fri Oct 26 12:20:22 PDT 2007

Bill Gates <NO1@microsoft.com> wrote:
> In fact, I am just doing some C++ exercise. When learning function
> pointer, I found the member function is different with global/static
> function. It can be judged which one is less between two same type
> global functions.

No, not really. The behavior of such comparison is unspecified. From the
standard 5.9/2:

- If two pointers p and q of the same type point to the same ...
function, ... then p<=q and p>=q both yield true and p<q and p>q both
yield false.
- If two pointers p and q of the same type point to ... different
functions, ... the results of p<q, p>q, p<=q, and p>=q are unspecified.

Here's what the word "unspecified" means:

1.3.13 unspecified behavior
behavior, for a well-formed program construct and correct data, that
depends on the implementation. The implementation is not required to
document which behavior occurs.

A particular platform you are working with may do something (you feel
is) reasonable when comparing function pointers, but another platform
(to which your code might be ported at some point) may not.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Tim
Fri Oct 26 23:25:25 PDT 2007

Paul?Allen <Jeff_Relf@Yahoo.COM> wrote:
>
>You can build a sorted list of pointers ( to functions ).

...but not pointers to member functions. That was the original problem
statement.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Jeff_Relf
Sat Oct 27 01:10:43 PDT 2007

â?? member functions â?? don't really interest me, Tim_Roberts,
I just posted something off the top of my head
so I could pretend to be Paul Allen talking to Bill Gates.

Vladimir
Tue Oct 30 04:45:07 PDT 2007

>> Maybe it would help if you explained out *precisely* what you're
>> trying to accomplish. Why the heck does it matter to you what order
>> functions lie in memory? Go mess with your linker options and generate
>> a .map file if you're somewhat curious.

>
> In fact, I need search in a member functions collection. If the member
> functions can be ordered, it will be quick to search with some arithmetic
> like binary search. If not, I will have to find the target member function
> one by one in the collection.

It seems you're talking about a class (possibly abstract) with a virtual
function, and descendants of this class that override virtual function and
do different tasks (e.g. call some functions).