Is there a way to have some kind of default constructor (like a C++ one) for C user types defined with a structure?
I already have a macro which works like a fast in
C++ is different from C in this case in the respect that it has no "classes". However, C (as many other languages) can still be used for object oriented programming. In this case, your constructor can be a function that initializes a struct. This is the same as constructors (only a different syntax). Another difference is that you have to allocate the object using malloc() (or some variant). In C++ you would simlpy use the 'new' operator.
e.g. C++ code:
class A {
public:
A() { a = 0; }
int a;
};
int main()
{
A b;
A *c = new A;
return 0;
}
equivalent C code:
struct A {
int a;
};
void init_A_types(struct A* t)
{
t->a = 0;
}
int main()
{
struct A b;
struct A *c = malloc(sizeof(struct A));
init_A_types(&b);
init_A_types(c);
return 0;
}
the function 'init_A_types' functions as a constructor would in C++.
Assuming that you want to do this in C, so your question isn't about structs in C++:
What I usually do is that I just create a function, init_whatever, that takes a pointer to the struct (or other variable), and sets it to the values I want.
If it is a global variable (which is initialized to zero) you could sort of simulate an argument-less constructor by having an "initialized" flag in it, and then let your other functions check that flag, and initialize the struct if the flag is zero. I'm not at all sure that this is a good idea, though.
And, as someone else noted, you could also do something horrible with macros...
You can write a function that returns the C struct:
struct file create_file(int i, float f) {
struct file obj = { i, f };
// other code here...
return obj;
}
If you wonder whether you can have "normal" member functions in C. Well, you can to some extent. I prefer the object-as-first-argument style. You pass a pointer to your struct as the first argument. This way, you can have several functions, defining the interface to your objects:
int file_get_integer(struct file *self) { return self->i; }
float file_get_float(struct file *self) { return self->f; }
If you write in that style, what you have at the end is an abstract data-type. I've seen guys emulating the member function call syntax used in C++ by having function pointers into their struct and then doing:
obj.get_integer(&obj);
It's used by the linux kernel for defining the interface to file system drivers. It's a style of writing that one may like, or may not like. I don't like it too much, because i keep using members of structures for data and not for emulating member functions calls to look like in popular object oriented languages.
You might want to take a look at a C++ compiler. It gives you more object oriented features than you can remember in a language having a C-like syntax in a more elegant and standard way than trying to bolt constructors and so forth onto C with libraries and macros.
If that doesn't work for you then take a look at GObject. http://en.wikipedia.org/wiki/GObject. It is an object system for C used in GTK and Gnome that pretty much cranks "objects in C" to 11.
From Wikipedia:
The GLib Object System, or GObject, is a free software library (covered by the LGPL) that provides a portable object system and transparent cross-language interoperability.
The system supports constructors, destructors, single inheritance, interfaces, virtual public and private methods and so forth. It's also much more tedious and difficult than doing the same things in C++. Have fun!
Let's talk about the complete engineering solution that was considered best practice in the olden days.
The problem with structs is that everything is public so there is no data hiding.
We can fix that.
You create two header files. One is the "public" header file used by clients of your code. It contains definitions like this:
typedef struct t_ProcessStruct *t_ProcessHandle;
extern t_ProcessHandle NewProcess();
extern void DisposeProcess(t_ProcessHandle handle);
typedef struct t_PermissionsStruct *t_PermissionsHandle;
extern t_PermissionsHandle NewPermissions();
extern void DisposePermissions(t_PermissionsHandle handle);
extern void SetProcessPermissions(t_ProcessHandle proc, t_PermissionsHandle perm);
then you create a private header file that contains definitions like this:
typedef void (*fDisposeFunction)(void *memoryBlock);
typedef struct {
fDisposeFunction _dispose;
} t_DisposableStruct;
typedef struct {
t_DisposableStruct_disposer; /* must be first */
PID _pid;
/* etc */
} t_ProcessStruct;
typedef struct {
t_DisposableStruct_disposer; /* must be first */
PERM_FLAGS _flags;
/* etc */
} t_PermissionsStruct;
and then in your implementation you can do something like this:
static void DisposeMallocBlock(void *process) { if (process) free(process); }
static void *NewMallocedDisposer(size_t size)
{
assert(size > sizeof(t_DisposableStruct);
t_DisposableStruct *disp = (t_DisposableStruct *)malloc(size);
if (disp) {
disp->_dispose = DisposeMallocBlock;
}
return disp;
}
static void DisposeUsingDisposer(t_DisposableStruct *ds)
{
assert(ds);
ds->_dispose(ds);
}
t_ProcessHandle NewProcess()
{
t_ProcessHandle proc = (t_ProcessHandle)NewMallocedDisposer(sizeof(t_ProcessStruct));
if (proc) {
proc->PID = NextPID(); /* etc */
}
return proc;
}
void DisposeProcess(t_ProcessHandle proc)
{
DisposeUsingDisposer(&(proc->_disposer));
}
What happens is that you make forward declarations for your structs in your public header files. Now your structs are opaque, which means clients can't dick with them. Then, in the full declaration, you include a destructor at the beginning of every struct which you can call generically. You can use the same malloc allocator for everyone the same dispose function and so. You make public set/get functions for the elements you want exposed.
Suddenly, your code is much more sane. You can only get structs from allocators or function that call allocators, which means you can bottleneck initialization. You build in destructors so that the object can be destroyed. And on you go. By the way, a better name than t_DisposableStruct might be t_vTableStruct, because that's what it is. You can now build virtual inheritance by having a vTableStruct which is all function pointers. You can also do things that you can't do in a pure oo language (typically), like changing select elements of the vtable on the fly.
The important point is that there is an engineering pattern for making structs safe and initializable.
No, not directly. The closest you could do is to write a function that allocated an instance and populated some of the fields.