"George Heintzelman" <georgeh@no_spam_please.aya.yale.edu> wrote in message
news:3D9D90EE.8050606@no_spam_please.aya.yale.edu...
> Carl Daniel wrote:
> >
> > You missed something - see Ron Natalie's post.
>
> No, I don't think I did. He was talking about T Derived::* into T
> Base::*, which I know about as I said above. I was talking about Derived
> X::* into Base X::*, something which ought to be simple (I think ?!). Of
> course D1 B2::* ought to be convertible into B1 D2::* in the general case.

Sorry, I didn't read carefully enough.

>
> Hmm, right, this would be trickier than I thought at first. And it would
> make all pointers-to-function pay for machinery that most cases wouldn't
> use. So you may as well make the user build the functors which do the
> appropriate work if they need this kind of conversion. Time for a
> library solution!

I think it could be done with zero impact on programs that don't use the
feature, since all the work would be done at the point of conversion rather
than at the point of dereference (just as compilers now have to add a
constant offset on Derived -> Base conversions in the general case).  Still,
I wouldn't lobby for such a feature to be added:  it's a very unusual
circumstance with a complex solution, and as you point out, probably can be
solved well enough as a library.

-cd


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

""Carl Daniel"" <cpdaniel@pacbell.net> wrote in message news:R2mn9.758$eO2.77888657@newssvr14.news.prodigy.com...

>
> No guessing required - all information is present at the point of conversion
> (the complete type AND the runtime value of the source and the complete type
> of the destination)

You've lost me.   How does a B1 D2::* know when it contains a member that
requries a D1 to B1 conversion?  At the point of conversion it needs to know
to apply the conversion or not (even D1 to B1 would be an implicit conversion
otherwise).



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

"Andrey Tarasevich" <andreytarasevich@hotmail.com> wrote in message news:3D9DE7C6.2010800@hotmail.com...

> > ...
> > It's got nothing to do with thunking at all, it's the fact that it's not a safe conversion
> > because there might not be that member there.
> > ...
>
> "Not safe" doesn't mean "not allowed". Downcasts like 'Base*' -> 'Derived*'
> are not safe in exactly the same way. However, downcasts are allowed and can
> be performed by explicit conversions.

Correct, I thought we were talking about impllicit conversions NOT casts.



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

George Heintzelman wrote:
>>
>> Feasible, yes, but tricky, since the this-pointer-adjuster would be unique
>> to the particular conversion made and the value of the pointer,  it would
>> have to be generated on the fly, allocated in some dynamic storage, that
>> somehow gets cleaned up when the pointer is re-assigned or goes out of
>> scope.
>
> Hmm, right, this would be trickier than I thought at first. And it would
> make all pointers-to-function pay for machinery that most cases wouldn't
> use.

The current C++ standard already requires all pointers to class methods to
pay for machinery that most cases wouldn't use.

