I'm trying to translate the header of libfprint (fprint.h) to Pascal, but I find a structure that can not understand and some tools such as "C2Pas" only send error.
The structure is as follows:
struct fp_dscv_dev **fp_discover_devs(void);
Where fp_dscv_dev this only declared as follows:
/* structs that applications are not allowed to peek into */
struct fp_dscv_dev;
What would be the equivalent in Pascal?
Thanks in advance
Opague pointers are traditionally basic pointers in Pascal (like void * in c).
If you really want to the struct aspect to return define it as a record without fields:
Type
fp_dscv_dev = record end;
As said in the comments, a ** is a double reference
Since in most modern pascals references can't be in parameter and return value declarations, we define additional types for them:
pfp_dscv_dev = ^fp_dscv_dev
ppfp_dscv_dev = ^pfp_dscv_dev
Finally the declaration itself is
function fp_discover_devs:ppfp_dscv_dev; cdecl;
Related
I was writing a c library for linked lists and trees and i was looking for a solution to generalize the data type handled by these libraries without making a list/tree library for each type i need to handle.
For example, my list library has these functions:
/* list.h */
typedef int list_element; // <-- need to generalize that
struct list_node {
list_element value;
struct list_node* next;
};
typedef struct list_node list_node;
typedef struct list_node* list;
extern list list_cons(list_element d, list l)
And then my list.c:
/* list.c */
#include <list.h>
list list_cons(list_element d, list l){
list m = malloc(sizeof(list_node));
m->value = element_copy(d);
m->next = l;
return m;
}
Now suppose that in my main program i've to use a list of int and a list of double, i should create 2 couple of file, something like list_float.c/.h and list_int.c/.h
Also some list_element can be struct and need functions like copy/isLess/isEqual to compare themselves
I want to write something like this in my code:
/* main.c */
list_cons(void *data, list l);
Where data is a pointer to any type i want and inside list_cons, element_copy work for any type of data i pass (obviously i need to copy the data not the pointer to data, void* is the only idea i had to generalize the argument's type of a function)
As a general suggestion, you should not assume that list_cons would be the only way to construct a linked list. Sometimes malloc is just not available or user wants to preallocate everything in a static array or wants to use custom allocator or...
As a concrete sample, you may look at https://github.com/torvalds/linux/blob/master/include/linux/list.h.
If you want other license for your code, search for data structure implementations in xBSD Unix sources.
The general idea is that you only require a linked list structure to contain next/prev and similar fields, not limiting user to your type names. All iterations and basic operations are defined as preprocessor macros, on top of which you implement complex algorithms.
Notice that in C11 (read its standard n1570 and some C reference site) different types can be handled differently (see its §6.5.2).
In particular, the implementation can handle int, double and pointer values differently (their size and alignment is often different, see sizeof & alignof), and some ABI conventions decide that they are passed in different registers (e.g. in function calls).
So you cannot write something which handles (portably) all of int, double etc... the same way (unless you have variadic functions; with <stdarg.h>)
You might decide to implement some "generic" list whose content is some arbitrary pointer. But then you need some conventions about them (who is allocating that pointer, who is freeing it, perhaps what operations are allowed, etc...). Look into Glib doubly-linked lists for inspiration.
You could also use preprocessor techniques to generate an abstract data type (of your list) and functions implementing it, given some type name for the content. Look into SGLIB for inspiration.
You could also use some metaprogramming techniques: you'll describe somehow the type of the element, and you feed that description into your metaprogram which is some C code generator. Look into SWIG for inspiration. The generated C code would implement your list's abstract data type.
Don't forget memory management issues and describe and document clearly your conventions around them. Read about RAII.
Think also of complex cases like some list of list of strings (perhaps dynamically allocated à la strdup or obtained using asprintf). You'll discover that things are not simple, and you'll need to explicit conventions (e.g. could some string be shared between two sublists? When would that string be free-d, ...).
This might be a good place to use a union.
You can define your base datatype as a union of the most common types you want to support. Then you would define a enum of the types in question as use that value to flag what the union contains.
enum element_type {
TYPE_INT,
TYPE_DOUBLE
};
typedef union {
int e_int;
double e_double;
} list_element;
struct list_node {
enum element_type type;
list_element value;
struct list_node* next;
};
Then you add to the list like this:
list list_cons(list_element d, enum element_type type, list l){
list m = malloc(sizeof(list_node));
m->type = type;
m->value = element_copy(d);
m->next = l;
return m;
}
This is a follow-up to this question. I made an assumption there that might not be true, which is why I am explicitly asking about it. Because I forgot to ask if this is actually possible, I have already filed issue #8114 about this.
With cgo, it is possible to have Go code operate on C types, like this:
package foo
//#include <sys/stat.h>
import "C"
func fileSizeFromStat(stat *C.struct_stat) int64 {
return int64(stat.st_size)
}
Is the reverse possible? I.e. writing C functions that operate on go types? The concrete point of this is outlined in the question linked above; I want to marshall C structures that cannot be accessed from Go code, either because they use unions or bitfields or because their alignment makes them incompatible with Go code.
As far as I know, no, you can't.
But you could use something ugly like https://github.com/OneOfOne/go-nfqueue/blob/master/nfqueue.go#L130 where you export a Go function that takes a lot of pointers and construct your Go struct in go.
I wrote the following dirty hack to work around the apparent inability to access Go structures from C. While this hack is not guaranteed to work, it works for those cases were Go and C agree on how to lay out structures, which happens to be the case for all those cases I am interested in.
For each Go structure I want to access
type JewelTarget struct {
SensRes [2]byte
Id [4]byte
Baud int
}
I create a corresponding C structure which has fields of the same width and hopefully the same layout:
typedef ptrdiff_t GoInt;
struct JewelTarget {
uint8_t SensRes[2];
uint8_t Id[4];
GoInt Baud;
};
Then I write C functions that use these C structs:
extern void
marshallJewelTarget(nfc_target *nt, const struct JewelTarget *jt)
{
nfc_jewel_info *ji = &nt->nti.nji;
memcpy(ji->btSensRes, jt->SensRes, sizeof(jt->SensRes));
memcpy(ji->btId, jt->Id, sizeof(jt->Id));
nt->nm.nbr = jt->Baud;
nt->nm.nmt = NMT_JEWEL;
}
and call them as if the arguments had the corresponding Go types:
func (d *JewelTarget) Marshall() uintptr {
nt := mallocTarget()
jt := (*C.struct_JewelTarget)(unsafe.Pointer(d))
C.marshallJewelTarget(nt, jt)
return uintptr(unsafe.Pointer(nt))
}
All examples taken from my nfc bindings.
I have some code that a program generated for me, and I really do not understand why it does what it does. The language is plain C, and a struct is generated.
.h-file:
struct X_IMPL {
sint32 y;
};
struct X {
struct X_IMPL * IMPL;
};
.c-file:
#define _my_y self->IMPL->y
sint32 do_something(struct X * self)
{
return _my_y*13;
}
I do assume that _my_y now points to a variable inside the struct, and can be used to change the struct's variable. My question is, why would code be generated this way? Is there any advantage compared to just simply using the parameter's reference? When a reference is created with a define like that, do I really need that parameter at all?
It is just a matter of preferences, as you can do that in many ways, this one is not that sheer. On the first line, where the define is, it assigns nothing but define a macro for accessing a struct pointer through a struct pointer.
I think what you are seeing is "object oriented programming" in C. Note that it's not usually 1:1 equivalent to OOP in C++/Java/C#/whatever, because the OOP mechanisms are not built-in, but implemented explicitly. So different projects and different developers might write quite different code for same thing, while in some other language with built-in OOP features, they'd all just use the built-in features the same way.
The do_something in C++ might look like this:
// do_something is public member function AKA method of class X
sint32 X::do_something()
{
// y is this->y, private member variable of class X
return y * 13;
}
I have code in my header file that looks like:
typedef struct _bn bnode;
I can do
bnode b;
just fine, but
b[i], where i is an int gives me the following error:
invalid use of undefined type ‘struct _bn’
Any ideas?
As stated, b is not an array and, as such, can not be accessed as one.
Also, how do you expect the compiler to figure out the size of that structure? When you do something like bnode b[i] a certain amount of space is to be set aside for later use. As you have it there no size.
What is your opacity intended to do for you? Maybe if you explain further what you are trying to accomplish you will get a more revealing answer...
As far as an API/library goes, normally if you're going to need an opaque structure, you don't allow the user of the API to declare things like arrays or static instances because of this. Not knowing anything about the structure is the name of the game so you're probably going to have to define some functions to manipulate them. Most C libraries that declare opaque structures often has accessor and modification functions.
One example is from Lua (obviously a Lua state is an single use structure but it's the idea):
typedef struct lua_State lua_State;
void lua_pushnumber(lua_State *s, lua_Number n);
In this case, if you decided you needed multiple Lua states, you would do something like the following:
lua_State *states[5];
for(int i = 0; i < 5; i++)
states[i] = lua_open();
I think the general rule-of-thumb is that if you're working with opaque structures, you're going to be working through pointers only, which is pretty much the only way to go about it anyway.
Sounds like you either want an opaque pointer/PIMPL implementation, or you should include the appropriate header file.
Structs in C++ are almost identical to classes, so the same techniques apply.
You can't define an array of opaque structs. If you do you get an error such as:
error: array type has incomplete element type
(the specific error text will vary; the one above is from gcc 4.4.1).
But what you can do is create an array of pointers to opaque structs. This is doable as the details of the struct do not affect the size of the pointer.
typedef struct _bn bnode;
bnode *b[20];
You have to at least know the size of bnode to be able to make an array of them.
You could do, in your opaque definition of bnode:
typedef struct bnode_struct {
uint8_t opaque_bytes[1024]; /* magically just "know" how big it is. */
} bnode;
Then you can do:
bnode b[10];
and it will work.
I came across the following function signature and I wondered if this (the ellipsis, or "...") is some kind of polymorphism?
#include <fcntl.h>
int fcntl(int fd, int cmd, ... );
Thanks in advance.
It's a variable argument list.
That is a variadic function. See stdarg.h for more details.
The ... means that you can pass any number of arguments to this function, as other commenters have already mentioned. Since the optional arguments are not typed, the compiler cannot check the types and you can technically pass in any argument of any type.
So does this mean you can use this to implement some kind of polymorphic function? (I.e., a function that performs some operation based on the type of its arguments.)
No.
The reason you cannot do this, is because you cannot at runtime inspect the types of the arguments passed in. The function reading in the variable argument list is expected to already know the types of the optional arguments it is going to receive.
In case of a function that really is supposed to be able to take any number of arguments of any type (i.e., printf), the types of the arguments are passed in via the format string. This means that the caller has to specify the types it is going to pass in at every invocation, removing the benefit of polymorphic functions (that the caller doesn't have to know the types either).
Compare:
// Ideal invocation
x = multiply(number_a, number_b)
y = multiply(matrix_a, matrix_b)
// Standard C invocation
x = multiply_number(number_a, number_b)
y = multiply_matrix(matrix_a, matrix_b)
// Simulated "polymorphism" with varargs
x = multiply(T_NUMBER, number_a, number_b)
y = multiply(T_MATRIX, matrix_a, matrix_b)
You have to specify the type before the varargs function can do the right thing, so this gains you nothing.
No, that's the "ellipsis" you're seeing there, assuming you're referring to the ... part of the declaration.
Basically it says that this function takes an unknown number of arguments after the first two that are specified there.
The function has to be written in such a way that it knows what to expect, otherwise strange results will ensue.
For other functions that support this, look at the printf function and its variants.
Does C support polymorphism?
No, it doesn't.
However there are several libraries, such as Python C API, that implements a rough variant of polymorphism using structs and pointers. Beware that compiler cannot perform appropriate type checking in most cases.
The tecnhique is simple:
typedef struct {
char * (*to_string)();
} Type;
#define OBJ_HEADER Type *ob_type
typedef struct {
OBJ_HEADER;
} Object;
typedef struct {
OBJ_HEADER;
long ival;
} Integer;
typedef struct {
OBJ_HEADER;
char *name;
char *surname;
} Person;
Integer and Person get a Type object with appropriate function pointers (e.g. to functions like integer_to_string and person_to_string).
Now just declare a function accepting an Object *:
void print(Object *obj) {
printf("%s", obj->type->to_string());
}
now you can call this function with both an Integer and a Person:
Integer *i = make_int(10);
print((Object *) i);
Person *p = make_person("dfa");
print((Object *) p);
EDIT
alternatively you can declare i and p as Object *; of course make_int and make_person will allocate space for Integer and Person and do the appropriate cast:
Object *
make_integer(long i) {
Integer *ob = malloc(sizeof(Integer));
ob->ob_type = &integer_type;
ob->ival = i;
return (Object *) ob;
}
NB: I cannot compile these examples rigth now, please doublecheck them.
I came across the following function signature and I wondered if this (the ellipsis, or "...") is some kind of polymorphism?
yes, it is a primitive form of polymorphism. With only one function signature you are able to pass various structures. However the compiler cannot help you with detecting type errors.
Adding to what's been said: C supports polymorphism through other means. For example, take the standard library qsort function which sorts data of arbitrary type.
It is able to do so by means of untyped (void) pointers to the data. It also needs to know the size of the data to sort (provided via sizeof) and the logic that compares the objects' order. This is accomplished by passing a function pointer to the qsort function.
This is a prime example of runtime polymorphism.
There are other ways to implement object-oriented behaviour (in particular, virtual function calls) by managing the virtual function tables manually. This can be done by storing function pointers in structures and passing them around. Many APIs do so, e.g. the WinAPI, which even uses advanced aspects of object orientation, e.g. base class call dispatch (DefWindowProc, to simulate calling the virtual method of the base class).
I assume you are referring to the ellipsis (...)? If so this indicates that 0 or more parameters will follow. It is called varargs, defined in stdarg.h
http://msdn.microsoft.com/en-us/library/kb57fad8.aspx
printf uses this functionality. Without it you wouldn't be able to keep adding parameters to the end of the function.
C supports a crude form of Polymorphism. I.e. a type being able to appear and behave as another type. It works in a similar was as in C++ under the hood (relying on memory being aligned) but you have to help the compiler out by casting. E.g. you can define a struct:
typedef struct {
char forename[20];
char surname[20];
} Person;
And then another struct:
typedef struct {
char forename[20];
char surname[20];
float salary;
char managername[20];
} Employee;
Then
int main (int argc, int *argv)
{
Employee Ben;
setpersonname((Person *) &Ben);
}
void setpersonname(Person *person)
{
strcpy(person->forename,"Ben");
}
The above example shows Employee being used as a Person.
No, it is a function that is taking variable number of arguments.
That is not technically polymorphism. fcntl takes variable number of arguments & that is the reason for the ... similar to printf function.
C neither supports function overloading - which is a type of ad-hoc polymorphism based on compile-time types - nor multiple dispatch (ie overloading based on runtime types).
To simulate function overloading in C, you have to create multiple differently named functions. The functions' names often contain the type information, eg fputc() for characters and fputs() for strings.
Multiple dispatch can be implemented by using variadic macros. Again, it's the programmer's job to provide the type information, but this time via an extra argument, which will be evaluated at runtime - in contrast to the compile-time function name in case of the approach given above. The printf() family of functions might not be the best example for multiple dispatch, but I can't think of a better one right now.
Other approaches to multiple dispatch using pointers instead of variadic functions or wrapping values in structures to provide type annotations exist.
The printf declaration in the standard library is
int printf(const char*, ...);
Think about that.
You can write code that supports Polymorphic behavior in C, but the ... (ellipsis) is not going to be much help. That is for variable arguments to a function.
If you want polymorphic behavior you can use, unions and structures to construct a data structure that has a "type" section and variable fields depending on type. You can also include tables of function pointers in the structures. Poof! You've invented C++.
Yes C Do support the polymorphism
the Code which we write in the C++ using virtual to implement the polymorphism
if first converted to a C code by Compiler (one can find details here).
It's well known that virtual functionality in C++ is implemented using function pointers.