In article <313pd6$ntb@wyatt.ksu.ksu.edu>, khise@wyatt.ksu.ksu.edu (Martin Shobe) writes:
|>
|> In article <1994Jul25.181849.12913@bnrmtl.bnr.ca>, ldang@bnr.ca (Student) writes:
|> > : >But this problem has led me to another. I have discovered that
|> > : >in some cases, the fact that the scope operator necessary to make
|> > : >visible hidden information was also used to break virtuality was
|> > : >very inconvenient and that in that case, the use of pointers to
|> > : >member functions was the only work around.
|> >        ^^^^
|>
|> > Nah !!! Ofcourse not !
|>
|> > : >
|> > : >example :
|> > : >
|> > : >#include <iostream.h>
|> > : >class A {
|> > : > public :
|> > : > virtual int f() =0;
|> > : >};
|> > : >class B : public A {
|> > : > public :
|>
|>  virtual int f() = 0;
|>         ^^^^^^^^^^^^^^^^^^^^
|>
|> > : > virtual int f(int n) {
|> > : >   // Here we want to express f(int) with f() i.e
|> > : >   // f(n) = n * f()
|> > : >   // but we can't write : return n * f()
|> > : >   // as f() is hidden by f(int). Neither A::f() can be used
|> > : >   // as it would break virtuality and moreover it doesn't work
|> > : >   // as f() is pure. The only way is to use a pointer to m.f :
|> > : >  int (A::*pf)()=&A::f;
|> > : >  return n * (this->*pf)();
|>
|>
|> >  const A& self = *this;
|> >  return n * self.f();

Well tried but it doesn't work for two reasons :

 1) A::f is non-const (can modify the object) and you call it on a const object
 2) It doesn't work if A::f is protected. My solution works as A::f is not
    referenced in B::f(int) via a pointer to A.

|>
|> > : > }
|> > : >};
|>
|>
|> You could also insert the underlined function.

Of course making f visible in B solves the problem. But it's
by keeping f hidden in B that I wanted to solve it.

|>
|>
|> Martin          khise@matt.ksu.ksu.edu


------Etienne FREJAVILLE--- Bull S.A   ---------------------------------
 OSS/HEU/ASD/TOPAS                      e-mail: E.Frejaville@frcl.bull.fr
 Rue Jean-Jaures, F5-238                tel: (33-1) 30806548
 78340 Les Clayes-sous-Bois, France     Fax: (33-1) 30803338

John Max Skaller (maxtal@physics.su.OZ.AU) wrote:
: >From: E.Frejaville@frcl.bull.fr (Etienne Frejaville)
: >Subject: virtuality and explicit qualification conflict ?
: >
: >My first question is : Why the language doesn't provide any
: >syntactic mean to break virtuality on the call :
: >
: > (pa->*pf)();

:  No one thought it was important I suppose.
: >
: >Besides, would it be possible ... ?

:  Yes, its possible. The syntax for pointers to member
: functions could have been chosen to represent EITHER
: the virtual or non-virtual versions of the virtual function.
: The former was chosen. Obviously, more syntax is needed if
: we are to allow pointers to members of both kinds.

: >
: >But this problem has led me to another. I have discovered that
: >in some cases, the fact that the scope operator necessary to make
: >visible hidden information was also used to break virtuality was
: >very inconvenient and that in that case, the use of pointers to
: >member functions was the only work around.
       ^^^^

Nah !!! Ofcourse not !

: >
: >example :
: >
: >#include <iostream.h>
: >class A {
: > public :
: > virtual int f() =0;
: >};
: >class B : public A {
: > public :
: > virtual int f(int n) {
: >   // Here we want to express f(int) with f() i.e
: >   // f(n) = n * f()
: >   // but we can't write : return n * f()
: >   // as f() is hidden by f(int). Neither A::f() can be used
: >   // as it would break virtuality and moreover it doesn't work
: >   // as f() is pure. The only way is to use a pointer to m.f :
: >  int (A::*pf)()=&A::f;
: >  return n * (this->*pf)();


 const A& self = *this;
 return n * self.f();



: > }
: >};

