Private functions cannot be overridden so I presume
they are implicitly final, am I right?

I was wondering if the compiler can automatically decide
if a function can be static or not where it is not specified
in the code. Can it?

-Dario

"Dario" <Dario_member@pathlink.com> wrote in message news:bepojd$1v2o$1@digitaldaemon.com...
> Private functions cannot be overridden so I presume
> they are implicitly final, am I right?

Yes.

> I was wondering if the compiler can automatically decide
> if a function can be static or not where it is not specified
> in the code. Can it?

It could by looking at the function body and seeing if there are no references to 'this'. However, this will fail if someone uses an abstract declaration of the function (i.e. declares it without a body), so I'd say that no, the compiler can't do it.

> > I was wondering if the compiler can automatically decide
> > if a function can be static or not where it is not specified
> > in the code. Can it?
>
> It could by looking at the function body and seeing if there are no references to 'this'. However, this will fail if someone uses an abstract declaration of the function (i.e. declares it without a body), so I'd say that no, the compiler can't do it.

Am firmly of the opinion that this would be a hideous thing conceptually, even if it were doable (which it is not).

I am, however, intrigued, as to whether functions that don't use 'this' still make reference to it. In other words, will D support the safe-this idiom, use by MFC in GetSafeHwnd()? Specifically, can I write the following

class X
{
public:
    bool    is_null()
    {
        return null == this ? true : false;
    }
}

int main(. . .)
{
    X    x1    =    new X();
    X    x2    =    null;

    printf("x1: %s\n", x1.is_null() ? "null" : "non-null");
    printf("x2: %s\n", x2.is_null() ? "null" : "non-null");

    return 0;
}

and have it print

        non-null
        null

rather than crash after printing

        non-null

?

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bfnmkd$2uqa$1@digitaldaemon.com...
>
> > > I was wondering if the compiler can automatically decide
> > > if a function can be static or not where it is not specified
> > > in the code. Can it?
> >
> > It could by looking at the function body and seeing if there are no references to 'this'. However, this will fail if someone uses an
abstract
> > declaration of the function (i.e. declares it without a body), so I'd
say
> > that no, the compiler can't do it.
>
> Am firmly of the opinion that this would be a hideous thing conceptually, even if it were doable (which it is not).
>
> I am, however, intrigued, as to whether functions that don't use 'this' still make reference to it. In other words, will D support the safe-this idiom, use by MFC in GetSafeHwnd()? Specifically, can I write the
following
>
> class X
> {
> public:
>     bool    is_null()
>     {
>         return null == this ? true : false;
>     }
> }
>
> int main(. . .)
> {
>     X    x1    =    new X();
>     X    x2    =    null;
>
>     printf("x1: %s\n", x1.is_null() ? "null" : "non-null");
>     printf("x2: %s\n", x2.is_null() ? "null" : "non-null");
>
>     return 0;
> }
>
> and have it print
>
>         non-null
>         null
>
> rather than crash after printing
>
>         non-null
>
> ?

You can only use that idiom if is_null() is final, otherwise it will crash
going through the vtbl[].

"Walter" <walter@digitalmars.com> wrote in message news:bhre6s$1nmf$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bfnmkd$2uqa$1@digitaldaemon.com...
> >
> > > > I was wondering if the compiler can automatically decide
> > > > if a function can be static or not where it is not specified
> > > > in the code. Can it?
> > >
> > > It could by looking at the function body and seeing if there are no references to 'this'. However, this will fail if someone uses an
> abstract
> > > declaration of the function (i.e. declares it without a body), so I'd
> say
> > > that no, the compiler can't do it.
> >
> > Am firmly of the opinion that this would be a hideous thing
conceptually,
> > even if it were doable (which it is not).
> >
> > I am, however, intrigued, as to whether functions that don't use 'this' still make reference to it. In other words, will D support the safe-this idiom, use by MFC in GetSafeHwnd()? Specifically, can I write the
> following
> >
> > class X
> > {
> > public:
> >     bool    is_null()
> >     {
> >         return null == this ? true : false;
> >     }
> > }
> >
> > int main(. . .)
> > {
> >     X    x1    =    new X();
> >     X    x2    =    null;
> >
> >     printf("x1: %s\n", x1.is_null() ? "null" : "non-null");
> >     printf("x2: %s\n", x2.is_null() ? "null" : "non-null");
> >
> >     return 0;
> > }
> >
> > and have it print
> >
> >         non-null
> >         null
> >
> > rather than crash after printing
> >
> >         non-null
> >
> > ?
>
> You can only use that idiom if is_null() is final, otherwise it will crash
> going through the vtbl[].

Which brings us round to the possibilities of having a nonvirtual keyword and non-virtual methods, for those of us who feel the need. Maybe final is the way to go, but AFAIU final does not stipulate non-virtuality, just "no more overriding beyond this point".

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bhrjhf$1vsd$1@digitaldaemon.com...
> > You can only use that idiom if is_null() is final, otherwise it will
crash
> > going through the vtbl[].
> Which brings us round to the possibilities of having a nonvirtual keyword and non-virtual methods, for those of us who feel the need. Maybe final is the way to go, but AFAIU final does not stipulate non-virtuality, just "no more overriding beyond this point".

Final might as well stipulate non-virtuality, as there is no semantic difference between the two.

