> > swu00@earthlink.net (Shao Wu) wrote in message news:<3D7B9133.DD2F8B39@earthlink.net>...
> > Marian Pavlikovic wrote:
> >
> > > Every now and then I wonder why isn't construct like this
> > > possible in C++:
> > >
> > >     class A;
> > >     extern void f1( A* pThis );
> > >     extern char f2( const A* pThis , int i );
> > >
> > >     class A
> > >     {
> > >     public:
> > >         // ...
> > >
> > >         virtual void m1() = f1;
> > >         virtual char m2( int ) const = f2;
> > >     };
> > >
> >
> > Interesting. That makes f1(), f2() effectively as
> > out-of-class  default implementation of A::m1(), A::m2()
> > except they can be called as stand alone functions, and
> > can access only to the public members of A regardless if
> > A is further subclass or not.

Yes, right: only public access by default. That, however,
shouln't preclude anybody from declaring the function 'f1()'
to be a friend of the class A if needed ...

> > In effect,
> >     f1(A* pthis)
> >     {
> >            pthis->m1();    // Possible recursive
> >     }
> >
> > The line pthis->m1() depending on the actual object f1()
> > is bound to, and if that subclass provides m1()
> > implementation or default to A::m1().

Technically yes, that would be possible and I believe it
should be.

However, I don't believe it would be likely to happen by
accident: usually it makes sense to use this construct only
when 'f1(...)' provides some computation that uses class
'A', but doesn't really belong into 'A' (often times because
it is quite generic, not specific to 'A', only to interface
that 'A' can support). This usually happens when 'f1(...)'
is an algorithm that operates on 'A', but was not or should
not be burried into a implementation of 'A's methods. Such
algorithm usually uses just get/set operations on 'A'. On
the other hand, implementing get/set in 'A' using this
technique would not be very useful (though possible). This
means that the 'f1(...)' would naturaly implement a set of
functionality that disjoint from the set of functionality it
actually uses => as such, there would be probably little
room for recursion.

> > One greate reason for programmers to eat healthy,
> > exercise more, and check out our heart conditions often!
> > And a nice life insurance coverage just in case
> > something happens.  ;-)

Okay, okay, I promise: starting next week I'm going to cut
it down to 80h/w ... :-)

marian

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

Victor Bazarov wrote:
> >     class C : public A
>
> Did you mean to write
>
>     class C : public B
>
> ???

Whoops, my mistake! You're right. Sorry about that -- too much of
copy-and-paste, too little proofreading ... :-|

Thanks!

marian

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

> > > Marian Pavlikovic wrote:
> > > >
> > > > Every now and then I wonder why isn't construct like this
> > > > possible in C++:
> > > >
> > > >     class A;
> > > >     extern void f1( A* pThis );
> > > >     extern char f2( const A* pThis , int i );
> > > >
> > > >     class A
> > > >     {
> > > >     public:
> > > >         // ...
> > > >
> > > >         virtual void m1() = f1;
> > > >         virtual char m2( int ) const = f2;
> > > >     };
> > > >
> > > > In other words, it would be nice to extend the current
> > > > syntax used to identify a pure virtual function with '= 0'
> > > > to allow initialization of a vftable pointer with an
> > > > existing pointer to a function. Naturally, this should be
> > > > allowed only if the global function signature was equivalent
> > > > to the signature of the method. Such as method would not be
> > > > allowed to have any other definition.


> > petebecker@acm.org (Pete Becker) wrote:
> > > Compilers are not currently required to pass the 'this' pointer to a
> > > member function as if it were the first named argument to a global
> > > function. Some compilers hold the 'this' pointer in a register so that
> > > it doesn't have to be passed around during member function calls from
> > > other member functions. The proposed extension would preclude this
> > > optimization (or, alternatively, impose an inefficient calling
> > > convention on all global functions that take a pointer to a class type
> > > as their first argument).
>
> Hmm, I admit I didn't think about this.
>
> But if I understand you correctly, what we are talking about
> here is a mismatch of calling conventions. As such, and
> please correct me if I'm wrong, it could be solved by the
> compiler itself -- if case it uses internally a specialized
> calling convention, it would be required, upon seeing the
> syntax 'method() = function;' to implicitly generate a new
> method/function that would translate its optimized calling
> convention into standard function calling convention. The
> 'vftable' would then be inserted with the address of this
> new function/method instead of the user-defined one.

