I am writing an GL effect system in my application so i have a superclass called
cEffect - which handles loading/parsing configuration file for each effect
and other inherited classess
cFX<name> - for every effect i add ( blur, bloom, chaos,... ).
The code is simplified here but looks like this:
Class cEffect
{
public:
bool ParseString(...);
private:
int m_nStartFrame;
int m_nEndFrame;
float m_fSpeed;
};
// Blur effect
Class cFXBlur : public cEffect
{
public:
bool RenderFrame(...);
};
// Bloom effect
Class cFXBloom : public cEffect
{
public:
bool RenderFrame(...);
};
// Scene drawing effect
Class cFXScene : public cEffect
{
public:
bool RenderFrame(...);
};
// Clear the depth/color buffer
Class cFXClearBuffers : public cEffect
{
public
bool RenderFrame(...);
}
Now, the demo engine handles a
std::vector<cEffect *> m_pvEffects;
Vector that has a list of effects added.
And when an effect is added to the current time (let's say i add a blur)
i add it like:
// Blur to be added
cEffect *newEffect = new cFXBlur;
newEffect->SetStartTime(x);
newEffect->SetEndTime(y);
newEffect->SetPower(13.0f);
newEffect->SetTexture(...);
// Now add the effect to the effects list.
m_pvEffects.push_back(newEffect);
Now, when i render i iterate through m_pvEffects list - but also i would like to call
an RenderFrame method ( which is public in every CFX<name> effect).
(*it)->RenderFrame(...)
But compiler says:
error C2039: 'RenderFrame' : is not a member of 'CEffect'
I kinda understand why it happens but can't really think of a way how can i fix this,
can you guys help me out please - it seems like i lost the plot ...
Thanks for any suggestion, what can i do to add CFX to a cEffect vector and later
use -> RenderFrame method?
You should change your class cEffect to:
Class cEffect
{
public:
bool ParseString(...);
virtual bool RenderFrame(...) = 0;
private:
int m_nStartFrame;
int m_nEndFrame;
float m_fSpeed;
};
You need the keyword virtual, if you want to redefine a method in a subclass. The = 0 makes the class cEffect abstract (i.e. you cannot create an object directly of the type cEffect), therefore subclasses must implement the method RenderFrame(...)
The error occurs, because cEffect has no member function called RenderFrame. What you want is a virtual function, a fundamental concept of object oriented programming. Basically you need to add a function
virtual bool RenderFrame(...);
to your cEffect definition. The virtual keyword basically tells the compiler to resolve it at runtime. This means if you call this method on a cEffect pointer or a reference, the corresponding method of the concrete derived class this pointer or reference point to is called. In this case you should also declare the method as virtual in all derived classes (although this is not neccessary, it makes your code clearer).
If you do not want the base class method to do anything and you want to require all derived classes to override it with their own implementation, then you can make this method pure virtual in the base class, by decralring it like
virtual bool RenderFrame(...) = 0;
This basically tells the compiler, that this is an abstract method, which doesn't have a concrete implementation and is only implemented by derived classes.
This is a very simplified explanation (appologies to every expert who thinks my wordings not 100% exact). You should read some more material on object oriented programming, especially in conjunction with C++.
Related
I have a lot of native classes that accept some form of callbacks, usually a boost::signals2::slot-object.
But for simplicity, lets assume the class:
class Test
{
// set a callback that will be invoked at an unspecified time
// will be removed when Test class dies
void SetCallback(std::function<void(bool)> callback);
}
Now I have a managed class that wraps this native class, and I would like to pass a callback method to the native class.
public ref class TestWrapper
{
public:
TestWrapper()
: _native(new Test())
{
}
~TestWrapper()
{
delete _native;
}
private:
void CallbackMethod(bool value);
Test* _native;
};
now usually what I would do is the following:
Declare a method in the managed wrapper that is the callback I want.
Create a managed delegate object to this method.
Use GetFunctionPointerForDelegate to obtain a pointer to a function
Cast the pointer to the correct signature
Pass the pointer to the native class as callback.
I also keep the delegate alive since I fear it will be garbage collected and I will have a dangling function pointer (is this assumption correct?)
this looks kind of like this:
_managedDelegateMember = gcnew ManagedEventHandler(this, &TestWrapper::Callback);
System::IntPtr stubPointer = Marshal::GetFunctionPointerForDelegate(_managedDelegateMember);
UnmanagedEventHandlerFunctionPointer functionPointer = static_cast<UnmanagedEventHandlerFunctionPointer >(stubPointer.ToPointer());
_native->SetCallback(functionPointer);
I Would like to reduce the amount of code and not have to perform any casts nor declare any delegate types. I want to use a lambda expression with no delegate.
This is my new approach:
static void SetCallbackInternal(TestWrapper^ self)
{
gcroot<TestWrapper^> instance(self);
self->_native->SetCallback([instance](bool value)
{
// access managed class from within native code
instance->Value = value;
}
);
}
Declare a static method that accepts this in order to be able to use C++11 lambda.
Use gcroot to capture the managed class in the lambda and extend its lifetime for as long as the lambda is alive.
No casts, no additional delegate type nor members, minimal extra allocation.
Question:
Is this approach safe? I'm fearing I'm missing something and that this can cause a memory leak / undefined behavior in some unanticipated scenario.
EDIT:
this approach leads to a MethodAccessException when the lambda calls a private method of its managed wrapper class. seems like this method must at least be internal.
I think that you should not be using gcroot but a shared pointer. Shared pointer are made to keep an object alive as long as someone is using it.
You should also use a more c++ style in your whole code by replacing raw pointer with smart pointer and template instead of std::function (a lambda can be stored in a compile time type).
For example using the code you posted :
class Test
{
// set a callback that will be invoked at an unspecified time
// will be removed when Test class dies
template <class T>
void SetCallback(T callback); // Replaced std::function<void(bool)> with T
}
public ref class TestWrapper
{
public:
TestWrapper()
: _native()
{}
private:
void CallbackMethod(bool value);
std::unique_ptr<Test> _native; // Replaced Test* with std::unique_ptr<Test>
};
After replacing the old method with this new method all over my code base, I can report that it is safe, more succinct, and as far as I can tell, no memory leaks occur.
Hence I highly recommend this method for passing managed callbacks to native code.
The only caveats I found were the following:
Using lambda expressions forces the use of a static method as a helper for the callback registration. This is kinda hacky. It is unclear to me why the C++-CLI compiler does no permit lambda expressions within standard methods.
The method invoked by the lambda must be marked internal so to not throw MethodAccessException upon invocation. This is sort of make sense as it is not called within the class scope itself. but still, delegates / lambdas with C# don't have that limitation.
I am aware of the lack of reflection and basic template mechanics in C++ so the example below can't work. But maybe there's a hack to achieve the intended purpose in another way?
template <typename OwnerClass>
struct Template
{
OwnerClass *owner;
};
struct Base
{
virtual void funct ()
{
Template <decltype(*this)> temp;
// ...
}
};
struct Derived : public Base
{
void whatever ()
{
// supposed to infer this class and use Template<Derived>
// any chance some macro or constexpr magic could help?
funct();
}
};
In the example, Derived::whatever() calls virtual method Base::funct() and wants it to pass its own class name (Derived) to a template. The compiler complains "'owner' declared as a pointer to a reference of type 'Base &'". Not only does decltype(*this) not provide a typename but a reference, the compiler also can't know in advance that funct is called from Derived, which would require funct() to be made a template.
If funct() was a template however, each derived class needs to pass its own name with every call, which is pretty verbose and redundant.
Is there any hack to get around this limitation and make calls to funct() infer the typename of the calling class? Maybe constexpr or macros to help the compiler infer the correct type and reduce verbosity in derived classes?
You should use CRTP Pattern (Curiously Recurring Template Pattern) for inheritance.
Define a base class:
struct CBase {
virtual ~CBase() {}
virtual void function() = 0;
};
Define a prepared to CRTP class:
template<typename T>
struct CBaseCrtp : public CBase {
virtual ~CBaseCrtp() {}
void function() override {
using DerivedType = T;
//do stuff
}
};
Inherit from the CRTP one:
struct Derived : public CBaseCrtp<Derived> {
};
It should work. The only way to know the Derived type is to give it to the base!
Currently, this can't be done. Base is a Base and nothing else at the time Template <decltype(*this)> is instantiated. You are trying to mix the static type system for an inheritance hierarchy inherently not resolved before runtime. This very same mechanism is the reason for not calling virtual member functions of an object during its construction.
At some point, this limitation might change in the future. One step towards this is demonstrated in the Deducing this proposal.
I know that additional initialization methods are evil, as they leave a very nasty option for having object half-constructed and as result all methods needs to check for this. But what about this situation?
class config;
class cfg_item final
{
private:
friend class config;
cfg_item(std::weak_ptr<config> owner) : owner(owner) { }
std::weak_ptr<config> owner;
}
class config final : private std::enable_shared_from_this<config>
{
public:
config()
{
items.emplace(std::make_shared<cfg_item>(weak_from_this())); // Will crash!
}
private:
std::vector<std::shared_ptr<cfg_item>> items;
}
int main(int argc, char * argv[])
{
std::shared_ptr<config> cfg = std::make_shared<config>();
}
I KNOW WHY IT CRASHES. The std::shared_ptr in the main is not yet initialized with shared pointer to config instance, so constructor does not know how to make weak_from_this and just raises std::bad_weak_ptr exception because there are no valid std::shared_ptr pointing to this at constructor's call time.
The question is: how can I avoided the whole thing? I believe the only way I see would be to add separate initialization method, which is evil as I've already mentioned...
As note about real code: the constructors loads cfg_item from external source. It is assumed that all cfg_items are available for the entire lifetime of config. The weak pointers back to config are mandatory, as cfg_item must push all changes done to it back to config to save to external source
If you look at the answers to this question, there are strong arguments why an external initialization function is necessary. However, you rightfully write
I know that additional initialization methods are evil, as they leave a very nasty option for having object half-constructed and as result all methods needs to check for this.
it's possible to reduce this problem. Say you have a class foo, with the protocol that each time a foo object is constructed, foo::init() needs to be called. Obviously, this is a brittle class (client code will eventually omit calls to init()).
So, one way is to make the (non-copy / non-move) constructors of foo private, and create a variadic static factory method that creates objects, then calls init():
#include <utility>
class foo {
private:
foo() {}
foo(int) {}
void init() {}
public:
template<typename ...Args>
static foo create(Args &&...args) {
foo f{std::forward<Args>(args)...};
f.init();
return f;
}
};
In the following code
template<typename ...Args>
static foo create(Args &&...args) {
foo f{std::forward<Args>(args)...};
f.init();
return f;
}
note that this single method can be used for all constructors, regardless of their signature. Furthermore, since it is static, it is external to the constructor, and doesn't have the problems in your question.
You can use it as follows:
int main() {
auto f0 = foo::create();
auto f1 = foo::create(2);
// Next line doesn't compile if uncommented
// foo f2;
}
Note that it's impossible to create an object without this method, and the interface doesn't even contain init.
Assume we have next code:
class ISampleInterface
{
public:
virtual ~ISampleInterface() {} ;
virtual void Method1() = 0;
virtual void Method2() = 0;
};
class SampleClass : public ISampleInterface
{
public:
SampleClass() { };
~SampleClass() override { };
void Method1() { };
void Method2() { };
};
int main()
{
ISampleInterface *pObject = (ISampleInterface*)new SampleClass();
delete pObject;
return 0;
}
Is it better explicitly declare ~SampleClass() as override or don't care?
P.S. Please, focus on override and don't care the implementation of destructor itself. It could be defined, I just put example here in order to make my question clear.
I wouldn't do that. I also don't see any point in declaring explicitly a trivial destructor. Let the compiler do its job. You might need to introduce a virtual destructor into your class to (i) make the class polymorphic - although any function will do for that - and (ii) to assist in memory management, but that's not strictly relevant here.
Or, if you must do such a thing, consider using = default notation rather than supplying the empty body explicitly.
IMHO opinion any answer would be biased (i.e., opinion based). Generally, using the override specifier amongst many advantages has the advantage of eliminating:
inadvertent overriding : Inadvertently override a virtual function by declaring a member function that accidentally has the same name and signature as a base class’s virtual member function.
signature mismatches: Define a function in derived class that intended to override a virtual function in the base class but the two functions have different signatures.
There are even people that back up the opinion that the use of override specifier should be mandatory in future version of C++.
Now, in the particular case of a destructor, attaching the override specifier seems to me a little verbose.
And I'll try to clear my stand. A destructor is a special member function. Considering a class hierarchy, a derived class's destructor overrides by default the destructor of the base class (that for the known reasons should be declared virtual). Furthermore, you don't have the advantages mentioned earlier (i.e., there can't be either inadvertent overriding nor signature mismatch in a case of a destructor).
Thus, I wouldn't specify a destructor override.
Looks like I found at least one reason why it is better to make destructor override.
override for destructors prevents to make mistake when destructor of interface base class is not declared as virtual.
I recently started using C++/Cli for wrapping purposes.
Now I'm at a point where I've to know more about the internals.
Consider the following code:
Header file (ignoring .NET namespaces for this example):
public ref class BaseyClass
{
protected:
delegate void TestMethodDelegate(); // TestMethod delegate
BaseyClass(); // constructor
virtual void TestMethod(); // member: method
GCHandle _testMethodHandle; // member: method handle
};
CPP file (ignoring .NET namespaces for this example):
BaseyClass::BaseyClass()
{
_testMethodHandle
= GCHandle::Alloc(
gcnew TestMethodDelegate(this, &BaseyClass::TestMethod));
}
void TestMethod()
{
}
Eventually this class will be used as base class (for a DerivedClass) later and the method "TestMethod()" gets overridden and called from unmanaged code through the delegate pointer.
Now the question: Which method will be referenced by the delegate?
BaseyClass::TestMethod();
or
DerivedClass::TestMethod();
Personally I think the "BaseyClass::TestMethod()" will be referenced by the delegate because even when it's overridden, the delegate points to the (base-)address of BaseyClass. Hence a DerivedClass cannot override the "TestMethod" and use the delegate from BaseyClass.
I just want to be sure. Thanks for your comments and enlightment.
The delegate will be a reference to the derived class's TestMethod. Even though you're passing &BaseyClass::TestMethod, that's a virtual method, you're also passing this, which is the derived type, and both of those are taken into account when the delegate is created.
Other notes:
TestMethodDelegate doesn't need to be inside the class definition. The more standard way is to have the delegate outside of the class, just in the namespace. (Or use the existing built-in one, Action.)
You don't need to GCHandle::Alloc (I assume that's what you meant by Allow). Instead, declare _testMethodHandle as TestMethodDelegate^ (or Action^). In general, you shouldn't need to deal with GCHandle unless you're interfacing with unmanaged code, and this code is all managed.
Here's my test code:
public ref class BaseyClass
{
public:
BaseyClass() { this->_testMethodHandle = gcnew Action(this, &BaseyClass::TestMethod); }
virtual void TestMethod() { Debug::WriteLine("BaseyClass::TestMethod"); }
Action^ _testMethodHandle;
};
public ref class DerivedClass : BaseyClass
{
public:
virtual void TestMethod() override { Debug::WriteLine("DerivedClass::TestMethod"); }
};
int main(array<System::String ^> ^args)
{
BaseyClass^ base = gcnew DerivedClass();
base->_testMethodHandle();
return 0;
}
Output:
DerivedClass::TestMethod