Polymorphism violating private access modifier

[Speedo]

Sorry, I understand that, but I still don't understand how you would enforce that a virtual function declared as private in a derived class but declared public in the base class is not called from a base class object such as the one in my example.

Don't think it's possible without redesigning the language. As nuzzle said the concept of "private" only exists at compile-time. You're asking the virtual call mechanism to enforce access restrictions at runtime, which it's totally incapable of doing in its current form.

I don't have the standard in front of me at the moment, but I wouldn't be surprised if what you're doing is undefined behavior. The whole point of polymorphism is to be able to access a certain functionality through an interface defined by the base class, so if a derived class decides to change that interface.... all bets are probably off.

[laserlight]

I don't have the standard in front of me at the moment, but I wouldn't be surprised if what you're doing is undefined behavior.

It is well defined, and C++03 section 11.6 even has a direct example of what happens when the derived class overrides a public virtual member function to have private access.

nuzzle cited what sounds like a plausible use of this feature, but frankly its use feels like abuse. (That rhymes!)

[superbonzo]

nuzzle cited what sounds like a plausible use of this feature, but frankly its use feels like abuse. (That rhymes!)

maybe, nuzzle's pattern is a "low cost" alternative to the use of private virtuals and public forwarders whenever the latter are not allowed. That sead, the idea of a class that does not fully include its public base public interface is quite counterintuitive ( argh, no rhymes! )

[laserlight]

nuzzle's pattern is a "low cost" alternative to the use of private virtuals and public forwarders whenever the latter are not allowed.

As in the non-virtual interface idiom? It seems a little different though, since with NVI you can use the function given just an object of the derived class, but with respect to nuzzle's use you really need a base class pointer/reference/object.

[superbonzo]

As in the non-virtual interface idiom? .

yes ...

It seems a little different though, since with NVI you can use the function given just an object of the derived class, but with respect to nuzzle's use you really need a base class pointer/reference/object.

... and yes .

I didn't mean they are equivalent and I'm not fostering it. But in this way you have a bit more control on the way polymorhic behaviour is invoked compared to only public virtuals. For example, you can always convert it to NVI by modifyng only the code accessing base objects without touching code explicitly using derived classes public interfaces.

[nuzzle]

maybe, nuzzle's pattern is a "low cost" alternative to the use of private virtuals and public forwarders whenever the latter are not allowed. That sead, the idea of a class that does not fully include its public base public interface is quite counterintuitive ( argh, no rhymes! )

I've never thought about it really because I find it so natural,

class Base {
public:
   // pure virtual interface (the Base type)
};
//
class Derived : public Base {
private:
   // implementation of the Base type
};

In a polymorphic design most of the time the above is exactly what you want.

When a Derived class is instantiated it's immediately assigned to a Base variable. It's not used in any other way so there's no need for it to publicly expose the interface it has implemented. This is the ultimate encapsulation really.

If anyone sees a problem with this I would be very interested to hear about it because I'm using this approach quite alot.

[sockman]

Sorry, I understand that, but I still don't understand how you would enforce that a virtual function declared as private in a derived class but declared public in the base class is not called from a base class object such as the one in my example.

If you don't want the function to be called by the base class then:
1. don't declare it as abstract in the base class and
2. don't provide an implementation of it in your derived class.

Your current design would be useful if you want typical polymorphic behaviour on your derived class, but want to make sure that the function can't be called outside of the inheritance hierarchy.
Cheers,
BJW

[superbonzo]

In a polymorphic design most of the time the above is exactly what you want.
When a Derived class is instantiated it's immediately assigned to a Base variable. It's not used in any other way so there's no need for it to publicly expose the interface it has implemented. This is the ultimate encapsulation really.

That's a different story, you are privately inheriting from Base. Among other things this means that you must supply some factory (static member or friend non member) function in order to "assign" it to a Base variable. Certainly this is a stronger form of encapsulation but I don't known how many here would define that sort of design the prototypical polymorphic design.

[nuzzle]

That's a different story, you are privately inheriting from Base.

That's a mistake, it should be public inheritance. I correct it in my previous post.

[superbonzo]

That's a mistake, it should be public inheritance. I correct it in my previous post.

ok.

If anyone sees a problem with this I would be very interested to hear about it because I'm using this approach quite alot.

IMHO it depends on what you consider part of the interface of the system your developing: if the interface is identifiable with your abstract base classes then that's fine; but if by interface you mean the whole semantic "world" represented by your type system ( thus including all types and functions operating on them in a specified namespace ) then you'll get in trouble if public inheritance does not imply full inclusivity of public members.

For example, suppose you have a class world::A and a function world:o_something_to(A&). Then, you can define a world::B: public A. That's fine because do_something_to(B_instance) should work properly (and this works with your use pattern). But you can also define a world:o_something_to(B&) and here come troubles because the do_something_to(B&) implementor expects that whatever you can do to an A can be done to a B.

[Mybowlcut]

You cannot enforce something that is in contrast to the mechanism you use. Public inheritance means is-a, so if you say that Text is a GUI_Object, then Text must behave like a GUI_Object. What you want to express is that Text is sort of a bit like a GUI_Object, which is not what public inheritance expresses.

Besides, what would you expect to happen. The compiler does not (necessarily) know what's the derived object that you are calling the function on, so it cannot give you an error. Are you expecting a private_function_exception to be thrown?

Actually, you have misunderstood what I meant. I was asking nuzzle how he would do this:

I often do this in polymorphic designs to enforce that derived type objects are used only as base type objects. Methods just aren't accessible in derived objects.

I misread what he wrote, as I thought he said he was somehow enforcing that derived class virtual functions weren't being called through base objects.

As for my problem, can anyone help suggesting a better design?

This has brought up another problem for me... that is, I have a shared_ptr<GUI_Object> and want to have a property grid that displays the properties of the object - how would I get an instance of that type of object if all I have to go by is a string containing the type of the object? Can someone please suggest a better design? This one is horrible.