Basically, I have an already compiled a file that is written assembly; .obj file. It has an exported function f. In C++, I wrote a class and want to use the exported function f as a member function.
If it were to be used as a global function, I know that one just writesextern "C" f(). However, this doesn't work with a member function, at least I didn't figure out how to do it.
So, how do I do it?
Note: The function f is written properly. i.e. it takes into account the this pointer, etc. It should work correctly at assembly level.
If the function is written as a free function, you will have to declare it as a free function the way you're accustomed to. Just as you can't build a library with void foo() and then somehow declare it as void bar() and expect it to work, you can't take a free function and turn it into a member function. What you can do, though, is add an inline forwarder into your class like so:
struct S;
extern "C" void f( S * );
struct S {
void f() {
using ::f;
f(this);
}
};
That's the best you can do, as far as I'm aware.
Related
I have a DLL in pure C code. I would like to find a way to remove the library name prefix from the functions, classes, and structs; EX:
// lib.h
void foobar();
// lib.hpp
namespace foo {
bar();
}
I would like to avoid simply writing a wrapper for every function, since I'd have to write it for every time I want to add a function. Is there a better / more efficient way of writing this?
I started writing the wrapper idea, but there's a lot of functions to write this for. Void pointers worked a little better, but still had the same issue.
Unless you are worried about name conflicts between existing C++ function names and the C library, how about just using extern "C" (in your C++ code) and call it (from your C or C++ code). For example:
extern "C" void f(int); // apply to a single function
extern "C" { // or apply to a block of functions
int g(double);
double h(void);
};
void code(int i, double d)
{
f(i);
int ii = g(d);
double dd = h();
// ...
}
When code is enclosed within an extern “C” block, the C++ compiler ensures that the function names are un-mangled – that the compiler emits a binary file with their names unchanged, as a C compiler would do.
This approach is commonly used to accommodate inter language linkage between C++ and C.
from this Reference
more from cppprefference.com
You could try this:
// lib.hpp
namespace foo {
constexpr auto bar = foobar;
}
This should create a function pointer, and because it is constexpr, it should get resolved at compile time, so no performance hit. Also, constexpr is implicitly inline, so that (or static) can be omitted from this definition.
If we do not mention the function prototype,call the function from the main and write the definition after main it gives an error.If we write the function definition before main and do not write the prototype the program works fine. So my question is if we write the function definition before main(without writing the prototype) does it solve the problem of not declaring a function prototype(i.e, the compiler will start reading from top-down and will still be able to know about the function name,return type,parameters and etc)
Defining the function with no prior prototype is semantically equivalent to declaring the prototype immediately before defining the function. So yes, it's safe: defining a function without a prototype, before any uses of the function, will work just fine.
Compiler goes at function definition when you make a call to that function. While function prototype is consulted for arguments and return type checking. So, you can safely emit function prototype in your case...
Yes (for C++), compiler will accept this. To call a function compiler must see its prototype or definition before. Also translation units (cpp) files are compiled from top to bottom, so:
void foo();
void foo2() {
}
int main() {
foo();
foo2();
}
void foo() {
}
are both correct. If you would provide foo() prototype without defining foo below main(), compiler will still accept your code, but linker would complain with error.
Let us say I have a function in my program and somewhere in my code, that function is called through a function pointer. What happens if the compiler happened to inline that function, or would the compiler realize that there is a function pointer assigned to that function and therefore avoid inlining it.
When a pointer to a function is taken, the compiler will generate an out-of-line body for the function. It is still possible to inline the function at other call sites.
Note that a function marked inline must have a definition available in all TUs which refer to it, and these definitions must be identical. Which means it's perfectly safe to inline the function at some call sites and keep it out-of-line at others.
Well, it will surely work. I don't see how inlining would prevent that. You just have some code that calls the function directly, and it might be inlined there, and you have some code which calls it through a function pointer, just as a regular function.
There's no reason that using a function pointer should prevent inlining. Inlining is done on a case-by-case basis and can exist alongside a usual function body. So a function can be inlined in one place, and called in another.
The compiler will, therefore, inline where it can and still produce a callable function for your function pointer.
Not only does the compiler inline "other calls of the function", but it may even inline calls through function pointers if it understands enough about which function is actually being used, something like this:
typedef void (*funcptr)();
void somefunc()
{
... do stuff here ...
}
void indirection(funcptr *f)
{
f();
}
void call_with_ptr()
{
funcptr f = somefunc();
for(int i = 0; i < 100; i++)
{
indirection(f);
}
}
I had code similar to this, and it inlined the indirection, and made the call to somefunc() a direct call without using the function pointer.
But of course, this assumes the compiler can figure out which function is called from the code - which is obvious in this case, but if there is runtime decisions involved, it may not do so.
this is the cpp of a Time function. The code is defining functions of a time.h file on this time.cpp. My question is: How come this function definition is possible if the functions inside this fct are defined afterwards? Thank you
void Time::setTime(int hour, int minute, int second)
{
sethour(hour);
setminute(minute);
setseconds(seconds);
}
void Time::sethour( int h)
{ ....
You don't need a definition to call a function, you only need a declaration. The compiler is happy with the declaration alone. The linker requires code to be generated, and it requires the definition, but it doesn't matter when you define them, as long as you do.
In your case, the declaration of every member function is visible to all other member function, even if inside the class definition it came afterwards:
class Time
{
void setTime(); //setTime knows about sethour even if it's before
void sethour();
};
Outside of a class, this doesn't hold, meaning you need a declaration before using a method. The declaration is just the prototype:
void foo();
void goo()
{
foo(); //can call foo here even if it's just declared and not defined
}
Presumably because they were declared somewhere above (e.g. in the header file), and that's what's important.
It's best to imagine that the compiler operates in a "one-pass" approach; it processes your code linearly from top-to-bottom. Therefore, it needs to know that functions exist (i.e. their name, arguments and return type) before they are used, in order to establish that the caller is not doing something invalid. But the actual function definition (i.e. its body) is not relevant for this task.
You can choose when to define them.
Suppose I have a function defined like this:
class Foo() {
public:
void bar(MyClass* p, int i, int j, CArray<CArray<int,int>,int> &a);
}
void Foo::bar(MyClass* p, int i, int j, CArray<CArray<int,int>,int> &a){
// Function body
}
For a Win32 application/DLL, that this function is not "exported" how can I be able to find the function address of bar, getting the function address of exported function was easy. However getting the function address of non-exported function is a bit hard.
It is not possible to do this in the general case.
Among other problems, if the function is not exported, then it may not exist. The optimizer may inline the function at every location where the function is called. If this occurs, the function won't have an address because it won't exist in the module.
if the functions are in the .dll, you can probably export them using a .def file. It creates an export table after the fact from compiled code as if dllexport had been defined.
Read about it here: http://msdn.microsoft.com/en-us/library/d91k01sh(v=vs.80).aspx