Olive.c: a simple graphics library that does not have any dependencies
1–10 of 96 posts
Re: Olive.c: a simple graphics library that does not have any dependencies
#2Re: Olive.c: a simple graphics library that does not have any dependencies
#3Re: Olive.c: a simple graphics library that does not have any dependencies
#4It pains me to see #include at the top of the file. It makes the project feel like a toy.
Re: Olive.c: a simple graphics library that does not have any dependencies
#5Cool project! What’s the motivation? Since it eschews any graphics API, is it safe to assume this only does CPU-based rendering?
// This idea is that you can take this code and compile it to different platforms with different rendering machanisms:
// native with SDL, WebAssembly with HTML5 canvas, etc.
The goal seems to be to maximize portability.Re: Olive.c: a simple graphics library that does not have any dependencies
#6It pains me to see #include at the top of the file. It makes the project feel like a toy.
If OLIVE_IMPLEMENTATION is defined before including "olive.c", then the full implementation is produced. Otherwise, just declarations, so that it behaves like a header file.
It's a valid technique. If you have a library all in one source file, the requirement to have a separate .h doubles your file count.
One small reason to have a .c suffix is might be that your editor can then choose a more specific syntax scheme. A .h file could be C++. Another one is that it can be used as a source file. You can pop it into a Makefile project, and just make sure you have -DOLIVE_IMPLEMENTATION on the compiler command line for that file. Other files using it just include "olive.c" to get the declarations. Because it has a .c suffix, make will handle it via its .c.o rule.
Re: Olive.c: a simple graphics library that does not have any dependencies
#7It pains me to see #include at the top of the file. It makes the project feel like a toy.
Sorry, why does it make the project feel like a toy? I'm not trying to argue, I just don't understand. Is it because you're including a source file instead of a header file?
It's possible that your linker would be smart enough to identify and remove the duplicates, but it's still inelegant, unidiomatic and needlessly inefficient.
Re: Olive.c: a simple graphics library that does not have any dependencies
#8Re: Olive.c: a simple graphics library that does not have any dependencies
#9Earlier quoted context omitted.
Sorry, why does it make the project feel like a toy? I'm not trying to argue, I just don't understand. Is it because you're including a source file instead of a header file?
The function declarations and definitions are all commingled in a single file. So if you want to use this library in a project that contains multiple source files, you have to include a duplicate copy of the implementation (including e.g. the static font data) in every single compilation unit. It's possible that your linker would be smart enough to identify and remove the duplicates, but it's still inelegant, unidiom…
Re: Olive.c: a simple graphics library that does not have any dependencies
#10Earlier quoted context omitted.
Sorry, why does it make the project feel like a toy? I'm not trying to argue, I just don't understand. Is it because you're including a source file instead of a header file?
The function declarations and definitions are all commingled in a single file. So if you want to use this library in a project that contains multiple source files, you have to include a duplicate copy of the implementation (including e.g. the static font data) in every single compilation unit. It's possible that your linker would be smart enough to identify and remove the duplicates, but it's still inelegant, unidiom…