:  Ooooo. What a lovely example. Thanks!
        ^^^^^^

Really ???!!! I don't see it !!!!

--------------
LD.









: >
: >So my second question is : is it convenient to use the same
: >operator for scope qualification and to break virtuality ?

:  Having just proved it isnt, I assume you have
: been taking lessons from the English in "understatement" :-)

: >More generally, is not normal that in some case,
: >pointer to member functions must be used as a work around to
: >express what cannot be expressed otherwise ?
: >
: >Any ideas ?

:  Sure. Change the name of f(int) to g(int).


: --
:         JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
:  Maxtal Pty Ltd,
:         81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
:         NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <1994Jul25.181849.12913@bnrmtl.bnr.ca>, ldang@bnr.ca (Student) writes:
> : >But this problem has led me to another. I have discovered that
> : >in some cases, the fact that the scope operator necessary to make
> : >visible hidden information was also used to break virtuality was
> : >very inconvenient and that in that case, the use of pointers to
> : >member functions was the only work around.
>        ^^^^

> Nah !!! Ofcourse not !

> : >
> : >example :
> : >
> : >#include <iostream.h>
> : >class A {
> : > public :
> : > virtual int f() =0;
> : >};
> : >class B : public A {
> : > public :

 virtual int f() = 0;
        ^^^^^^^^^^^^^^^^^^^^

> : > virtual int f(int n) {
> : >   // Here we want to express f(int) with f() i.e
> : >   // f(n) = n * f()
> : >   // but we can't write : return n * f()
> : >   // as f() is hidden by f(int). Neither A::f() can be used
> : >   // as it would break virtuality and moreover it doesn't work
> : >   // as f() is pure. The only way is to use a pointer to m.f :
> : >  int (A::*pf)()=&A::f;
> : >  return n * (this->*pf)();


>  const A& self = *this;
>  return n * self.f();

> : > }
> : >};


You could also insert the underlined function.


Martin          khise@matt.ksu.ksu.edu

>From: E.Frejaville@frcl.bull.fr (Etienne Frejaville)
>Subject: virtuality and explicit qualification conflict ?
>
>My first question is : Why the language doesn't provide any
>syntactic mean to break virtuality on the call :
>
> (pa->*pf)();

 No one thought it was important I suppose.
>
>Besides, would it be possible ... ?

 Yes, its possible. The syntax for pointers to member
functions could have been chosen to represent EITHER
the virtual or non-virtual versions of the virtual function.
The former was chosen. Obviously, more syntax is needed if
we are to allow pointers to members of both kinds.

>
>But this problem has led me to another. I have discovered that
>in some cases, the fact that the scope operator necessary to make
>visible hidden information was also used to break virtuality was
>very inconvenient and that in that case, the use of pointers to
>member functions was the only work around.
>
>example :
>
>#include <iostream.h>
>class A {
> public :
> virtual int f() =0;
>};
>class B : public A {
> public :
> virtual int f(int n) {
>   // Here we want to express f(int) with f() i.e
>   // f(n) = n * f()
>   // but we can't write : return n * f()
>   // as f() is hidden by f(int). Neither A::f() can be used
>   // as it would break virtuality and moreover it doesn't work
>   // as f() is pure. The only way is to use a pointer to m.f :
>  int (A::*pf)()=&A::f;
>  return n * (this->*pf)();
> }
>};

 Ooooo. What a lovely example. Thanks!
>
>So my second question is : is it convenient to use the same
>operator for scope qualification and to break virtuality ?

 Having just proved it isnt, I assume you have
been taking lessons from the English in "understatement" :-)

>More generally, is not normal that in some case,
>pointer to member functions must be used as a work around to
>express what cannot be expressed otherwise ?
>
>Any ideas ?

 Sure. Change the name of f(int) to g(int).

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189