www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Silly question

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
Are private functions that aren't declared final in the vtable?  Instinct 
tells me they should not be, but maybe they are...

-Steve
Apr 23 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Apr 23 2008
parent reply janderson <askme me.com> writes:
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
Apr 23 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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?
Apr 24 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"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
Apr 24 2008
prev sibling parent reply janderson <askme me.com> writes:
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
Apr 24 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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...
Apr 24 2008
parent reply janderson <askme me.com> writes:
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
Apr 24 2008
parent Jason House <jason.james.house gmail.com> writes:
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.
Apr 27 2008