"Walter" <walter@digitalmars.com> wrote in message news:bi4dd3$2o0v$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bhrjhf$1vsd$1@digitaldaemon.com...
> > > You can only use that idiom if is_null() is final, otherwise it will
> crash
> > > going through the vtbl[].
> > Which brings us round to the possibilities of having a nonvirtual
keyword
> > and non-virtual methods, for those of us who feel the need. Maybe final
is
> > the way to go, but AFAIU final does not stipulate non-virtuality, just
"no
> > more overriding beyond this point".
>
> Final might as well stipulate non-virtuality, as there is no semantic difference between the two.

only if not an overriden final or accessed via a pointer to the class where it is declared final or sub class there of

class A { int foo() { return 1; } }
class B : A { final int foo() { return 0; } }
class C : B { final int bar() { return 0; } }

int func( A a ) { return a.foo(); } // virtual call (must be)
int func( B b ) { return b.foo(); } // can be nonvirtual
int func( C b ) { return c.foo(); } // can be nonvirtual  B::foo

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bi5bgf$13nv$5@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:bi4dd3$2o0v$1@digitaldaemon.com...
> >
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bhrjhf$1vsd$1@digitaldaemon.com...
> > > > You can only use that idiom if is_null() is final, otherwise it will
> > crash
> > > > going through the vtbl[].
> > > Which brings us round to the possibilities of having a nonvirtual
> keyword
> > > and non-virtual methods, for those of us who feel the need. Maybe
final
> is
> > > the way to go, but AFAIU final does not stipulate non-virtuality, just
> "no
> > > more overriding beyond this point".
> >
> > Final might as well stipulate non-virtuality, as there is no semantic difference between the two.
>
> only if not an overriden final or accessed via a pointer to the class
where
> it is declared final or sub class there of
>
> class A { int foo() { return 1; } }
> class B : A { final int foo() { return 0; } }
> class C : B { final int bar() { return 0; } }
>
> int func( A a ) { return a.foo(); } // virtual call (must be)
> int func( B b ) { return b.foo(); } // can be nonvirtual
> int func( C b ) { return c.foo(); } // can be nonvirtual  B::foo

Right. It is an error to override a final!

"Walter" <walter@digitalmars.com> wrote in message news:bi5l0r$1hih$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bi5bgf$13nv$5@digitaldaemon.com...
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:bi4dd3$2o0v$1@digitaldaemon.com...
> > >
> > > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bhrjhf$1vsd$1@digitaldaemon.com...
> > > > > You can only use that idiom if is_null() is final, otherwise it
will
> > > crash
> > > > > going through the vtbl[].
> > > > Which brings us round to the possibilities of having a nonvirtual
> > keyword
> > > > and non-virtual methods, for those of us who feel the need. Maybe
> final
> > is
> > > > the way to go, but AFAIU final does not stipulate non-virtuality,
just
> > "no
> > > > more overriding beyond this point".
> > >
> > > Final might as well stipulate non-virtuality, as there is no semantic difference between the two.
> >
> > only if not an overriden final or accessed via a pointer to the class
> where
> > it is declared final or sub class there of
> >
> > class A { int foo() { return 1; } }
> > class B : A { final int foo() { return 0; } }
> > class C : B { final int bar() { return 0; } }
> >
> > int func( A a ) { return a.foo(); } // virtual call (must be)
> > int func( B b ) { return b.foo(); } // can be nonvirtual
> > int func( C b ) { return c.foo(); } // can be nonvirtual  B::foo
>
> Right. It is an error to override a final!

I have not overriden a final [the code was a little wrong] should be

class A { int foo() { return 1; } }
class B : A { final int foo() { return 0; } }
class C : B { final int bar() { return 0; } }

int func( A a ) { return a.foo(); } // virtual call (must be)
int func( B b ) { return b.foo(); } // can be nonvirtual
int func( C c ) { return c.foo(); } // can be nonvirtual  B::foo
int main( char[][] args ) {
 A a = new A();
 B b = new B();
 C c = new C();
 func ( a ); func(b); func(c);
 return 0;
}

still func(A a ) need to make a virtual call to foo
foo is declared `virtual` in A then `final` in B
do you mean an overridden function can not be final ? (the above code
compiles)
the above code compiles fine and runs and as the other test implies you are
making a virtual call to a final function. so final and `non-virtual` are
not the same always.

class A { int foo() { return 1; } }
class B : A { final int foo() { return 0; } }
class C : B { final int bar() { return 0; } }

int funcA( A a ) { return a.foo(); } // virtual call (must be)
int funcB( B b ) { return b.foo(); } // can be nonvirtual
int main( char[][] args ) {
 A a = new A();
 B b = new B();
 C c = new C();
 int i;
 i = funcA( a );
 printf( "funcA(a) = %d\n", i );
 i = funcA( b );
 printf( "funcA(b) = %d\n", i );
 i = funcA( c );
 printf( "funcA(c) = %d\n", i );
 i = funcB( b );
 printf( "funcB(b) = %d\n", i );
 i = funcB( c );
 printf( "funcB(c) = %d\n", i );
 return 0;
}

outputs
funcA(a) = 1
funcA(b) = 0
funcA(c) = 0
funcB(b) = 0
funcB(c) = 0

as you would expect

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bi6hdd$2rpa$3@digitaldaemon.com...
> > Right. It is an error to override a final!
> I have not overriden a final [the code was a little wrong]

Correct, you did not. If you did, the compiler should have issued an error.