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 



 They are however in my book this is plain wrong.  The whole 




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