About Virtual and Override usage

I just wanted to clear out that using the virtual keyword allows the usage of the override keyword but that doesn’t mean that you cannot override a public or protected function from a derived class, you still can (by not adding override to the declaration of the method) but depending on the situation you may need to use virtual because you can come across something like this (I made a small example).

Another thing about override that I found a bit confusing and maybe you can explain this to me, why is it that I can override a virtual method that is public and declare it private on the header of the derived class?, it just doesn’t make sense since it will always execute (maybe that’s the reason the compiler doesn’t complain, it doesn’t matter right?).

That’s just having a function with the same name as the base class and there’s no overriding in that, your example proves this. Unless I’m not understanding what you said correctly.

From the C++ FAQ

[quote]Should I hide member functions that were public in my base class?

Never, never, never do this. Never. Never!
Attempting to hide (eliminate, revoke, privatize) inherited public member functions is an all-too-common design error. It usually stems from muddy thinking.

(Note: this FAQ has to do with public inheritance; private and protected inheritance are different.)[/quote]

and relevant stackoverflow

That’s just having a function with the same name as the base class and there’s no overriding in that, your example proves this. Unless I’m not understanding what you said correctly.

Thanks for the reply @DanM , you are right, I got confused by overriding using the virtual keyword, I thought that you could still override the method by calling it the same on the derived class and that this would work but I see that it doesn’t.

Should I hide member functions that were public in my base class?

Never, never, never do this. Never. Never!
Attempting to hide (eliminate, revoke, privatize) inherited public member functions is an all-too-common design error. It usually stems from muddy thinking.

(Note: this FAQ has to do with public inheritance; private and protected inheritance are different.)

Thanks for that info, I’ve never asked this to myself before mainly because the pre processors I’ve used before always got me an error if you would even dare to do something like this, thanks for clearing that out.

Hello Dan, I know bother you, sorry that, but nobody answer except you

  1. what’s relationship between classes Actor, AActor, Actor Component, Object, UObject


I don’t quite understand this definition

  1. why they don’t appear in Unreal Editor in Class Viewer (except Actor)

Every object is derived from UObject, an Actor is something derived from AActor (which in turn is derived from UObject) which is something that can be spawned into the world. An Actor Component (derived from UObject) is a component that is attached to an Actor.

I want to take example from passed course:

we have the Door in the world and OpenDoor Component. As I guess Door is AActor, (not Actor) which can be spawned into the World. if I am right please give me example of Object and Actor. Can be Object spawned into the World?

and why can’t find UObjcet and Object in the Class Viewer, we need not to access them?

No, you can tell by the prefix Unreal uses prefix with A means it’s derived from AActor e.g. APawn, ACharacter. Prefix with U means it’s derived from UObject like our UOpenDoorComponent.

You can use the docs to see the hierarchy

You can only see actors in the class viewer because this option is selected by default

Thank you Den and last. As I am clearing:

Actor

SM_Door(Instance) is form Actor class, which can be attached ActorComponent
StaticMesh is form UObject class, which is real, visualize on the screen

out come this with help SM_Door(Instance) we can add more features our StaticMesh (like moving, rotation and so on)
am I right?

I think so, if you mean you can attach ActorComponents to an Actor class and not the other way around.

Thank you Dan :slight_smile:

Privacy & Terms