Every time you declare a pointer to a method of class A in your program, the
compiler must keep in mind the fact that it is quite possible that this
pointer will actually point to a method of another class, derived from A.
Once we get into multiple and virtual inheritance it becomes obvious that
the pointer might need to be adjusted _at_ _the_ _point_ _of_ _dereference_.
(In general case this adjustment cannot be done at the point of
initialization.) For this reason, pointers to class methods must always
carry around some additional information (in addition to method's entry point).

So the real question is whether this "machinery" that is _already_ in
language and its implementations, can be made to work in your case without
significant changes.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

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

Ron Natalie wrote:
> You've lost me.   How does a B1 D2::* know when it contains a member that
> requries a D1 to B1 conversion?  At the point of conversion it needs to know
> to apply the conversion or not (even D1 to B1 would be an implicit conversion
> otherwise).

Remember that pointer-to-member is already a complicated
little object. It would just need to become a little more
complicated. A pointer to member is first created in exactly
one way, through the expression &Type::Member. Therefore we
know it's original type. Every time it is cast to some other
type, we can add information on what kind of conversion has
happened. Finally, we apply it to some object, and we know
the exact type of that object, looking at its vtable if we
need to, just like dynamic cast does. At that point we can
do whatever adjustments we need.

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

Ron Natalie wrote:
> "George Heintzelman" <georgeh@no_spam_please.aya.yale.edu> wrote in message news:3D9D90EE.8050606@no_spam_please.aya.yale.edu...
>
>> No, I don't think I did. He was talking about T Derived::* into T
>> Base::*, which I know about as I said above. I was talking about Derived
>> X::* into Base X::*, something which ought to be simple (I think ?!). Of
>> course D1 B2::* ought to be convertible into B1 D2::* in the general case.
>
> Ahh, now you want the compiler to guess when it is necessary to generate
> a conversion after the dereference of the pointer?   Where is the information
> necessary to do that obtained from?
> ...

>From the pointer itself, of course. Consider the following

struct A { int i; };
struct B { int j; };
struct C : A, B { void foo() {} };

int main()
{
  void (A::*pfa)() = static_cast<void (A::*)()>(&C::foo);
  void (B::*pfb)() = static_cast<void (B::*)()>(&C::foo);

  C c;
  A* pa = &c;
  B* pb = &c;

  (pa->*pfa)();
  (pb->*pfb)();
}

The above code is perfectly legal C++. However, it is obvious that in order
to make the calls correctly, the compiler will need some additional
information, besides the method's entry point. The additional information is
necessary in order to calculate the correct value of 'this' pointer before
the 'C::foo' method is invoked. Where do you think the compiler gets this
information? This information is stored in the pointer itself. That's why,
for example, class method pointers in GCC on Win32 consist of 8 bytes
instead of 4 - in addition to the method's entry point they store some
offset information, used for 'this' adjustment.

Maybe something like this is possible in George's case too.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

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

Carl Daniel wrote:
>> ...
>> > No, I don't think I did. He was talking about T Derived::* into T
>> > Base::*, which I know about as I said above. I was talking about Derived
>> > X::* into Base X::*, something which ought to be simple (I think ?!). Of
>> > course D1 B2::* ought to be convertible into B1 D2::* in the general
> case.
>>
>> Ahh, now you want the compiler to guess when it is necessary to generate
>> a conversion after the dereference of the pointer?   Where is the
> information
>> necessary to do that obtained from?
>
> No guessing required - all information is present at the point of conversion
> (the complete type AND the runtime value of the source and the complete type
> of the destination) - delaying the adjustment until the point of dereference
> doesn't seem even remotely workable though.  It would require some rather
> elaborate runtime mechanisms to make it work.
> ...

Do you have any reason to believe that in this case the delayed adjustment
will be _more_ _complicated_ than the delayed adjustment used when class
method is called through a pointer in multiple/virtual inheritance situations?

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

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

"Andrey Tarasevich" <andreytarasevich@hotmail.com> wrote in message
news:3D9DF638.1040903@hotmail.com...
> Carl Daniel wrote:
> >
> > No guessing required - all information is present at the point of
conversion
> > (the complete type AND the runtime value of the source and the complete
type
> > of the destination) - delaying the adjustment until the point of
dereference
> > doesn't seem even remotely workable though.  It would require some
rather
> > elaborate runtime mechanisms to make it work.
> > ...
>
> Do you have any reason to believe that in this case the delayed adjustment
> will be _more_ _complicated_ than the delayed adjustment used when class
> method is called through a pointer in multiple/virtual inheritance
situations?

If the adjustment were performed at the point of dereference, then no, I
don't think it would significantly complicate the already complicated
gymanstics required for pointer to member function.  However, getting back
to Goerge's original question, that of convertibility of Derived* (*)(args)
to Base* (*)(args), deferring the adjustment to the point of dereference
would have a negative impact on every use of function pointers - they'd have
to be ugly beasties like pointers-to-member-function already are.  So I
would assume that if someone actually implemented this sort of conversion,
that it would be desirable to do all of the adjustment at the point of
conversion, regardless of whether it's a pointer-to-member-function or an
ordinary pointer-to-function.  Doing it at the point of conversion, though,
requires management of a family of "dynamic thunks" which perform the 'this'
adjust "on the fly" and then forward to the actual pointee (or something
equivalent).

-cd

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

So I noticed that the C++ standard does not allow the conversion
(implicitly or explicitly) of:

Derived X::*
into
Base X::*

I know all the reasons why Derived** is not convertible to Base** and
why T Derived::* is not convertible to T Base::* while the converse is
allowed. Still, I couldn't see a reason why this conversion is not allowed.

So, what's the consensus? Is this a defect or oversight in the standard,
or am I missing something? I note that even reinterpret_cast is not a
good solution in general, because of MI offsets (which a compiler can
know how to adjust of course).

While I'm at it, shouldn't

Derived * (*)(args) be convertible into
Base * (*)(args) ? (Similarly for pointer-to-member functions, of course).

I know this is harder, because a compiler would have to generate a
little thunk to adjust MI pointers where this is relevant, but that
should be feasible, no?

George Heintzelman
georgeh@no_spam_please.aya.yale.edu

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

"George Heintzelman" <georgeh@no_spam_please.aya.yale.edu> wrote in message news:3D9CC452.5000300@no_spam_please.aya.yale.edu...
> So I noticed that the C++ standard does not allow the conversion
> (implicitly or explicitly) of:
>
> Derived X::*
> into
> Base X::*
>

Because not all members of Derived are part of Base.
It will allow you to go the other way (convert Base ::* to Derived::*)
because all members of Base are members of Derived.

Take an example:

    class Base {
    };

    class Derived : public Base {
    public:
        int member;
    };

    int Base::*pmBase = &Derived::member; ; // presume this was legal.

    Base x;
    x.*pmBase = 5;         // what does this change?

It's got nothing to do with thunking at all, it's the fact that it's not a safe conversion
because there might not be that member there.



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

"George Heintzelman" <georgeh@no_spam_please.aya.yale.edu> wrote in message
news:3D9CC452.5000300@no_spam_please.aya.yale.edu...
> So I noticed that the C++ standard does not allow the conversion
> (implicitly or explicitly) of:
>
> Derived X::*
> into
> Base X::*
>
> I know all the reasons why Derived** is not convertible to Base** and
> why T Derived::* is not convertible to T Base::* while the converse is
> allowed. Still, I couldn't see a reason why this conversion is not
allowed.
>
> So, what's the consensus? Is this a defect or oversight in the standard,
> or am I missing something? I note that even reinterpret_cast is not a
> good solution in general, because of MI offsets (which a compiler can
> know how to adjust of course).

You missed something - see Ron Natalie's post.

>
> While I'm at it, shouldn't
>
> Derived * (*)(args) be convertible into
> Base * (*)(args) ? (Similarly for pointer-to-member functions, of course).
>
> I know this is harder, because a compiler would have to generate a
> little thunk to adjust MI pointers where this is relevant, but that
> should be feasible, no?

Feasible, yes, but tricky, since the this-pointer-adjuster would be unique
to the particular conversion made and the value of the pointer, it would
have to be generated on the fly, allocated in some dynamic storage, that
somehow gets cleaned up when the pointer is re-assigned or goes out of
scope.

For the pointer-to-member function case, I assume you mean that

Derived* (X::*)(args) should be convertible to
Base* (X::*)(args)

Where X is some class (could be Base, could be Derived, could be some other
class).  This would require a similar solution to the above.  (Rationale:
every Derived IsA Base, so the result of calling the function is convertible
to Base* already).

An even stranger variety of conversion should be possible and safe:

D1* (B2::*)(args) could be converted to
B1* (D2::*)(args)

where D1 derives from B1 and D2 from B2.

Again, a similar solution.  (Rationale:  Every member of B2 is also a member
of D2, and every D1 IsA B1, so whatever is pointed-to in B2 exists in D2,
and the result of calling the function is convertible to B1 already).

Is any of this worth it?  Not likely, IMO.

-cd


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

Carl Daniel wrote:
> "George Heintzelman" <georgeh@no_spam_please.aya.yale.edu> wrote in message
> news:3D9CC452.5000300@no_spam_please.aya.yale.edu...
>
>>So I noticed that the C++ standard does not allow the conversion
>>(implicitly or explicitly) of:
>>
>>Derived X::*
>>into
>>Base X::*
>>
>>I know all the reasons why Derived** is not convertible to Base** and
>>why T Derived::* is not convertible to T Base::* while the converse is
>>allowed. Still, I couldn't see a reason why this conversion is not
>
> You missed something - see Ron Natalie's post.

No, I don't think I did. He was talking about T Derived::* into T
Base::*, which I know about as I said above. I was talking about Derived
X::* into Base X::*, something which ought to be simple (I think ?!). Of
course D1 B2::* ought to be convertible into B1 D2::* in the general case.

>> While I'm at it, shouldn't
>>
>>Derived * (*)(args) be convertible into
>>Base * (*)(args) ? (Similarly for pointer-to-member functions, of course).
>>
>>I know this is harder, because a compiler would have to generate a
>>little thunk to adjust MI pointers where this is relevant, but that
>>should be feasible, no?
>
> Feasible, yes, but tricky, since the this-pointer-adjuster would be unique
> to the particular conversion made and the value of the pointer,  it would
> have to be generated on the fly, allocated in some dynamic storage, that
> somehow gets cleaned up when the pointer is re-assigned or goes out of
> scope.

Hmm, right, this would be trickier than I thought at first. And it would
make all pointers-to-function pay for machinery that most cases wouldn't
use. So you may as well make the user build the functors which do the
appropriate work if they need this kind of conversion. Time for a
library solution!

George Heintzelman
georgeh@no_spam_please.aya.yale.edu

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

Ron Natalie wrote:
> "George Heintzelman" <georgeh@no_spam_please.aya.yale.edu> wrote in message news:3D9CC452.5000300@no_spam_please.aya.yale.edu...
>
>>So I noticed that the C++ standard does not allow the conversion
>>(implicitly or explicitly) of:
>>
>>Derived X::*
>>into
>>Base X::*
>
> Because not all members of Derived are part of Base.
> It will allow you to go the other way (convert Base ::* to Derived::*)
> because all members of Base are members of Derived.

No, I know that. You're talking about converting T Derived::* into T
Base::*, which isn't allowed though the converse is. I'm talking about
converting Derived X::* into Base X::*. Pointers to members of the same
class, with different pointed-to types related by inheritance. That's
why I pointed out that I know the other conversion isn't okay, because I
know it's a FAQ. ;)

Thanks for trying, though.

George Heintzelman
georgeh@no_spam_please.aya.yale.edu


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

"George Heintzelman" <georgeh@no_spam_please.aya.yale.edu> wrote in message news:3D9D90EE.8050606@no_spam_please.aya.yale.edu...

> No, I don't think I did. He was talking about T Derived::* into T
> Base::*, which I know about as I said above. I was talking about Derived
> X::* into Base X::*, something which ought to be simple (I think ?!). Of
> course D1 B2::* ought to be convertible into B1 D2::* in the general case.

Ahh, now you want the compiler to guess when it is necessary to generate
a conversion after the dereference of the pointer?   Where is the information
necessary to do that obtained from?



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

George Heintzelman wrote:
> So I noticed that the C++ standard does not allow the conversion
> (implicitly or explicitly) of:
>
> Derived X::*
> into
> Base X::*

Where did you get this information? The C++ standard _does_ allow this
conversion. This conversion is performed explicitly by 'static_cast'. See
the description of 'static_cast' in the C++ standard (particularly 5.2.9/9).

In the first draft (see ftp://ftp.research.att.com/dist/c++std/WP/CD1) of
the standard this conversion wasn't allowed. In the second draft (see
ftp://ftp.research.att.com/dist/c++std/WP/CD2) the corresponding part of the
standard (5.2.9/9) was changed to allow the conversion in question.

> I know all the reasons why Derived** is not convertible to Base** and
> why T Derived::* is not convertible to T Base::* while the converse is
> allowed. Still, I couldn't see a reason why this conversion is not allowed.

It is allowed.

> So, what's the consensus? Is this a defect or oversight in the standard,
> or am I missing something? I note that even reinterpret_cast is not a
> good solution in general, because of MI offsets (which a compiler can
> know how to adjust of course).
>
> While I'm at it, shouldn't
>
> Derived * (*)(args) be convertible into
> Base * (*)(args) ? (Similarly for pointer-to-member functions, of course).
>
> I know this is harder, because a compiler would have to generate a
> little thunk to adjust MI pointers where this is relevant, but that
> should be feasible, no?

Yes, it is feasible and compliant compilers implement all necessary
functionality.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

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

Andrey Tarasevich wrote:
> ...
>> So I noticed that the C++ standard does not allow the conversion
>> (implicitly or explicitly) of:
>>
>> Derived X::*
>> into
>> Base X::*
>
> Where did you get this information? The C++ standard _does_ allow this
> conversion. This conversion is performed explicitly by 'static_cast'. See
> the description of 'static_cast' in the C++ standard (particularly 5.2.9/9).
>
> In the first draft (see ftp://ftp.research.att.com/dist/c++std/WP/CD1) of
> the standard this conversion wasn't allowed. In the second draft (see
> ftp://ftp.research.att.com/dist/c++std/WP/CD2) the corresponding part of the
> standard (5.2.9/9) was changed to allow the conversion in question.

Oh... I saw Ron's post first and read your post under impression that you
are talking about converting 'T Derived::*' to 'T Base::*'. Now I see that
you question is about quite different conversion.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

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

Ron Natalie wrote:
> ...
> Because not all members of Derived are part of Base.
> It will allow you to go the other way (convert Base ::* to Derived::*)
> because all members of Base are members of Derived.
> ...
> It's got nothing to do with thunking at all, it's the fact that it's not a safe conversion
> because there might not be that member there.
> ...

"Not safe" doesn't mean "not allowed". Downcasts like 'Base*' -> 'Derived*'
are not safe in exactly the same way. However, downcasts are allowed and can
be performed by explicit conversions. The same applies to 'Derived::*' ->
'Base ::*' conversion. It is allowed by C++ standard as one of the
conversions performed by 'static_cast'.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

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

""Ron Natalie"" <ron@sensor.com> wrote in message
news:oSkn9.9948$Jw5.2811@fe04...
>
> "George Heintzelman" <georgeh@no_spam_please.aya.yale.edu> wrote in
message news:3D9D90EE.8050606@no_spam_please.aya.yale.edu...
>
> > No, I don't think I did. He was talking about T Derived::* into T
> > Base::*, which I know about as I said above. I was talking about Derived
> > X::* into Base X::*, something which ought to be simple (I think ?!). Of
> > course D1 B2::* ought to be convertible into B1 D2::* in the general
case.
>
> Ahh, now you want the compiler to guess when it is necessary to generate
> a conversion after the dereference of the pointer?   Where is the
information
> necessary to do that obtained from?

No guessing required - all information is present at the point of conversion
(the complete type AND the runtime value of the source and the complete type
of the destination) - delaying the adjustment until the point of dereference
doesn't seem even remotely workable though.  It would require some rather
elaborate runtime mechanisms to make it work.

-cd


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