Are private functions that aren't declared final in the vtable?  Instinct tells me they should not be, but maybe they are...

-Steve

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:fuo7ac$17mn$1@digitalmars.com...
> Are private functions that aren't declared final in the vtable?  Instinct tells me they should not be, but maybe they are...
>
> -Steve
>

They aren't, at least what a little experiment shows:

class A
{
    public void foo() {}
}

class B
{
    private void bar() {}
}

void main(char[][] args)
{
    Stdout.formatln("{}", Object.classinfo.vtbl.length);
    Stdout.formatln("{}", A.classinfo.vtbl.length);
    Stdout.formatln("{}", B.classinfo.vtbl.length);
}

prints 5, 6, 5.

Jarrett Billingsley wrote:
> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:fuo7ac$17mn$1@digitalmars.com...
>> Are private functions that aren't declared final in the vtable?  Instinct tells me they should not be, but maybe they are...
>>
>> -Steve
>>
> 
> They aren't, at least what a little experiment shows:
> 
> class A
> {
>     public void foo() {}
> }
> 
> class B
> {
>     private void bar() {}
> }
> 
> void main(char[][] args)
> {
>     Stdout.formatln("{}", Object.classinfo.vtbl.length);
>     Stdout.formatln("{}", A.classinfo.vtbl.length);
>     Stdout.formatln("{}", B.classinfo.vtbl.length);
> }
> 
> prints 5, 6, 5. 
> 
> 

They are however in my book this is plain wrong.  The whole purpose of being able to hide abstraction layers is broken.  I should be able to protect inherited functions from objects that work on that level.  Its a fundamental principle in C++.

-Joel

"janderson" <askme@me.com> wrote in message news:fuorvl$2j02$1@digitalmars.com...

> They are however in my book this is plain wrong.  The whole purpose of being able to hide abstraction layers is broken.  I should be able to protect inherited functions from objects that work on that level.  Its a fundamental principle in C++.

What?

Am I the only one who can't understand what this post means?

"Jarrett Billingsley" wrote
> "janderson" wrote
>> They are however in my book this is plain wrong.  The whole purpose of being able to hide abstraction layers is broken.  I should be able to protect inherited functions from objects that work on that level.  Its a fundamental principle in C++.
>
> What?
>
> Am I the only one who can't understand what this post means?


I'm not sure, but I think he's talking about private base classes.  Where all the base class' functions are private in a derived class.  Other than that, I don't see how you could override a virtual function and make it private...

But thanks for your experiment, I didn't really know how to do that kind of a test :)

For some reason my brain wasn't working yesterday.  I found this in the docs (http://www.digitalmars.com/d/1.0/function.html) today:

"All non-static *non-private* non-template member functions are virtual"

Sorry for the noise...

-Steve

Jarrett Billingsley wrote:
> "janderson" <askme@me.com> wrote in message news:fuorvl$2j02$1@digitalmars.com...
> 
>> They are however in my book this is plain wrong.  The whole purpose of being able to hide abstraction layers is broken.  I should be able to protect inherited functions from objects that work on that level.  Its a fundamental principle in C++.
> 
> What?
> 
> Am I the only one who can't understand what this post means? 
> 
> 


I have a interface:
(I'm using C++ because this won't work in D)

class OnRenderI
{
   public:
	virtual void OnRender() = 0;
};


I have a derived class:

class A : OnRenderI
{
   public:
	A() {  GetRender().Add(Me); }
   private:  //Or protected
	virtual void OnRender(); //This is good private
}



I have my render:

class Render
{
   Add(OnRenderI& render);
};


This is very good practice.  The renderer is the one who knows about how to render OnRender-ables.  People who have a class A should not be-able to call OnRender.  Reasons if they where to use a public on A:

1) Then they are coupling OnRender method to class A.  This is bad because not we can't simply remove OnRender and put it elsewhere.

2) The size of A's interface is larger.  That makes the class more complex.   You want to keep your interfaces small.  You want to keep the responsibility of a class small.  This makes it easier to validate and prevent problems.  Essentially you want to make invariants.  Private virtual inheritance is tool to help meet those goals.

3) You want to force behavior to occur at the interface level so that you can easily switch the owner class without touching how the inherited classes work.  It makes it more difficult for you or others from passing around A objects instead of OnRender objects to get at the OnRenderI method.  Basically its good decoupling.  Stuff that deal with OnRender know about OnRender stuff but not A.  Stuff that deal with A know about A stuff but shouldn't know about OnRender.

Remember inheritance is one of the tightest couplings there is.  So anything that we can do to remove the coupling is a great improvement.

You might want to read, Effective C++ for more information.

Some people even recommend never having a public virtual at all (even in the base class).  I won't go that far, but they do have a good point.

I hope that was helpful.
-Joel