Why not simply tell the compiler how to do it at compile time?

     class A;
     extern void f1( A* pThis );
     extern char f2( const A* pThis , int i );

     class A
     {
     public:
         // ...
         virtual void m1()            { f1(this); }
         virtual char m2(int i) const { return f2(this, i); }
     };

When the compiler "knows" that an object is actually an A (and not
something derived from A), it will be able to inline the calls to
f1() and f2() -- essentially giving you exactly what you asked
for. When the virtual calling mechanism is in place, the function
will call a "method/function that would translate its" (virtual
calling method) "into standard function calling convention."

This version has two additional advantages:

   1. It would be possible to make parameter changes or additional
      actions before or after the call. For instance,

         virtual char m2(int i) const { std::cout << "m2(" << i << "(\n";
                                        return f2(this, i-1) + 4; }

   2. It requires no language changes at all.

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

mpavlikovic@poboxes.com ("Marian Pavlikovic") wrote in message news:<MPEe9.17673$jG2.1276059@bgtnsc05-news.ops.worldnet.att.net>...
> Every now and then I wonder why isn't construct like this
> possible in C++:
>
>     class A;
>     extern void f1( A* pThis );
>     extern char f2( const A* pThis , int i );
>
>     class A
>     {
>     public:
>         // ...
>
>         virtual void m1() = f1;
>         virtual char m2( int ) const = f2;
>     };
>

you can already do this:

struct A {
 virtual inline void m1() { f1(this); }
 virtual inline char m2(int i) const { return f2(i); }
};

My solution is identical to yours:

1- in both, the class definition is polluted with the name of the
function to call.
2- in both, the function to be called must be visible to the class
definition.

My solution has some benefits:

1- if you have an object of static type which is known to be A, it may
be able to inline the call to f1 or f2.
2- all forms of parameter conversions are supported, without any new
convoluted rules.

So, what does the =f1 form get you that the inlined method does not?
Does the inline method present any problems that the =f1 method would
solve?

joshua lehrer
factset research systems

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

Victor Bazarov wrote:
>
> I don't understand how that would be true.  Why would such
> imposition have to be made?  If a regular call to 'f1' can
> be done with its argument in a register (I don't know of any
> specific requirement in the Standard), why wouldn't the compiler
> be able to preserve the 'this' in a register for 'f1'?

It could. The problem is that the compiler would have to use the same
calling convention for global functions (that take a pointer to a class
as their first argument) and for member functions. This is a constraint
on code generation that isn't currently present, and isn't desirable.
What's good for objects isn't necessarily good for globals, and vice
versa.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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

>>""Marian Pavlikovic"" <mpavlikovic@poboxes.com> wrote...
>> Every now and then I wonder why isn't construct like this
>> possible in C++:
>>
>>     class A;
>>     extern void f1( A* pThis );
>>     extern char f2( const A* pThis , int i );
>>
>>     class A
>>     {
>>     public:
>>         // ...
>>
>>         virtual void m1() = f1;
>>         virtual char m2( int ) const = f2;
>>     };
>>
>> In other words, it would be nice to extend the current
>> syntax used to identify a pure virtual function with '=
>> 0' to allow initialization of a vftable pointer with an
>> existing pointer to a function. Naturally, this should be
>> allowed only if the global function signature was
>> equivalent to the signature of the method. Such as method
>> would not be allowed to have any other definition.
>>
><innocentsarcasm>
>What, no integral/arithmetic promotions, no conversions? :-(
>We've just started having fun with those...
></innocentsarcasm>

:-)

>Additions, actually...
>
>This should probably be allowed:
>
>    class A
>    {
>    public:
>        // ...
>
>        virtual void m01();
>        virtual void m02(int) const;
>
>        virtual void m1() = m01;
>        virtual char m2(int) const = m02;
>    };

Yes, sure, although after talking to some people, I have to
admit that we might have really hard time to find a useful
application for that.

