Hi there,
This is working but I'm a little nervous it might be pushing boundaries a bit. Have a look at the portion of the abstract class below:
Code:
class IMPORT_EXPORT D3DInterface
{
public:
....stuff omitted
virtual void Update() = 0;
....class continues
}
So a pure virtual, which is making the class abstract. This class is used as the interface between the main app and the DLL. So anything inside the DLL inherits from this class and over rides the pure virtuals. It allows the main app to ultimately make API specific function calls without knowing anything about the API itself.
Here's a shortened portion of the inheriting class:
Code:
class D3DRenderer : public D3DInterface
{
public:
....stuff omitted
void Update()override;
....more stuff omitted
void Update(const GameTimer& gt);
....class continues
So two function signatures, one an over ride, the other a typical class member function.
Here's the two functions below:
Code:
void D3DRenderer::Update()
{
Update(mTimer);
return;
}
void D3DRenderer::Update(const GameTimer& gt)
{
....function body
}
This allows the main app to call the over ridden Update() function which then delegates to the ordinary member function which takes a GameTimer object as an argument. I mean it works.... but I wonder if this will always work in the future, especially when just running it as an executable on other machines (if I ever get that far).
I assume provided something is within a defined C++ standard then I don't have to worry. It just seems a little wild to me to allow a compiler to choose between two signatures when one of them is an over ride.
I'm probably worrying about nothing, but I'd like a second opinion.
Thanks