I've overloaded a function in a consequent upgradeable Solidity contract implementation. In previous implementation the function was:
function example() external { ... }
In new implementation overloaded function was added:
function example(uint _arg) external { ... }
It turns out example(uint _arg) variant is not possible to call, it's just not being executed. If example1(uint _arg) is added instead - it's possible to call.
Truffle is used in development, and OpenZeppelin libraries used for upgradeable. All works well except overloading. One of hypothesis is that the issue can be in how Truffle works. Is this true?
Related
I need to dynamically make a function that can be called by an external library using the __cdecl calling convention, and that then redirect the call to a method on a class, effectively serving as a proxy to a __thiscall calling convention.
The main idea is that this program (program1) should receive a function pointer from an external application (program2), package it into an object that can query us (program1) to know if the call to program2 should be made or not, then pass it to the library.
I have a vague idea of what a header for such class should look like
template <typename F, class C>
class this_call_wrapper
{
public:
// Creates a wrapper function that calls `operator()` on `object`
// `operator()` should take the same arguments as `F`
this_call_wrapper(const C* object);
// Deallocates memory used by this and the wrapper
~this_call_wrapper();
// Returns the pointer to the function wrapper
F* get_wrapper();
private:
C* object;
F* wrapper;
};
Are there any libraries out there that provide similar functionality? If not, how can I implement this in C++?
I found libffcall to be the most appropriate solution for these kind of problems. Constructing closures on assembly/machine code is also a valid option, but with how easy and portable it is to implement the same thing using libffcall, I don't think you'd want to mess with the former, unless you have some sort of (very restrictive) size constraint for your binaries.
This is the final solution.
I work on a project with extremely low unit test culture. We have almost zero unit testing and every API is static.
To be able to unit test some of my code I create wrappers like
class ApiWrapper {
virtual int Call(foo, bar) {
return ApiCall(foo, bar);
}
};
Now in my functions instead:
int myfunc() {
APiCall(foo, bar);
}
I do:
int myfunc(ApiWrapper* wrapper) {
wrapper->Call(foo, bar);
}
This way I am able to mock such functionality. The problem is that some colleagues complain that production code should not be affected from testability needs - nonsense I know, but reality.
Anyway, I believe that I read somewhere at some point that compilers are actually smart about replacing unused polymorphic behavior with a direct call ... or if there is no class that overrides a virtual method it becomes "normal".
I experimented, and on gcc 4.8 it does not inline or directly call the virtual method, but instead creates vt.
I tried to google, but I did not find anything about this. Is this a thing or do I misremember ... or I have to do something to explain this to the linker, an optimization flag or something?
Note that while in production this class is final, in the test environment it is not. This is exactly what the linker has to be smart about and detect it.
The C++ compiler will only replace a polymorphic call with a direct call if it knows for certain what the actual type is.
So in the following snippet, it will be optimized:
void f() {
ApiWrapper x;
x.Call(); // Can be replaced
}
But in the general case, it can't:
void f(ApiWrapper* wrapper) {
wrapper->Call(); // Cannot be replaced
}
You also added two conditions to your question:
if there is no class that overrides a virtual method it becomes "normal".
This will not help. Neither the C++ compiler nor the linker will look at the totality of classes to search whether any inheritor exists. It's futile anyway, since you can always dynamically-load an instance of a new class.
By the way, this optimization is indeed performed by some JVMs (called devirtualization) - since in Java land there's a class loader which is aware of which classes are currently loaded.
in production this class is final
That will help! Clang, for example, will convert virtual calls to non-virtual calls if the method / method's class is marked final.
I'm trying to call a member function of an external library which takes a function pointer as a parameter:
Timer::every(unsigned long period, void (*callback)(void));
But unfortunately the parameter I want to pass is a member function:
void MyClass::the_method_i_want_to_pass(void);
Since I'm programming for the ATMega under Arduino (AVR) there is just limited support of c++11. My first approach raises a type error:
void MyClass::the_method_i_want_to_pass() {...}
MyClass::MyClass() {
// constructor
Timer *timer = new Timer();
timer->every(500, [this](){this->the_method_i_want_to_pass();})
}
Compiler Output:
warning: warning: lambda expressions only available with -std=c++11 or -std=gnu++11 [enabled by default]
error: no matching function for call to ‘Timer::every(int, MyClass::MyClass()::__lambda0)’
Are there other/better solutions?
Concerning my current approach: (How) is it possible to pass a reference to a lambda when a function pointer is required?
How can I find out if Arduino/AVR supports these lambdas (see "warning")?
Your basic problem is your Timer library is poorky written: it should take void(*)(void*), void* at the least.
Without a pvoid or equivalent, you cannot pass any state other than the address in execution code to run the procedure at. As a method also rewuires a this pointer, you are out of luck.
Now, if your instance of MyClass is a singleton, you can get this from somewhere else.
Failing that, you need to make your own global state that lets you map from a particular callback to some state. If you have a limited number of MyClass and other consumers of Timer, you can have a few fixed functiins, and have them store their extra state globally.
This is all a hack. What follows is worse.
Write a dynamic library with some global state, and a void() interface. When you add a callback, duplicate that dynamic library, modify its global state at runtime, write it out as a differently named library, load it, and pass the pure callback function to your Timer class.
Or do the equvalent without a library by manually writing machine code and marking pages as execuable.
These are all poor solutions. Which leads me to a good one: find a better Timer. If they screwed up something that simple, the rest of the library is probably bad as well.
Lets say I have a bunch of free functions, within a particular namespace, which are covered by unit-tests. And lets say I see some common functionality that can be moved out into a separate free function. What can I do such that this new function becomes hidden? In other words, this function should only be used by the aforementioned free functions and not elsewhere. Should I added it to a namespace under the free functions' namespace. If so, what should I call the namespace - is there a naming convention?
I should also point out that this new function is not unit tested since it is used internally by other functions that are unit-tested. Perhaps I'm being lazy and the solution to this question is that I simply unit-test this function also and then people can use it if they want.
You can hide it: make it a private static member function of a class, and then explicitly friend each of your inline functions. The implementation could be in- or out-of-line, access control will still work.
Unless you need to restrict access though, I'd follow the Boost convention and just put it in a nested namespace called detail (or something similar).
This is just intended to document that it is an implementation detail, rather than a stable public interface (and to avoid polluting the namespace, of course).
This also avoids having to explicitly list each free function as a friend.
You could have the helper function as a static function in the private section of a class and then only friend the functions that are allowed to use it.
class Foo
{
static int helper() {return 0;}
friend void baz();
};
void baz()
{
Foo::helper(); //compiles
}
void buz()
{
Foo::helper(); //doesn't compile
}
I have a two-part program where the main core needs to have an adapter registered and then call back into the register. The parts are in separate DLLs, and the core doesn't know the adapter's specifics (besides methods and parameters ahead of time). I've tried setting it up with the following code and recieve a segfault every time the core tries to call an adapter method:
Core.hpp/cpp (combined and simplified):
class Core
{
public:
Core()
: mAdapter(NULL)
{ }
void DoStuff(int param)
{
if ( this->mAdapter )
{
this->mAdapter->Prepare(param);
}
}
void Register(Adapter * adapter)
{
this->mAdapter = adapter;
}
private:
Adapter * mAdapter;
};
Adapter.hpp/cpp (in the core library):
class Adapter
{
public:
Adapter(Core * core) { }
virtual void Prepare(int param)
{
// For testing, this is defined here
throw("Non-overridden adapter function called.");
}
};
AdapterSpecific.hpp/cpp (second library):
class Adapter_Specific
: Adapter
{
public:
Adapter_Specific(Core * core)
{
core->Register(this);
}
void Prepare(int param) { ... }
};
All classes and methods are marked as DLL export while building the first module (core) and the core is marked as export, the adapter as import while building the adapter.
The code runs fine up until the point where Core::DoStuff is called. From walking through the assembly, it appears that it resolves the function from the vftable, but the address it ends up with is an 0x0013nnnn, and my modules are in the 0x0084nnnn and above range. Visual Studio's source debugger and the intellisense shows the the entries in the vftable are the same and the appropriate one does go to a very low address (one also goes to 0xF-something, which seems equally odd).
Edit for clarity: Execution never re-enters the adapter_specific class or module. The supposed address for the call is invalid and execution gets lost there, resulting in the segfault. It's not an issue with any code in the adapter class, which is why I left that out.
I've rebuilt both libraries more than once, in debug mode. This is pure C++, nothing fancy. I'm not sure why it won't work, but I need to call back into the other class and would rather avoid using a struct of function ptrs.
Is there a way to use neat callbacks like this between modules or is it somehow impossible?
You said all your methods are declared DLL exports. Methods (member functions) do not have to be marked that way ,exporting the class is sufficient. I don't know if it's harmfull if you do.
You are using a lot of pointers. Where are their lifetimes managed?
Adapter_Specific is inheriting private from Adapter in your example
Adapter has a virtual method so probably needs a virtual destructor too
Adapter also has no default constructor so the constructor of Adapter_Specific won't compile. You might want it to construct the base class with the same parameter. This does not happen automatically. However see point 6.
Constructors that take exactly one parameter (other than the copy constructor) should normally be declared explicit.
The base class Adapter takes a parameter it does not use.
The problem ended up being a stupid mistake on my part.
In another function in the code, I was accidentally feeding a function a Core * instead of the Adapter * and didn't catch it in my read-through. Somehow the compiler didn't catch it either (it should have failed, but no implicit cast warning was given, possibly because it was a reference-counted point).
That tried to turn the Core * into an Adapter and get the vftable from that mutant object, which failed miserably and resulted in a segfault. I fixed it to be the proper type and all works fine now.
__declspec(dllexport) on classes and class members is a really bad idea. It's much better to use an interface (base class containing only virtual functions, it's essentially the same as the "struct of function pointers" you didn't want, except the compiler handles all the details), and use __declspec(dllexport) only for global functions such as factory functions. Especially don't call constructors and destructors directly across DLL boundaries because you'll get mismatched allocators, expose an ordinary function which wraps the special functions.