Nevertheless, I personally believe that this should be
allowed along with any other function address assignment
that you can think of. However, some OO enthusiasts might
find things like the following one rather disturbing :-)

    class A
    {
    public:
        // ...
        virtual void m();
    };

    void A::m() { /* ... */ }

    class B : public A
    {
    public:
        // ...
        virtual void m();
    };

    void B::m() { /* ... */ }

    class C : public A
    {
    public:
        // ...
        virtual void m() = &A::m;   // skip the overload in 'B'
    };

>And this:
>
>    class B
>    {
>    public:
>        void m01(); // non-virtual
>    };
>
>    class A : B  // non-public inheritance
>    {
>    public:
>        virtual void m1() = &B::m01; // is it accessible?
>    };

Hmm, interesting. I would say that no, it should not.

Why? Well, this proposal sees the syntax

    virtual method() = 0;

almost literarly as an assignment into the 'vftable'.
Therefore the analogy:

    virtual method() = function;

Basically tries to assign the function pointer into the
'vftable' slot fo the function.

As such, this "assignment" is resolved at the compile time,
it should then respect the access control which is all
available at the compile time ... But that's just my view --
I'm open to other reasonable interpretations.

Thanks!

marian

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

> > petebecker@acm.org (Pete Becker) wrote in message news:<3D7B6783.5E39EE7D@acm.org>...
> > Marian Pavlikovic wrote:
> > >
> > > Every now and then I wonder why isn't construct like this
> > > possible in C++:
> > >
> > >     class A;
> > >     extern void f1( A* pThis );
> > >     extern char f2( const A* pThis , int i );
> > >
> > >     class A
> > >     {
> > >     public:
> > >         // ...
> > >
> > >         virtual void m1() = f1;
> > >         virtual char m2( int ) const = f2;
> > >     };
> > >
> > > In other words, it would be nice to extend the current
> > > syntax used to identify a pure virtual function with '= 0'
> > > to allow initialization of a vftable pointer with an
> > > existing pointer to a function. Naturally, this should be
> > > allowed only if the global function signature was equivalent
> > > to the signature of the method. Such as method would not be
> > > allowed to have any other definition.
> >
> > Compilers are not currently required to pass the 'this' pointer to a
> > member function as if it were the first named argument to a global
> > function. Some compilers hold the 'this' pointer in a register so that
> > it doesn't have to be passed around during member function calls from
> > other member functions. The proposed extension would preclude this
> > optimization (or, alternatively, impose an inefficient calling
> > convention on all global functions that take a pointer to a class type
> > as their first argument).

Hmm, I admit I didn't think about this.

But if I understand you correctly, what we are talking about
here is a mismatch of calling conventions. As such, and
please correct me if I'm wrong, it could be solved by the
compiler itself -- if case it uses internally a specialized
calling convention, it would be required, upon seeing the
syntax 'method() = function;' to implicitly generate a new
method/function that would translate its optimized calling
convention into standard function calling convention. The
'vftable' would then be inserted with the address of this
new function/method instead of the user-defined one.

marian

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

"Marian Pavlikovic" <mpavlikovic@bigfoot.com> wrote...
> [...]
> Nevertheless, I personally believe that this should be
> allowed along with any other function address assignment
> that you can think of. However, some OO enthusiasts might
> find things like the following one rather disturbing :-)
>
>     class A
>     {
>     public:
>         // ...
>         virtual void m();
>     };
>
>     void A::m() { /* ... */ }
>
>     class B : public A
>     {
>     public:
>         // ...
>         virtual void m();
>     };
>
>     void B::m() { /* ... */ }
>
>     class C : public A

Did you mean to write

    class C : public B

???

>     {
>     public:
>         // ...
>         virtual void m() = &A::m;   // skip the overload in 'B'
>     };

There is nothing disturbing in this (provided that C derives
from B, and you just made a typo above).  We have used such
constructs when one of the overridden functions "forwards" the
control to a grand-base class' function skipping the base.  It
is not pretty, but sometimes necessary.  It would be worse if
you could actually have A::m() as pure.  Suddenly, a derived
class from a concrete class 'B' becomes abstract again...  I
am not sure what OO people would have to say about that.  Of
course, it again presumes the typo above and C is derived from
B, as I suppose you meant it.

Victor
--
Please remove capital A's from my address when replying by mail


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

