Jim Cobban wrote in message <388CC286.B7848872@hotmail.com>...
>Could someone please explain to me the rationale behind the restriction
>documented in paragraph 3 of section 5.3.1 of the standard:
>
>"A pointer to member is only formed when an explicit & is used and ...

My first guess: the guy who got this into the standard had once written

   while(foo){...}

when he had intended

  while(foo()){...}

he couldn't change the rule for existing pointer types, but could change
them for member pointers.

My second guess: for object (data) members there needs to be a way to
disambiguate pointer-to-member, pointer-to-object, and object.  If m is a
non-static data member of base then &base::m, &(base::m) and base::m mean
three different things.  The standard is slightly simpler if the same rules
apply to both function members and data members.



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This is a multi-part message in MIME format.
--------------D958C02480015BFE950CEE8E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bill Wade wrote:

> My second guess: for object (data) members there needs to be a way to
> disambiguate pointer-to-member, pointer-to-object, and object.  If m is a
> non-static data member of base then &base::m, &(base::m) and base::m mean
> three different things.  The standard is slightly simpler if the same rules
> apply to both function members and data members.

I will grant you that I understand that the capability in base C and C++ to
implicitly convert the name of a function into a pointer to the function was
always recognized as a shortcut.  However it is a shortcut which the STL itself
has taken advantage of, for example in the implementation of parameter-less IO
manipulators.

My point remains that my code would look cleaner and be easier to understand if
this restriction was not present.  I am, in effect, being penalized for writing
object-oriented code.

--
Jim Cobban   jcobban@magma.ca
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438


--------------D958C02480015BFE950CEE8E
Content-Type: text/x-vcard; charset=us-ascii;
 name="thesnaguy.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jim Cobban
Content-Disposition: attachment;
 filename="thesnaguy.vcf"

begin:vcard
n:Cobban;James
tel;fax:+1-613-592-9438
tel;home:+1-613-592-9438
x-mozilla-html:FALSE
url:http://www.magma.ca/~jcobban
version:2.1
email;internet:thesnaguy@hotmail.com
title:Consultant
adr;quoted-printable:;;34 Palomino Dr.=0D=0A;Kanata;ON;K2M 1M1;Canada
fn:Jim Cobban
end:vcard

--------------D958C02480015BFE950CEE8E--

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Wade wrote:
>
> Jim Cobban wrote in message <388CC286.B7848872@hotmail.com>...
> >Could someone please explain to me the rationale behind the restriction
> >documented in paragraph 3 of section 5.3.1 of the standard:
> >
> >"A pointer to member is only formed when an explicit & is used and ...
>
> My first guess: the guy who got this into the standard had once written
>
>    while(foo){...}
>
> when he had intended
>
>   while(foo()){...}
>
> he couldn't change the rule for existing pointer types, but could change
> them for member pointers.
>
> My second guess: for object (data) members there needs to be a way to
> disambiguate pointer-to-member, pointer-to-object, and object.  If m is a
> non-static data member of base then &base::m, &(base::m) and base::m mean
> three different things.  The standard is slightly simpler if the same rules
> apply to both function members and data members.

I think the problem is the use of the same operator& to provide
both object pointers and member pointers. If there had been
another operator, say operator&& (which currently would be
interpreted as taking the address of an address, which is
ill-formed), then there would be no problem in allowing
&&(base::m) or even &&m to generate a pointer to member, while
&(base::m) or &m would return a pointer to the object.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This is a multi-part message in MIME format.
--------------2A153B3BFFFFB9C79A044A80
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Could someone please explain to me the rationale behind the restriction
documented in paragraph 3 of section 5.3.1 of the standard:

"A pointer to member is only formed when an explicit & is used and its
operand is a qualified-id not enclosed in parentheses. [Note: that is,
the expression &(qualified-id), where the qualified-id is enclosed in
parentheses, does not form an expression of type <pointer to member>
Neither does qualified-id, because there is no implicit conversion from
a qualified-id for a nonstatic member function to the type <pointer to
member function> as there is from an lvalue of function type to the type

<pointer to function> (4.3). Nor is &unqualified-id a pointer to member,

even within the scope of the unqualified-id's class. ]"

The result of this restriction is what seems unnecessarily ugly code in
my program.

I am writing a state based parser. So at the end of processing each
token I want to set the state for handling the next token.  At first I
did this with an enumeration, but that then required a switch statement
to select the function to be called for each state, so I decided to use
a pointer-to-member-function.  But that requires the ugly syntax:

 pmf = &ClassName::StateFunc;

where, as the standard says this qualification would not be required if
I were not writing this code using classes.  I therefore feel that the
standard is, in this situation, penalizing me for wanting to program
using
object oriented techniques.

Note that the enforcement of this restriction varies by compiler.  I
have tried it on Borland, which issues an error message, and on
Metrowerks, which accepts the short-hand pmf = StateFunc;

--
Jim Cobban   jcobban@magma.ca
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438


--------------2A153B3BFFFFB9C79A044A80
Content-Type: text/x-vcard; charset=us-ascii;
 name="thesnaguy.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jim Cobban
Content-Disposition: attachment;
 filename="thesnaguy.vcf"

begin:vcard
n:Cobban;James
tel;fax:+1-613-592-9438
tel;home:+1-613-592-9438
x-mozilla-html:FALSE
url:http://www.magma.ca/~jcobban
version:2.1
email;internet:thesnaguy@hotmail.com
title:Consultant
adr;quoted-printable:;;34 Palomino Dr.=0D=0A;Kanata;ON;K2M 1M1;Canada
fn:Jim Cobban
end:vcard

--------------2A153B3BFFFFB9C79A044A80--



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]