In article <8pig9t$1co$1@nnrp1.deja.com>,  <wmm@fastdial.net> wrote:
>In article <EjTu5.506$8Z2.17400@news101.telia.com>,
>  liborius@stofanet.dk (Per Liboriussen) wrote:
>> Given the following definitions:
>>
>>   class Base {
>>   public:
>>     int func() const;
>>   };
>>
>>   class Derived : public Base {
>>   };
>>
>> the Standard says that the type of the expression "&Derived::func" is
>> "int (Base::*)() const" rather than "int (Derived::*)() const"
>(5.3.1).

[Example involving templates which fails to compile snipped]

>The note at the end of the issue description summarizes the
>discussion at the April, 2000 meeting.  What it says is that
>the current specification was chosen to allow the widest
>possible application of address-of-member expressions.  That
>is, using your example, both of the following are well-formed:
>
>    int (Base::* bp)() const = &Derived::func;
>    int (Derived::* dp)() const = &Derived::func;
>
>With the the choice you and Ms Lippincott are advocating,
>only the second would be well-formed.

Well, yes, that's true. However, I cannot think of any advantage
at all of using the expression "&Derived::func" to initialize
a variable of type "int (Base::* bp)() const".
It seems to me to be merely obfuscation, with the added liability
that it will break if somebody later adds func() to Derived.
If the programmer needs the widest possible application of the pointer,
he or she can just write &Base::func instead.

Am I overlooking something?

>We left the issue open for future discussion.  However, my
>personal speculation is that the Committee is unlikely to
>adopt a change that would break the "bp" initialization, so
>unless a different solution can be found that addresses your
>concern, the situation will probably stay as it is.

Would it be possible to make the type pointer-to-derived-member,
and add an implicit conversion to pointer-to-base-member if the name
in question ("func", in this case) is defined in the base class
(and not redefined in the derived class, obviously)?

>I will add your example to the description of the issue.

Thanks.


Per Liboriussen

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

In article <EjTu5.506$8Z2.17400@news101.telia.com>,
  liborius@stofanet.dk (Per Liboriussen) wrote:
> Given the following definitions:
>
>   class Base {
>   public:
>     int func() const;
>   };
>
>   class Derived : public Base {
>   };
>
> the Standard says that the type of the expression "&Derived::func" is
> "int (Base::*)() const" rather than "int (Derived::*)() const"
(5.3.1).
>
> This is an open issue according to the C++ Standard Core Language
Active
> Issues list at
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html (issue
203).
>
> Does anybody know what the Committee's view is on this issue?

In addition to my previous reply, I thought I should point
out that this specification was already present in the ARM
and thus predates the Committee.  On page 55 (in my
first-edition, first-printing copy):

    Note that the type of a member includes the class in which
    it was defined (and _not_ any class derived (sec. 10) from
    that class).  For example:

        struct B { void f(); int i; };
        struct D : B { };

    Here, the types of &B::f and &D::f are the same:
    void (B::*)().

That doesn't mean that the decision was good or bad, just that
it was made a long time ago and has probably figured in a lot
of code over that period.  That's one of the things the
Committee has to consider in cases like this.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

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

Given the following definitions:

  class Base {
  public:
    int func() const;
  };

  class Derived : public Base {
  };

the Standard says that the type of the expression "&Derived::func" is
"int (Base::*)() const" rather than "int (Derived::*)() const" (5.3.1).

This is an open issue according to the C++ Standard Core Language Active
Issues list at
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html (issue 203).

I would like to support Lisa Lippincott, who submitted the issue.
My problem is the following code, which (with the above class definitions)
fails to compile:

  template<class T>
  class Templ {
  public:
    template<class S>
    Templ(S (T::*ptmf)() const);
  };

  void foo()
  {
    Templ<Derived> x(&Derived::func);
  }

The implicit conversion from pointer-to-base-member to
pointer-to-derived-member doesn't help me here. When the compiler
determines the set of viable functions for the constructor, it will try
to deduce the types for the member template, and fail. This happens before
implicit conversions are considered, which leaves only the copy-constructor
as a viable function.

Does anybody know what the Committee's view is on this issue?


Per Liboriussen

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

In article <EjTu5.506$8Z2.17400@news101.telia.com>,
  liborius@stofanet.dk (Per Liboriussen) wrote:
> Given the following definitions:
>
>   class Base {
>   public:
>     int func() const;
>   };
>
>   class Derived : public Base {
>   };
>
> the Standard says that the type of the expression "&Derived::func" is
> "int (Base::*)() const" rather than "int (Derived::*)() const"
(5.3.1).
>
> This is an open issue according to the C++ Standard Core Language
Active
> Issues list at
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html (issue
203).
>
> I would like to support Lisa Lippincott, who submitted the issue.
> My problem is the following code, which (with the above class
definitions)
> fails to compile:
>
>   template<class T>
>   class Templ {
>   public:
>     template<class S>
>     Templ(S (T::*ptmf)() const);
>   };
>
>   void foo()
>   {
>     Templ<Derived> x(&Derived::func);
>   }
>
> The implicit conversion from pointer-to-base-member to
> pointer-to-derived-member doesn't help me here. When the compiler
> determines the set of viable functions for the constructor, it will
try
> to deduce the types for the member template, and fail. This happens
before
> implicit conversions are considered, which leaves only the copy-
constructor
> as a viable function.
>
> Does anybody know what the Committee's view is on this issue?

The note at the end of the issue description summarizes the
discussion at the April, 2000 meeting.  What it says is that
the current specification was chosen to allow the widest
possible application of address-of-member expressions.  That
is, using your example, both of the following are well-formed:

    int (Base::* bp)() const = &Derived::func;
    int (Derived::* dp)() const = &Derived::func;

With the the choice you and Ms Lippincott are advocating,
only the second would be well-formed.

We left the issue open for future discussion.  However, my
personal speculation is that the Committee is unlikely to
adopt a change that would break the "bp" initialization, so
unless a different solution can be found that addresses your
concern, the situation will probably stay as it is.

I will add your example to the description of the issue.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

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