Topic: Why must pointer-to-member-function repeat the type


Author: yecril@bluebottle.com ("Krzysztof elechowski")
Date: Tue, 17 May 2005 23:26:23 GMT
Raw View
U   ytkownik ""Ivan Godard"" <igodardA@TpacbellDO.Tnet> napisa    w wiadomo   ci
news:CHaCc.76618$mX7.52523@newssvr29.news.prodigy.com...
> struct A{
>    void Foo(){}
> };
> A a;
> &a.Foo;
>
> gets you (gcc3.4.0):
> foo.cc:13: error: ISO C++ forbids taking the address of a bound member
> function to form a pointer to member function.  Say `&A::Foo'
>
>
> When working with templates, the type of the class may be combersome or
> unavailable even though you have an object
> of that class. Why does the standard prohibit getting a
> pointer-to-member-function from an object when that is convenient?
>

It could also help as a replacement for dynamic_cast (which is switched off
by default by my compiler).

In the scene

class X {
public: virtual ~X(void);
};

class Y: public X {
public: ~Y(void);
};

you could have a dynamic cast from the function

inline Y *get_Y(X *pX) {
return &pX->~X == &Y::~Y? static_cast<Y *>(pX): 00;
}

without using RTTI.

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                       ]





Author: AlbertoBarbati@libero.it (Alberto Barbati)
Date: Wed, 18 May 2005 05:40:57 GMT
Raw View
Krzysztof =AFelechowski wrote:
>=20
> It could also help as a replacement for dynamic_cast (which is switched=
 off=20
> by default by my compiler).
>=20
> In the scene
>=20
> class X {
> public: virtual ~X(void);
> };
>=20
> class Y: public X {
> public: ~Y(void);
> };
>=20
> you could have a dynamic cast from the function
>=20
> inline Y *get_Y(X *pX) {
> return &pX->~X =3D=3D &Y::~Y? static_cast<Y *>(pX): 00;
> }
>=20
> without using RTTI.
>=20

Problems are:

1) I guess the OP was talking about a resolution based on the static
type of the left operand, while your code would require using its
dynamic type, which is a completely different issue

2) you just can't take the address of a destructor (see =A712.4/2)

Alberto

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





Author: igodardA@TpacbellDO.Tnet ("Ivan Godard")
Date: Wed, 23 Jun 2004 19:48:08 +0000 (UTC)
Raw View
struct A{
    void Foo(){}
};
A a;
&a.Foo;

gets you (gcc3.4.0):
foo.cc:13: error: ISO C++ forbids taking the address of a bound member
function to form a pointer to member function.  Say `&A::Foo'


When working with templates, the type of the class may be combersome or
unavailable even though you have an object
of that class. Why does the standard prohibit getting a
pointer-to-member-function from an object when that is convenient?

Thank you.

Ivan Godard

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





