Topic: Address-of-member syntax
Author: "Greg Herlihy" <greghe@pacbell.net>
Date: Mon, 28 Aug 2006 22:13:37 CST Raw View
kanze wrote:
> Greg Herlihy wrote:
> > Marcus wrote:
> > > Out of curiosity... Does anybody know why we use
> > > &Class::member instead of Class::&member?
>
> > For one reason, "Class::&member" would conflict with "&member" inside
> > Class's scope (the latter is an ordinary pointer, and not a member
> > pointer.)
>
> Can you show a case where something lik Class::&member is
> currently anything but a syntax error? I can't think of one.
Class::&member is currently a syntax error. But the point is that if it
were defined, it should be defined as a qualified version of "&member"
instead of as "&Class::member" is defined today. Otherwise, within the
Class class, the meaning of the two expressions "&member" and
"Class::&member" would differ.
> > A better question would probably be why Class::&member is not
> > valid syntax as in, say: this->Class::&member.
>
> What would it mean?
The same as &member does today, only with added qualification.
Currently, a program must use &(Class::member) or &this->Class::member
when qualification is needed. For example:
struct A
{
int member;
};
struct B
{
int member;
};
struct C : public A, public B
{
int * GetIntPtr()
{
/*
return &member; // error: 'member' ambiguous
return B::&member; // error: invalid syntax
return &B::member; // error: type mismatch
*/
return &(B::member); // OK
return &this->B::member; // OK
}
};
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: "kanze" <kanze@gabi-soft.fr>
Date: Tue, 29 Aug 2006 10:41:32 CST Raw View
Greg Herlihy wrote:
> kanze wrote:
> > Greg Herlihy wrote:
> > > Marcus wrote:
> > > > Out of curiosity... Does anybody know why we use
> > > > &Class::member instead of Class::&member?
> > > For one reason, "Class::&member" would conflict with
> > > "&member" inside Class's scope (the latter is an ordinary
> > > pointer, and not a member pointer.)
> > Can you show a case where something lik Class::&member is
> > currently anything but a syntax error? I can't think of
> > one.
> Class::&member is currently a syntax error. But the point is
> that if it were defined, it should be defined as a qualified
> version of "&member" instead of as "&Class::member" is defined
> today.
What's a "qualified version of &member"? Currently, names are
qualified, not what they name. If I write member, without
qualification, I get whatever symbol member refers to, according
to unqualified name lookup. If I write Class::member, name
lookup takes place only in that class.
> Otherwise, within the Class class, the meaning of the two
> expressions "&member" and "Class::&member" would differ.
Yes, but why should the second be legal to begin with?
> > > A better question would probably be why Class::&member is
> > > not valid syntax as in, say: this->Class::&member.
> > What would it mean?
> The same as &member does today, only with added qualification.
Qualification of what? Names are qualified, not expressions. I
can write C::a + b, with the name of a qualified, but it makes
no sense to write C::(a + b), because the results of an
expression is a value, not a symbol. Qualification affects name
lookup, and not values. (There are a few exceptions. In a
function call, if the name of the function is a qualified name,
then dynamic dispatch is not used. Which seems a bit arbitrary,
when you think of it---there is no way to inhibit dynamic
dispatch when calling through a pointer to member function, for
example.)
> Currently, a program must use &(Class::member) or
> &this->Class::member when qualification is needed.
Which is normal: you put the qualifier in front of what is being
qualified.
> For example:
> struct A
> {
> int member;
> };
> struct B
> {
> int member;
> };
> struct C : public A, public B
> {
> int * GetIntPtr()
> {
> /*
> return &member; // error: 'member' ambiguous
> return B::&member; // error: invalid syntax
> return &B::member; // error: type mismatch
> */
> return &(B::member); // OK
> return &this->B::member; // OK
> }
> };
Which all seems perfectly natural once you understand what
qualification is. Why do you want to apply it to expressions?
(And presumably only to some expressions---I doubt that you want
A::(a + b). So why some expressions, and not others?)
--
James Kanze GABI Software
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: "Yuu" <yuu@yyhmail.com>
Date: Tue, 29 Aug 2006 10:59:00 CST Raw View
Greg:
> Class::&member is currently a syntax error. But the point is that if it
> were defined, it should be defined as a qualified version of "&member"
A qualified version of &member would be &Class::member (::& would be
understood as a single operator).
Currently, a qualified version of &member is expressed as a very
confusing &(Class::member) or &this->Class::member, as you explain in
your message (quoted below). By using ::&, the meaning of
&Class::member and &(Class::member) could be the same, as one would
expect. Too bad this is not how the language evolved...
> Currently, a program must use &(Class::member) or &this->Class::member
> when qualification is needed. For example:
>
> struct A
> {
> int member;
> };
>
> struct B
> {
> int member;
> };
>
> struct C : public A, public B
> {
> int * GetIntPtr()
> {
> /*
> return &member; // error: 'member' ambiguous
> return B::&member; // error: invalid syntax
> return &B::member; // error: type mismatch
> */
>
> return &(B::member); // OK
> return &this->B::member; // OK
> }
> };
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: "Marcus" <yuu@yyhmail.com>
Date: Fri, 25 Aug 2006 22:06:04 CST Raw View
Out of curiosity... Does anybody know why we use &Class::member instead
of Class::&member? The second form is more consistent with ::*, .* and
->*.
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: musiphil@bawi.org (Seungbeom Kim)
Date: Sat, 26 Aug 2006 06:27:53 GMT Raw View
Marcus wrote:
> Out of curiosity... Does anybody know why we use &Class::member instead
> of Class::&member? The second form is more consistent with ::*, .* and
> ->*.
We are taking the address of (Class::member), hence the notation
&Class::member. On the other hand, in the case of class::*pm, obj.*pm
or ptr->*pm, (*pm) specifies the name of a member without specifying the
object (you can mentally replace it with the actual name of the member),
so *pm can be taken as a conceptual unit.
--
Seungbeom Kim
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: "Greg Herlihy" <greghe@pacbell.net>
Date: Sun, 27 Aug 2006 17:14:06 CST Raw View
Marcus wrote:
> Out of curiosity... Does anybody know why we use &Class::member instead
> of Class::&member?
For one reason, "Class::&member" would conflict with "&member" inside
Class's scope (the latter is an ordinary pointer, and not a member
pointer.) A better question would probably be why Class::&member is not
valid syntax as in, say: this->Class::&member.
> The second form is more consistent with ::*, .* and
> ->*.
The syntax for operations involving objects should be distinct from the
syntax for operations involving classes (such as obtaining a member
pointer for a class).
Greg
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: "kanze" <kanze@gabi-soft.fr>
Date: Mon, 28 Aug 2006 10:21:55 CST Raw View
Greg Herlihy wrote:
> Marcus wrote:
> > Out of curiosity... Does anybody know why we use
> > &Class::member instead of Class::&member?
> For one reason, "Class::&member" would conflict with "&member" inside
> Class's scope (the latter is an ordinary pointer, and not a member
> pointer.)
Can you show a case where something lik Class::&member is
currently anything but a syntax error? I can't think of one.
> A better question would probably be why Class::&member is not
> valid syntax as in, say: this->Class::&member.
What would it mean?
--
James Kanze GABI Software
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
---
[ 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.comeaucomputing.com/csc/faq.html ]