Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Olive.c: a simple graphics library that does not have any dependencies

tsoding.org

Post reply on HN
Print view View original

11–20 of 96 posts

Re: Olive.c: a simple graphics library that does not have any dependencies

#11

Post by jandrese »

kazinator wrote: post #6
jandrese wrote: post #3

It pains me to see #include at the top of the file. It makes the project feel like a toy.

It looks like olive.c is a "single header" library. They chose a .c suffix rather than .h. 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 ha…

This feels far messier to me than just having a .h file.

Re: Olive.c: a simple graphics library that does not have any dependencies

#12

Post by worthless-trash »

jandrese wrote: post #11
kazinator wrote: post #6

Earlier quoted context omitted.

It looks like olive.c is a "single header" library. They chose a .c suffix rather than .h. 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 ha…

This feels far messier to me than just having a .h file.

Its part of the spec, and not even obscure. this is not even scratching the surface of nightmare level C.

Re: Olive.c: a simple graphics library that does not have any dependencies

#13

Post by esrauch »

jandrese wrote: post #9
teraflop wrote: post #7

Earlier quoted context omitted.

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…

gcc or clang would crash on the linking step complaining about duplicate symbols. This library is only good for a project that is built in a single .c file.

That's not true in this case: if you look at the .c file you can see it actually has no definitions by default and is a relatively normal .h file when it's included.

You can #include it in any number of files as long as exactly one has #define OLIVEC_IMPLEMENTATION.

Re: Olive.c: a simple graphics library that does not have any dependencies

#14

Post by teraflop »

bangonkeyboard wrote: post #10
teraflop wrote: post #7

Earlier quoted context omitted.

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…

Incorrect. The implementation is #define'd out of every compilation unit save one.

Ah, I missed that, but I don't think your comment is precisely correct either.

All of the function definitions are declared with OLIVECDEF, which by default is #defined as `static inline`. So if you want to only get a single copy of the implementation, you would have to choose one compilation unit that defines OLIVEC_IMPLEMENTATION, and you would have to define OLIVECDEF as something else (like the empty string) that causes the functions to be non-static.

Still kind of hacky, but not as bad as I thought.

EDIT: I just noticed that only some of the functions are marked with OLIVECDEF, so you have to do this trick if you want to reference the library in multiple compilation units, or else you would get duplicate symbols. The default behavior doesn't seem like it would ever be useful.

Re: Olive.c: a simple graphics library that does not have any dependencies

#16

Post by hactually »

teraflop wrote: post #14
bangonkeyboard wrote: post #10

Earlier quoted context omitted.

Incorrect. The implementation is #define'd out of every compilation unit save one.

Ah, I missed that, but I don't think your comment is precisely correct either. All of the function definitions are declared with OLIVECDEF, which by default is #defined as `static inline`. So if you want to only get a single copy of the implementation, you would have to choose one compilation unit that defines OLIVEC_IMPLEMENTATION, and you would have to define OLIVECDEF as something else (like the empty string) that…

All good - I struggled when I first started with C.

The macro preprocessor is like a Schrodinger's Cat of helpful and painful!

Re: Olive.c: a simple graphics library that does not have any dependencies

#17

Post by andai »

Does this use WebGL2? It doesn't run on my phone (which does support WebGL 1).

Edit: According to the JS source file it appears to be a plain 2D canvas. Now I am even more confused, those should definitely load!

https://github.com/tsoding/olive.c/blob/master/js/vc.js

Re: Olive.c: a simple graphics library that does not have any dependencies

#20

Post by kazinator »

jandrese wrote: post #11
kazinator wrote: post #6

Earlier quoted context omitted.

It looks like olive.c is a "single header" library. They chose a .c suffix rather than .h. 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 ha…

This feels far messier to me than just having a .h file.

Sure, but let's look at the larger picture. If you have one file, then that's your deliverable. You can host that file somewhere, send it as an e-mail body, drop it into a paste-bin or whatever. It is one self-contained unit.

If you have two files: .h and .c, the use scenario may be simpler. Not a lot though. And now youu have two files which have to stay together somehow, yet remain distinct. If you combine them in one body of text, you have to indicate: oh, please snip out this part as a .h file and then the rest as a .c file. In e-mail you can have it as two separate MIME attachments. You can use an archive file --- have you looked into the formats? Not so simple.

It's not hard to understand the attraction to the one file deployment, even if you don't do it yourself.

Post reply on HN