Why is this virtual function complaining about unresolved external symbols?

[versed scaffold]

Hi, im trying to make an abstract class that my components will inherit from and I want all of them to implement OnInit so I made that one pure virtual, but I only want some to inherit OnHealthUpdate.

class ComponentManager
{
public:

    ComponentManager() = default;
    ~ComponentManager() = default;

    virtual void OnInit() = 0;
    virtual void OnHealthUpdate();

    static void ComponentEvent_OnInit()
    {
        for (ULONG_PTR p_ptr : logic_components)
        {
            auto component = reinterpret_cast<ComponentManager*>(p_ptr);
            component->OnInit();
        }
    }

    static void ComponentsEvent_OnHealthUpdate(Event::OnHealthUpdateArgs event)
    {
        for (ULONG_PTR p_ptr : logic_components)
        {
            auto component = reinterpret_cast<ComponentManager*>(p_ptr);
            component->OnHealthUpdate(event);
        }
    }
}

Why cant I do it like this and just simply implement the OnHealthUpdate function in the components I want without getting unresolved external symbol for OnHealthUpdate?

[shut mason]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For more information use !howto ask.

[versed scaffold]

ok I think I solved it by adding {} after virtual void OnHealthUpdate(), is that the correct way to do it?

[cedar kraken]

yes, the implementation of that virtual function was missing

[versed scaffold]

alright thanks!

!solved

[shut mason]

Thank you and let us know if you have any more questions!

[cedar kraken]

are you sure that OnHealthUpdate should be left empty? why not make it a pure virtual function and force all who inherit from ComponentManager to override it?

[versed scaffold]

because im only gonna use it in like a couple components not all

although one thing im unsure about is if my destructor should be protected or virtual

[cedar kraken]

aha, well then yes, leave it as a normal virtual function

[cedar kraken]

the destructor needs to be public and virtual

public because otherwilse you can't destory objects a.k.a. your code doesn't compile

[versed scaffold]

if thats the case do I need to do final on all my classes i inherit from?

[cedar kraken]

and virtual because otherwise you will get horrible memory leaks due to the wrong destructors getting called to destory your objects when operator delete is called

[versed scaffold]

ah ok

[cedar kraken]

well, final is used for blocking inheritance

you decide

[versed scaffold]

when i make it virtual it gives another warning about my ComponentManager class that it defines a default destructor but doesnt define a copy constructor, a copy assignment operator, a move constructor or a move assignment operator...whats that about?

[cedar kraken]

just define them as =default

this warning is shown because you have virtual functions, a.k.a. you are doing fancy stuff, so copying and assignment is maybe, something fancy too

[versed scaffold]

class ComponentManager
{
public:

    ComponentManager() = default;
    virtual ~ComponentManager() = default;

is this correct?

[cedar kraken]

yes

since your class doesn't have any fields

[versed scaffold]

ill just ignore the warning then

[cedar kraken]

no, follow the warning and write:

ComponentManager(const ComponentManager&) = default;
ComponentManager& operator=(const ComponentManager&)=default;

[versed scaffold]

in addition to the default constructor i already have right?

[cedar kraken]

yes

[versed scaffold]

the warning seems to remain

the same one

[cedar kraken]

show me the warning

[cedar kraken]

copy paste the warning here

[versed scaffold]

ill send a screenshot

if thats fine

hope its visible

[cedar kraken]

aha, ok, fine, in C++11 we also have two functions for move semantics, here they are:

ComponentManager(ComponentManager&&)=default;
ComponentManager& operator=(ComponentManager&&)=default;

@versed scaffold

[versed scaffold]

ok I tried with those, the warning is still there

[cedar kraken]

rebuild your program

[versed scaffold]

still

[cedar kraken]

you defined all of these and you get a warning that they are not implemented?

[versed scaffold]

Yep

[cedar kraken]

can you send a screenshot again

[versed scaffold]

should I try restart my VS?

I tried clean solution + rebuild

[cedar kraken]

you erased the last two that were there

ComponentManager(const ComponentManager&) = default;
ComponentManager& operator=(const ComponentManager&)=default;

ComponentManager(ComponentManager&&)=default;
ComponentManager& operator=(ComponentManager&&)=default;

[versed scaffold]

Oh I thought you meant replace

[cedar kraken]

no, I meant add

here are all of them listed

[versed scaffold]

Now the warning is gone yep

[cedar kraken]

as expected

[versed scaffold]

I dont really understand this code though

[cedar kraken]

well... ignore the && stuff for now, write your other classes that inherit from this one

[versed scaffold]

Alright

[cedar kraken]

wait... you have written copy constructors before manually right?

[versed scaffold]

uhhh nooo...should I have?

first time I see this warning

[cedar kraken]

well... yea... this is crucial in C++ object oriented programming...

the idea is that the copy constructor creates a deep copy

and the compiler often automatically implements the copy constructor by copying the fields

[versed scaffold]

I guess ive just done basics not so much oop stuff, ive avoided virtuals and stuff like that until now

[cedar kraken]

but, if your class has fancy fields like pointers

then the copy constructor generated by the compiler is absolute trash

and you gotta write your own

manually

[versed scaffold]

oh ok

[cedar kraken]

so, now what are you going to inherit with?

what is this class actually used for?

[versed scaffold]

anything that needs to use my callbacks like the onhealthupdate and module initialization etc

i was planning on making my menu inherit from it

[cedar kraken]

k, if you get stuck, make posts and ask for help

I have a really bad feeling about this... you don't know the basics...

[versed scaffold]

I know c# and have coded 1 year in c++ so far

a bit new to the c++ oop stuff tho

[cedar kraken]

C# and C++ have nothing in common 😄

[versed scaffold]

hence my confusion

[cedar kraken]

yeah...

[versed scaffold]

1 last thing im wondering, should I trust resharper warnings? Such as "this class can be made final" "this function can be made static" etc

[cedar kraken]

no, those are "info" messages, not warnings

ignore them

[versed scaffold]

ok

just to clarify, what exactly do you have a bad feeling about? @cedar kraken

that im learning about these things head on xD?

cause yesterday someone told me to just go for it

[cedar kraken]

you will use trial and error to use inheritance, and you program will crash, and you will feel pain

[cedar kraken]

yeah

[versed scaffold]

yeah i was advised thats the best way to learn

[cedar kraken]

anyways, continue writing this program, let's see when you will hit crashes

[versed scaffold]

alright

[cedar kraken]

the reason why trial and error doesn't work is because C++ is very hostile towards beginners, unlike C#

and because you gotta control memory manually

there is no magical garbage collector

[versed scaffold]

well its like this, I stumble upon something I dont know and I either look for answers in here or I google it, is that trial and error? idk, what else would you suggest I do?

I just went by what @inner sandal told me yesterday that I should try things myself first

[cedar kraken]

that kinda works, I like to use learncpp.com

[cedar kraken]

well... when I was learning C++ I had a real life teacher in uni who explained the material well, are you in uni?

[inner sandal]

I mean, you should still read and study

that suggestion was contextual

don’t fall into analysis paralysis

you will be better to write code and not read than the other way around

but you should still read too