Every now and then I wonder why isn't construct like this
possible in C++:

    class A;
    extern void f1( A* pThis );
    extern char f2( const A* pThis , int i );

    class A
    {
    public:
        // ...

        virtual void m1() = f1;
        virtual char m2( int ) const = f2;
    };

In other words, it would be nice to extend the current
syntax used to identify a pure virtual function with '= 0'
to allow initialization of a vftable pointer with an
existing pointer to a function. Naturally, this should be
allowed only if the global function signature was equivalent
to the signature of the method. Such as method would not be
allowed to have any other definition.

Yes, a more specific definition for what it means to be
"equivalent" would be required. However, that shouldn't be
very difficult to design: something like I already used in
the example above could work quite fine: following usual
conventions, the 'this' pointer  from the method could be
required to be passed as the very first parameter of the
global function. I would say that standard cv-qualified
conversions on 'this' should be still allowed.

RATIONALE:

This syntax would nicely allow for bridging OO and
algorithmic/functional code. Admittedly, it is already
possible to achieve the same effect today by implementing
the method and delegating the call to a global function
manually, but using this syntax makes it not only more
straight forward, it also results in faster execution
(avoids additional function call) and simplifies the
maintenance.

In general, this syntax would give the developer much
greater control over definition of the vftable for
polymorphic classes beyond what rudimentary inheritance
rules provide.

Any problems/objections?

Marian Pavlikovic


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

Marian Pavlikovic wrote:
>
> Every now and then I wonder why isn't construct like this
> possible in C++:
>
>     class A;
>     extern void f1( A* pThis );
>     extern char f2( const A* pThis , int i );
>
>     class A
>     {
>     public:
>         // ...
>
>         virtual void m1() = f1;
>         virtual char m2( int ) const = f2;
>     };
>
> In other words, it would be nice to extend the current
> syntax used to identify a pure virtual function with '= 0'
> to allow initialization of a vftable pointer with an
> existing pointer to a function. Naturally, this should be
> allowed only if the global function signature was equivalent
> to the signature of the method. Such as method would not be
> allowed to have any other definition.

Compilers are not currently required to pass the 'this' pointer to a
member function as if it were the first named argument to a global
function. Some compilers hold the 'this' pointer in a register so that
it doesn't have to be passed around during member function calls from
other member functions. The proposed extension would preclude this
optimization (or, alternatively, impose an inefficient calling
convention on all global functions that take a pointer to a class type
as their first argument).

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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

Marian Pavlikovic wrote:

> Every now and then I wonder why isn't construct like this
> possible in C++:
>
>     class A;
>     extern void f1( A* pThis );
>     extern char f2( const A* pThis , int i );
>
>     class A
>     {
>     public:
>         // ...
>
>         virtual void m1() = f1;
>         virtual char m2( int ) const = f2;
>     };
>

Interesting. That makes f1(), f2() effectively
as out-of-class  default implementation of
A::m1(), A::m2()  except they can be
called as stand alone functions, and can access
only to the public members of A regardless if
A is further subclass or not.

In effect,
    f1(A* pthis)
    {
           pthis->m1();    // Possible recursive
    }

The line pthis->m1() depending on the actual
object f1() is bound to, and if that subclass
provides m1() implementation or default to A::m1().

One greate reason for programmers to eat healthy,
exercise more, and check out our heart conditions
often!  And a nice life insurance coverage just in case
something happens.  ;-)

Regards,
Shao

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

""Marian Pavlikovic"" <mpavlikovic@poboxes.com> wrote...
> Every now and then I wonder why isn't construct like this
> possible in C++:
>
>     class A;
>     extern void f1( A* pThis );
>     extern char f2( const A* pThis , int i );
>
>     class A
>     {
>     public:
>         // ...
>
>         virtual void m1() = f1;
>         virtual char m2( int ) const = f2;
>     };
>
> In other words, it would be nice to extend the current
> syntax used to identify a pure virtual function with '= 0'
> to allow initialization of a vftable pointer with an
> existing pointer to a function. Naturally, this should be
> allowed only if the global function signature was equivalent
> to the signature of the method. Such as method would not be
> allowed to have any other definition.

