I'm building a wrapper using LuaJIT and FFI. I have a C library with a function that takes a FILE* as a parameter. In a Lua function within which I open a file using io.open(). Is there a way to cast, convert, or extract from the Lua file object to a C FILE*? This seems like it should be straightforward but I can't find a solution. Thanks in advance.
LuaJIT head will automatically convert a Lua file handle to a FILE * (well, void *).
http://www.freelists.org/post/luajit/an-admittedly-lazy-programmer-question,4
Related
I need to use a shared library (DLL) developed in C from MATLAB, and I wonder what the difference is between using the loadlibrary function, and implementing the functions from the C library in a MEX file?
The loadlibray function enables you to call functions from an existing C library through a foreign function interface. MEX file functions, in contrast, is a mechanism to write functions in C (or C++, Fortran) that can be called just as regular Matlab functions.
Now one typical use pattern is to write MEX functions that wrap existing C functions from a foreign library (and link these MEX files to the library). That requires a bit of work and care though, because you will have to write the wrapper function in C yourself. A useful starting point to is the timestwo example.
But if all you need is to call a specific function from your C library, and no intermittent transformation of input/output data is needed, the loadlibrary path is probably the easier one.
I don't know if this is possible, but having code in plain C, is it possible to call Cocoa API's from it?
Something like #include <cocoa.h>, add the corresponding library and go for it?
Thanks for the help
If you link against the Cocoa or Foundation frameworks, you can use objective-c within your C code. However, if you want to use the normal messaging syntax, you will have to change the file extension from .c to .m so that it is compiled as objective-c. If you keep the .c extension, you will only be able to use the c-style runtime calls to interact with objective-objects (i.e. objc_msgSend, objc_getClass, etc.).
Examples: Within a .m file
void cFunction() {
[[NSString alloc] init];
}
Within a .c file
void cFunction() {
void* cls = objc_getClass("NSString");
void* obj = objc_msgSend(cls, NSSelectorFromString(CFSTR("alloc")));
obj = objc_msgSend(obj, NSSelectorFromString(CFSTR("init")));
}
If you choose the second method, see the Objective-C Runtime Reference.
Objective-C is a very thin wrapper on top of C. The compiler just translates
[obj message:argument];
into a C-call
obj_msgSend(obj,#selector(message:),argument);
and that's it (where #selector(message:) is a magic encoding turning a selector (method name) into a computer-understandable-thingy.)
As such, there is not much difference between Objective-C and C from the compiler's viewpoint. For example, you can compile a pure C program with an Objective-C compiler, with exactly the same result as you would get by compiling with a C compiler.
So, the easiest way to "mix" a bit of Objective-C with C is to use .m extension so that the compiler use Objective-C.
That doesn't make your program suddenly very Objective-C-y. You can keep your program almost pure C, with the extension .m. With .m, you can add a few lines of Objective-C message calls without problems.
I am looking for a alternative for declaring the file pointer without using "FILE * pointer", so I mean without using the IO standard library function, maybe as a function.
With the library its easy but how could the function look like without the library.
Can somebody give an advice?
glibc includes a low-level file API for handling files with int file descriptors.
In fact, I think if you were to cast a FILE* to an integer in the glibc implementation, you would obtain a file descriptor usable with the low-level file API, and vise versa.
I am designing C library which does some mathematical calculations. I need to specify serialization interface to be able to save and then load some data. The question is, is it correct (from binary compatibility point of view) to use FILE* pointer in the public API of library?
Target platfoms are:
Linux x86, x86_64 with gcc >= 3.4.6
Windows x86, x86_64 >= WinXP with VS >= 2008sp1
I need to be as much binary compatible as it possible, so at the moment my variant is the following:
void SMModuleSave(SMModule* module, FILE* dest);
SMModule* SMModuleLoad(FILE* src);
So I am curious if it is correct to use FILE* or better switch to wchar*/char* ?
I don't agree with ThiefMaster: there's no benefit in going native (ie using file descriptors of type int on linux and handles of type void * on windows) when there's an equivalent portable solution.
I'd probably go with FILE * instead of opening the files by name from within the library: It might be more of a hassle for library users, but it's also more flexible as most libc implementations provide various ways for file opening (fopen(), _wfopen(), _fdopen(), fdopen(), fmemopen(),...) and you don't have to maintain seperate wide-char APIs yourself.
I'd use neither but let the user pass a file descriptor as an int.
Then you can fdopen() it in your code to get a FILE*.
However, when using windows it might not be the best solution even though it does have some helper functions to get a numeric file descriptor.
However, passing a FILE* or a const char* should be fine, too. I'd prefer passing a filename as it's less code to write if a library takes care of opening/closing a file.
Yes it is correct, from a stable binary interface perspective, to use FILE * here. I think perhaps you're confusing this with using FILE as opposed to a pointer to it. Notice that your standard library's fopen, fgets, etc. functions all use (both as arguments and return values) the FILE * type as part of their public interfaces.
A FILE * is a standard ANSI/ISO C89 and C99 (even K&R) type. It is a portability dream and I'd prefer it over anything else. You're safe to go with it. It won't get any better than that.
i am working on C source to translate to delphi but i was stuck on reading files on ftell() function, can you help me find the equivalent function in delphi?
If you have an object of type File, then you may use the FilePos() function, described here.