Author: eldiener@earthlink.net ("Edward Diener")
Date: Thu, 24 Jun 2004 00:09:46 +0000 (UTC)
Raw View
"Ivan Godard" wrote:
> struct A{
>     void Foo(){}
> };
> A a;
> &a.Foo;
>
> gets you (gcc3.4.0):
> foo.cc:13: error: ISO C++ forbids taking the address of a bound member
> function to form a pointer to member function.  Say `&A::Foo'
>
>
> When working with templates, the type of the class may be combersome
> or unavailable even though you have an object
> of that class. Why does the standard prohibit getting a
> pointer-to-member-function from an object when that is convenient?

First off, I agree that being able to get a "pointer to member function" as
a bound address would be desirable in C++. Current C++ defines a pointer to
member function as an unbound address, and the syntax of that is as above,
'&A::Foo'. The standard way of using such an address is to bind the address
to an actual object upon invocation, using syntax of the form (a.*pmem)()
for an object of type A and
(a->*pmem)() for a pointer to an object of type A, where pmem is a pointer
to member function of type 'void A::*()'.

There are also clever template functions and template classes like
std::bind1st, std::bind2nd, and boost::bind that let you manufacture a bound
address, as a function object, from an object and a C++ pointer to member
function. The latter is especially adaptable in letting one create your
"pointer to member function" as a bound address and boost::function can,
among other function-like addresses, hold on to the result.

It should be noted that Borland's C++ Builder allows one to do exactly what
you want above through an extension to C++ called a __closure. This is
non-standard C++ which makes it easy to pass around a "pointer to member
function" as a bound address and assign it to a __closure type, to be used
in the case of callbacks and events. With boost::function one can do this,
though with a little more code, in standard C++, and the creator of
boost::function, Mr. Gregor, has also created a C++ event-driven
implementation based on boost::function called boost::signals.

The boost::function and boost::bind implementations have been accepted into
TR1 of the C++ standard process, and I am personally hopeful that
boost::signals will be accepted also eventually. In lieu of your "pointer to
member function" as a bound address suggestion, these will hopefully be
these future C++ standard library versions of what you want. Needless to
say, boost::bind and boost::function also offer other capabilities which go
beyond the "pointer to member function" as a bound address functionality
which you desire.

But I do agree with you that having a native type of "pointer to member
function" as a bound address in C++, being able to declare an object of that
type ( of the correct function prototype ), and being able to take the
address of an actual object's member function as a value of that type is a
much more syntactically elelgant way of doing things than even the brilliant
implementations of boost::function and boost::bind.









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





Author: igodardA@TpacbellDO.Tnet ("Ivan Godard")
Date: Thu, 24 Jun 2004 04:19:30 +0000 (UTC)
Raw View
""Edward Diener"" <eldiener@earthlink.net> wrote in message
news:PBoCc.23754$Y3.10393@newsread2.news.atl.earthlink.net...
> "Ivan Godard" wrote:
> > struct A{
> >     void Foo(){}
> > };
> > A a;
> > &a.Foo;
> >
> > gets you (gcc3.4.0):
> > foo.cc:13: error: ISO C++ forbids taking the address of a bound member
> > function to form a pointer to member function.  Say `&A::Foo'
> >
> >
> > When working with templates, the type of the class may be combersome
> > or unavailable even though you have an object
> > of that class. Why does the standard prohibit getting a
> > pointer-to-member-function from an object when that is convenient?
>
> First off, I agree that being able to get a "pointer to member function"
as
> a bound address would be desirable in C++. Current C++ defines a pointer
to
> member function as an unbound address, and the syntax of that is as above,
> '&A::Foo'. The standard way of using such an address is to bind the
address
> to an actual object upon invocation, using syntax of the form (a.*pmem)()
> for an object of type A and
> (a->*pmem)() for a pointer to an object of type A, where pmem is a pointer
> to member function of type 'void A::*()'.
>
> There are also clever template functions and template classes like
> std::bind1st, std::bind2nd, and boost::bind that let you manufacture a
bound
> address, as a function object, from an object and a C++ pointer to member
> function. The latter is especially adaptable in letting one create your
> "pointer to member function" as a bound address and boost::function can,
> among other function-like addresses, hold on to the result.
>
> It should be noted that Borland's C++ Builder allows one to do exactly
what
> you want above through an extension to C++ called a __closure. This is
> non-standard C++ which makes it easy to pass around a "pointer to member
> function" as a bound address and assign it to a __closure type, to be used
> in the case of callbacks and events. With boost::function one can do this,
> though with a little more code, in standard C++, and the creator of
> boost::function, Mr. Gregor, has also created a C++ event-driven
> implementation based on boost::function called boost::signals.
>
> The boost::function and boost::bind implementations have been accepted
into
> TR1 of the C++ standard process, and I am personally hopeful that
> boost::signals will be accepted also eventually. In lieu of your "pointer
to
> member function" as a bound address suggestion, these will hopefully be
> these future C++ standard library versions of what you want. Needless to
> say, boost::bind and boost::function also offer other capabilities which
go
> beyond the "pointer to member function" as a bound address functionality
> which you desire.
>
> But I do agree with you that having a native type of "pointer to member
> function" as a bound address in C++, being able to declare an object of
that
> type ( of the correct function prototype ), and being able to take the
> address of an actual object's member function as a value of that type is a
> much more syntactically elelgant way of doing things than even the
brilliant
> implementations of boost::function and boost::bind.

Well thank you, but you are actually wanting more than I was asking for. I
wasn't looking for a bound address (although in other contexts that would be
useful). I was looking for a plain old current-standard
pointer-to-member-function kind of pointer. That is, I'd like:
    struct A { void Foo(){} };
    A a;
    &a.Foo
to give me exactly what:
    &A::Foo
gives now, or what:
    &typeof(a)::Foo
would if there were a 'typeof' to do it.

But I guess that you have answered my question (that is, why doesn't the
standard permit this): the notation is being saved for use in generating
bound pointers in some future language upgrade. That seems reasonable to
me - do you know if it is true?

Ivan

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





Author: eldiener@earthlink.net ("Edward Diener")
Date: Fri, 25 Jun 2004 05:37:25 +0000 (UTC)
Raw View
"Ivan Godard" wrote:
> ""Edward Diener"" <eldiener@earthlink.net> wrote in message
> news:PBoCc.23754$Y3.10393@newsread2.news.atl.earthlink.net...
>> "Ivan Godard" wrote:
> Well thank you, but you are actually wanting more than I was asking
> for. I wasn't looking for a bound address (although in other contexts
> that would be useful). I was looking for a plain old current-standard
> pointer-to-member-function kind of pointer. That is, I'd like:
>     struct A { void Foo(){} };
>     A a;
>     &a.Foo
> to give me exactly what:
>     &A::Foo
> gives now, or what:
>     &typeof(a)::Foo
> would if there were a 'typeof' to do it.
>
> But I guess that you have answered my question (that is, why doesn't
> the standard permit this): the notation is being saved for use in
> generating bound pointers in some future language upgrade. That seems
> reasonable to
> me - do you know if it is true?

No, I do not think it is true, especially given that boost::bind and
boost::function seem to be very likely parts of the next C++ standard
library, but I couldn't tell you what is being considered other than what
has been already published.

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