<innocentsarcasm>
What, no integral/arithmetic promotions, no conversions? :-(
We've just started having fun with those...
</innocentsarcasm>

> Yes, a more specific definition for what it means to be
> "equivalent" would be required. However, that shouldn't be
> very difficult to design: something like I already used in
> the example above could work quite fine: following usual
> conventions, the 'this' pointer  from the method could be
> required to be passed as the very first parameter of the
> global function. I would say that standard cv-qualified
> conversions on 'this' should be still allowed.
>
> RATIONALE:
>
> This syntax would nicely allow for bridging OO and
> algorithmic/functional code. Admittedly, it is already
> possible to achieve the same effect today by implementing
> the method and delegating the call to a global function
> manually, but using this syntax makes it not only more
> straight forward, it also results in faster execution
> (avoids additional function call) and simplifies the
> maintenance.
>
> In general, this syntax would give the developer much
> greater control over definition of the vftable for
> polymorphic classes beyond what rudimentary inheritance
> rules provide.
>
> Any problems/objections?

Additions, actually...

This should probably be allowed:

    class A
    {
    public:
        // ...

        virtual void m01();
        virtual void m02(int) const;

        virtual void m1() = m01;
        virtual char m2(int) const = m02;
    };
(the syntax should be improved, I am sure, especially if
 we allow m01 or/and m02 to be non-virtual...)

And this:

    class B
    {
    public:
        void m01(); // non-virtual
    };

    class A : B  // non-public inheritance
    {
    public:
        virtual void m1() = &B::m01; // is it accessible?
    };

Also, conversion to const should probably be OK:

    class A;
    void foo(const A*);
    class A
    {
        virtual void bar() = foo; // bar's *this is non-const
                                // but foo's param is
    };

Victor
--
Please remove capital A's from my address when replying by mail


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

Marian Pavlikovic wrote:
> Every now and then I wonder why isn't construct like this
> possible in C++:
>
>     class A;
>     extern void f1( A* pThis );
>     extern char f2( const A* pThis , int i );
>
>     class A
>     {
>     public:
>         // ...
>
>         virtual void m1() = f1;
>         virtual char m2( int ) const = f2;
>     };

Because it is unnecessary. You can already do the following:

struct A {
     virtual void m1() = 0;
     virtual char m2(int) const = 0;
};
void A::m1() { f1(this); }
char A::m2(int i) { return f2(this, i); }

You only need to make the members abstract if you want to.
I don't see what your suggested notation accomplishes beyond
what is already possible.

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

"Pete Becker" <petebecker@acm.org> wrote...
> Marian Pavlikovic wrote:
> >
> > Every now and then I wonder why isn't construct like this
> > possible in C++:
> >
> >     class A;
> >     extern void f1( A* pThis );
> >     extern char f2( const A* pThis , int i );
> >
> >     class A
> >     {
> >     public:
> >         // ...
> >
> >         virtual void m1() = f1;
> >         virtual char m2( int ) const = f2;
> >     };
> >
> > In other words, it would be nice to extend the current
> > syntax used to identify a pure virtual function with '= 0'
> > to allow initialization of a vftable pointer with an
> > existing pointer to a function. Naturally, this should be
> > allowed only if the global function signature was equivalent
> > to the signature of the method. Such as method would not be
> > allowed to have any other definition.
>
> Compilers are not currently required to pass the 'this' pointer to a
> member function as if it were the first named argument to a global
> function. Some compilers hold the 'this' pointer in a register so that
> it doesn't have to be passed around during member function calls from
> other member functions. The proposed extension would preclude this
> optimization (or, alternatively, impose an inefficient calling
> convention on all global functions that take a pointer to a class type
> as their first argument).

I don't understand how that would be true.  Why would such
imposition have to be made?  If a regular call to 'f1' can
be done with its argument in a register (I don't know of any
specific requirement in the Standard), why wouldn't the compiler
be able to preserve the 'this' in a register for 'f1'?  And if
the calling convention requires the argument of 'f1' to passed
in any other way (the stack, e.g.), the compiler would have to
 pull the 'this' value out of the register and push it into the
stack (or whatever is the actual parameter passing mechanism).

Of course, it's possible that I missed something, and the C++
Standard actually requires a particular and suboptimal calling
convention for external functions...  I would appreciate a ref.

Thank you.

Victor
--
Please remove capital A's from my address when replying by mail

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