↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → "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?
↑ ↓ ← → "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
↑ ↓
← → 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
↑ ↓ ← → 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...
↑ ↓ ← → 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
↑ ↓ ← → 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.
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next