I tried using boost optional and it works nice, but I cant find a way to call the member functions of the wrapped type. Is that by design or? I guess so because calling member funcs of unitialized boost::optional variable would be bad, but I want to be 100% sure.
class test
{
int test_method()
{
return 1984;
}
};
test tst;
boost::optional<test> get_test()
{
boost::optional<test> result(tst);
return result;
}
// main
boost::optional <test> ret_val= get_test();
int x=ret_val.test_method();
‘class boost::optional ANGLE_BRACKET test ANGLE_BRACKET ’ has no member named ‘test_method’
Try using ret_val->test_method() instead; operator-> can access the contained object in a boost::optional. Note that you need to ensure that the optional is not empty before you do that.
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 have a enum, SDKEnum which I need to convert into a AppEnum. I need to convert it, since my project shall be a wrapper around a .NET SDK and I cannot publish internal enums of that SDK. So I need to write my "own".
Now, for every enum I have I need a method that does the following:
AppEnum GetAppEnum (SDKEnum type)
{
switch (type)
{
// Return the correct constant, since AppEnum and SDKEnum have equal constants
}
}
That way I put a SDK enum into that method and get the corresponding App enum back.
I dont want to write that method for each enum I have.. . Is there a more generic or better way of doing this?
I'm pretty new to C++/CLI / C++ coming from C#.
Thanks a lot!
I don't know how these enums are defined, but most likely they are either (old) C-style enums or (since C++11) strongly-typed enum classes.
The following code compiles, thus static_cast is your friend here:
namespace
{
enum OLD_ENUM1 { A=1,B=2};
enum OLD_ENUM2 { C=1,D=2};
enum class NEW_ENUM1 { A=1,B=2};
enum class NEW_ENUM2 { A=1,B=2};
}
int main()
{
OLD_ENUM1 o1(A);
OLD_ENUM2 o2(static_cast<OLD_ENUM2>(o1));
NEW_ENUM1 n1(NEW_ENUM1::A);
NEW_ENUM2 n2(static_cast<NEW_ENUM2>(n1));
return EXIT_SUCCESS;
}
Note that for OLD_ENUM1 and OLD_ENUM2, I cannot use the same names for the enumeration values, since they are addressed without namespace. For the strongly-typed enums, I can do that because since they are classes, they have their own namespaces.
Alright, so what did the trick was the following regular cast:
enum SDKEnum
{
One, // (2)
Two, // (1)
Three // (0)
}
enum AppEnum
{
One,
Two,
Three
}
AppEnum MethoThatNeededTheConversion(SDKEnum sdkenum)
{
// DoStuff
return static_cast<AppEnum>(sdkenum); // Wrong int values returned
}
Important to note for me was:
The SDKEnum had other integer values for the constants then my AppEnum. So I created a test application and gave out those integer values so I can sync both enums and use regular cast.
Thanks for the help #all
Can someone show me an example of where this syntax would show up in code?
thing.Foo().Bar(this)
From the looks of it, I see an object that calls a function that calls another function?
I obviously don't know how it works. If you have the slightest idea, I would appreciate a suggestion. Thanks!
This is one of many possible scenarios:
struct somethingelse
{
void SomeOtherMethod()
{
thing.Foo().Bar(this);
}
};
struct foo
{
void Bar(somethingelse *pSomethingElse);
};
struct thing
{
foo &Foo() {return m_foo;}
foo m_foo;
};
What makes this a bit unusual is that the naming convention for the class and method naming is the opposite of the de-facto one in which classes are capitalised and methods camel-cased.
This code could be found in any non-static member function of a class. The Foo() function of thing returns an object of a class with a member function Bar that takes a pointer to the current object (this) as argument.
Sorry about the title, I couldn't come with a better one.
Suppose that I have a class with special delete semantics, which needs to call a function instead of been deleted by delete, let's call it releaseable_object:
struct releaseable_object
{
releaseable_object() : dummy_ptr(new int) {}
void Release()
{
std::cout << "Releasing releaseable object\n";
delete dummy_ptr;
}
int *const dummy_ptr;
};
And this releaseable_object is the base class of a bunch of other objects, each of them constructed by a factory which only returns pointers.
I'm trying to wrap each class into a std::unique_ptr with a custom deleter which call the releaseable_object::Release() function, so I've created a helper struct to handle some of the generic stuff:
// std::is_base_of<releaseable_object, T>::value must be true
template <typename T> struct Managed
{
using type = T;
static void deleter(type *object)
{
std::cout << "Release!\n";
object->Release();
};
using pointer = std::unique_ptr<T, decltype(deleter)>;
};
And then, a bunch of derived classes which does all the specific initializations and calls to te factory:
struct ManagedA : Managed<A>
{
using base = Managed<A>;
using base::pointer;
using base::deleter;
ManagedA(/* lots of parameters */) :
m_pointer(nullptr, deleter)
{
// do A specific stuff...
A *a = factory::CreateA(/* lots of parameters */);
// more A specific stuff...
// wrap the pointer:
m_pointer.reset(a);
}
pointer m_pointer;
};
If I try to compile the code above, it complains about the unique_ptr (demo here), I don't know what I'm doing wrong there, the error is about the instantiation of a tuple (the complete error log is in the ideone demo):
tuple: In instantiation of ‘struct std::_Head_base<1u, void(A*), false>’:
tuple:229:12: recursively required from ‘struct std::_Tuple_impl<1u, void(A*)>’
tuple:229:12: required from ‘struct std::_Tuple_impl<0u, A*, void(A*)>’
tuple:521:11: required from ‘class std::tuple<A*, void(A*)>’
bits/unique_ptr.h:127:57: required from ‘class std::unique_ptr<A, void(A*)>’
If I get rid of the m_pointer member then the compilation succeeds. I'm pretty lost with this, I'll be grateful of any hints about how to fix the compilation error.
Thanks for your attention.
The problem is that decltype(deleter) is a function type instead of a pointer-to-function type. Changing the pointer declaration to
using pointer = std::unique_ptr<T, decltype(deleter)*>; // or spell out void(*)(T*)
will fix it.
Be aware that a function object type is usually preferable to a function pointer type for a unique pointer deleter, since the function pointer must be stored in the object itself. i.e.,
sizeof(std::unique_ptr<foo*,void(*)(foo*)>) == sizeof(foo*) + sizeof(void(*)(foo*))
but most implementations will take advantage of the Empty Base Optimization if you use an empty deleter type:
struct deleter_type {
void operator () (foo*) {
// ...
}
};
sizeof(std::unique_ptr<foo*,deleter_type>) == sizeof(foo*)
Here's how your sample code would be written using a deleter type..