C++ "this" parent type instead child

Development Programming & Scripting UI
, , , , , ,
1

Getting strange behaviour.

Call hierarchy: C(BP) inherits B(BP) inherits A(C++) implements some interface (C++).

A::A(){
    an_interface_pointer = this; // A implements the interface
}

C::someFunction(){ //actually blueprint, but ill write in C++ way
    printString(an_interface_pointer.toObject().getClassName()) //prints B.... WHAT?? :( 
}

Why does that happen? if i set the pointer value to “self” in BP constructor, no matter if it’s B or C classes, it does print C as needed, but i would like that functionality to be in C++, and at least understand why does this happen :confused:

thanks.

2

I’m not sure if I understand correctly. In a blueprint this works fine, but in c++ it does not? What does your constructor look like for B and C? Are you setting the pointer for these classes?

3

i don’t quite understand what do you mean by “works”.

the pointer does not return the right class by getClassName().

it is set to point to “this” (self) in c++, but for somewhat mistery reason an object of class C would have this function for the pointer return B instead.

the above happens in the way that i set it in the question code. as i have also mentioned there, if i set the same reference to the same value “this” (self) but in one of the BP constructors, ie B or C, the function outputs C (the right value) instead.

B constructor is empty of logics (it is explicitly calling A constructor to ensure it is not being ignored however)

C constructor is the same, just calling B constructor (which calls A constructor in it’s turn)

4

I believe your constructors should look something like this then:

A::A(){
    an_interface_pointer = this;
 }

B::B(){
    an_interface_pointer = this
}

C::(){
    an_interface_pointer = this;
}

You need to specify the values for each constructor because the order constructors are called would be A → B → C.

5

No, assigning this to an_interface_pointer in A is sufficient because of polymorphism. No idea why it says B instead of C, of course it should be C!

6

as @phisigma has stated, all the idea of inheritance and OOP is keeping the common logics in base class. otherwise why would we even use OOP? :stuck_out_tongue:

7

it’s really sad. well, how to do about that then? know of any workaround?

8

To initialize any default values, override virtual functions such as PostInitProperties() or PostLoad(), etc:

UObject::PostLoad

Or create your own BlueprintNativeEvent which can have C++ code easily overriden by a Blueprint version.

9

PostInitProperties() solved my problem, thanks :]
can you please convert the comment to answer so i mark it solved?

10

for future viewers, i really recommend this article for understanding your case: UObject Constructor, PostInitProperties and PostLoad – heapcleaner

11

That happens because Blueprints have GeneratedClass with a Class Default Object.
Blueprints are living on virtual environment of Kismet system, “C++ world” isn’t transparent to a Blueprint class thus your polymorphism rules will never apply to Kismet Compiler the way you think it should be.

12

Oh okay; moved post to answer section :slight_smile: