# Virtual functions are not called from a static library

This topic is 842 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

c+++. I'm in the process of moving my engine to a static library but ran into some issues. Everything complied fine and I got a fresh .lib file. The game that uses the engine runs fine but the UI is not showing up at all, while everything else is rending fine. I'm thinking it's because my UI has a base class with virtual functions. So it's probably not calling the correct Draw() methods belonging to the ui elements.

The static library and the exe that calls it are in the same solution but separate projects. I'm referencing the .lib project from my exe project. The headers are all the same, they're actually all in the same folder of the exe project, I didn't have time to move them. Stackexchange thread I found said that it could be due to header mismatch, but that's impossible since I just excluded the headers from one project and included them into my .lib project. edit: but just in case I cleaned, and rebuilt both projects.

Thanks.

Edited by VanillaSnake

##### Share on other sites

Moving code into a lib shouldn't affect your virtual functions at all. Try setting a breakpoint right before your Draw function gets called, and step into the call to see what happens / where it goes (in visual studio, F9 to set a breakpoint, F10 for "step over", F11 for "step into").

##### Share on other sites

Moving code into a lib shouldn't affect your virtual functions at all. Try setting a breakpoint right before your Draw function gets called, and step into the call to see what happens / where it goes (in visual studio, F9 to set a breakpoint, F10 for "step over", F11 for "step into").

Right before, fine it hits it. Break point inside the Draw function misses.

##### Share on other sites

Moving code into a lib shouldn't affect your virtual functions at all. Try setting a breakpoint right before your Draw function gets called, and step into the call to see what happens / where it goes (in visual studio, F9 to set a breakpoint, F10 for "step over", F11 for "step into").

Right before, fine it hits it. Break point inside the Draw function misses.

Have a look at the object you're calling Draw on (use a watch window). Is it the type of object you expect?

Step into the draw function (F11), which function does it call?

Finally, check your compiler/project settings. Are you sure that your code in the lib is being called?

Do a rebuild etc.

##### Share on other sites

It is incredibly easy to accidentally make your Derived class' functions not properly override, by getting the signature wrong. Here's an example:

class Base
{
virtual void MyFunc() const;
};

class Derived : public Base
{
void MyFunc(); //<-- Won't override, because the 'const' is missing, so it's a different function entirely.
};

The more parameters, attributes, and long return variable names, the easier it is to accidentally mess the signatures up.

That's why, in C++11 and above, they added the 'override' keyword:

class Derived : public Base
{
void MyFunc() const override;
};


The override keyword enforces, at compile time, that the function signature actually matches.
(Unless you have multiple virtual functions with the same name that overload each other in the base class. If so, then you need to ban yourself from C++ and learn a more user-friendly language.  :P)

Basically, anytime you ever say "virtual" in a Base class, you should now say "override" in a Derived class, and let the compiler catch your mistakes for you.

I'm not 100% sure this is your problem, but since it's the most common problem, it'd be item #1 to check.  :)

The headers are all the same, they're actually all in the same folder of the exe project, I didn't have time to move them.

Well, actually, that should be your first fix. The headers for your library should belong with your library. There should almost never be two headers for the same class.

Your Derived class' "Derived.h" header should #include "./MyLibrary/Base.h" - not a copy of it, but the exact same file that was used to compile the library.

Anything other than that is abnormal - not 100% always wrong, but 99.99% of the time wrong (no exaggeration; only about 1 out of 10,000 headers should do that, to give not un-reasonable estimate. Likely even fewer than that). In coding, 'abnormal' almost always means 'guilty until proven innocent'.  :wink:

##### Share on other sites
Sometimes, if the debugger is confused enough, it won't be able to find the memory address that it needs to place a breakpoint on. Sometimes it'll tell you this, sometimes you can miss it.

If a breakpoint suspiciously fails, try logging something - your code might indeed be executing.

##### Share on other sites

Ok got it working, it turns out I the visibility was turned off for some reason, so it wasn't calling draw. Hehe sorry.

1. 1
2. 2
3. 3
Rutin
22
4. 4
frob
17
5. 5

• 9
• 33
• 13
• 13
• 10
• ### Forum Statistics

• Total Topics
632582
• Total Posts
3007200

×