janderson wrote:
> Jarrett Billingsley wrote:
>> "janderson" <askme@me.com> wrote in message news:fuorvl$2j02$1@digitalmars.com...
>>
>>> They are however in my book this is plain wrong.  The whole purpose of being able to hide abstraction layers is broken.  I should be able to protect inherited functions from objects that work on that level.  Its a fundamental principle in C++.
>>
>> What?
>>
>> Am I the only one who can't understand what this post means?
>>
> 
> 
> I have a interface:
> (I'm using C++ because this won't work in D)
> 
> class OnRenderI
> {
>    public:
>     virtual void OnRender() = 0;
> };
> 
> 
> I have a derived class:
> 
> class A : OnRenderI
> {
>    public:
>     A() {  GetRender().Add(Me); }
>    private:  //Or protected
>     virtual void OnRender(); //This is good private
> }

Are you decreasing the visibility of method OnRender? I don't get it...

void foo(A a) {
  a.OnRender(); // nope, it's private

  OnRenderI r = (OnRenderI) a;
  r.OnRender(); // Now it's public??
}

I'm sure misunderstanding something...

Ary Borenszweig wrote:
> janderson wrote:
>> Jarrett Billingsley wrote:
>>> "janderson" <askme@me.com> wrote in message news:fuorvl$2j02$1@digitalmars.com...
>>>
>>>> They are however in my book this is plain wrong.  The whole purpose of being able to hide abstraction layers is broken.  I should be able to protect inherited functions from objects that work on that level.  Its a fundamental principle in C++.
>>>
>>> What?
>>>
>>> Am I the only one who can't understand what this post means?
>>>
>>
>>
>> I have a interface:
>> (I'm using C++ because this won't work in D)
>>
>> class OnRenderI
>> {
>>    public:
>>     virtual void OnRender() = 0;
>> };
>>
>>
>> I have a derived class:
>>
>> class A : OnRenderI
>> {
>>    public:
>>     A() {  GetRender().Add(Me); }
>>    private:  //Or protected
>>     virtual void OnRender(); //This is good private
>> }
>
> Are you decreasing the visibility of method OnRender? I don't get it...
>
> void foo(A a) {
>   a.OnRender(); // nope, it's private
>
>   OnRenderI r = (OnRenderI) a;
>   r.OnRender(); // Now it's public??
> }
>
> I'm sure misunderstanding something...

Yep

You can also go in C++.

OnRenderI r = a; //No cast required (automatic upcast)

so:

a.OnRender(); //Nooo

r.OnRender(); //Yes but calls a's OnRender();


or

class Render
{
void Add(IOnRender a)=0;
}

....

A a;

render.Add(a); //Yes, a is automatically upcast.

-Joel

janderson wrote:

> Ary Borenszweig wrote:
>  > janderson wrote:
>  >> Jarrett Billingsley wrote:
>  >>> "janderson" <askme@me.com> wrote in message
> news:fuorvl$2j02$1@digitalmars.com...
>  >>>
>  >>>> They are however in my book this is plain wrong.  The whole
> purpose of being able to hide abstraction layers is broken.  I should be
> able to protect inherited functions from objects that work on that
> level.  Its a fundamental principle in C++.
>  >>>
>  >>> What?
>  >>>
>  >>> Am I the only one who can't understand what this post means?
>  >>>
>  >>
>  >>
>  >> I have a interface:
>  >> (I'm using C++ because this won't work in D)
>  >>
>  >> class OnRenderI
>  >> {
>  >>    public:
>  >>     virtual void OnRender() = 0;
>  >> };
>  >>
>  >>
>  >> I have a derived class:
>  >>
>  >> class A : OnRenderI
>  >> {
>  >>    public:
>  >>     A() {  GetRender().Add(Me); }
>  >>    private:  //Or protected
>  >>     virtual void OnRender(); //This is good private
>  >> }
>  >
>  > Are you decreasing the visibility of method OnRender? I don't get it...
>  >
>  > void foo(A a) {
>  >   a.OnRender(); // nope, it's private
>  >
>  >   OnRenderI r = (OnRenderI) a;
>  >   r.OnRender(); // Now it's public??
>  > }
>  >
>  > I'm sure misunderstanding something...
> 
> Yep
> 
> You can also go in C++.
> 
> OnRenderI r = a; //No cast required (automatic upcast)
> 
> so:
> 
> a.OnRender(); //Nooo
> 
> r.OnRender(); //Yes but calls a's OnRender();
> 
> 
> or
> 
> class Render
> {
> void Add(IOnRender a)=0;
> }
> 
> ....
> 
> A a;
> 
> render.Add(a); //Yes, a is automatically upcast.
> 
> -Joel

IMHO, this type of functionality becomes tough for anyone reading/manipulationg the code to keep things straight.  While it certainly is valid C++, I'm happy to see it's not in D.