3 ms·
For the lazy, a link to the latest release - https://github.com/liblfds/liblfds/tree/master/liblfds/liblfds7.1.0/liblfds710 https://github.com/liblfds/liblfds/t
by huhtenberg 10y ago
For the lazy, a link to the latest release - https://github.com/liblfds/liblfds/tree/master/liblfds/liblfds7.1.0/liblfds710 https://github.com/liblfds/liblfds/tree/master/liblfds/liblf...
PS. Code has quite a bit of that macro-heavy OpenSSL vibe to it. Definitely not everyone's thing, but it is very readable - https://github.com/liblfds/liblfds/blob/master/liblfds/liblfds7.1.0/liblfds710/src/lfds710_freelist/lfds710_freelist_push.c https://github.com/liblfds/liblfds/blob/master/liblfds/liblf...
- liblfds 10y agoMacros are heavily used to avoid making function calls. I'd glad you find it readable - I hope you're right :-)
- pantalaimon 10y agoBut wouldn't a static inline achieve the same thing while keeping type-safety?
- liblfds 10y agoYes. As I understand it, this requires either that every to-be-inlined function is present in the public header file, so it can be #included into every user source file which wishes to use those functions, so they turn up in the object file and so can be inlined, or we rely on the compiler and linker to inline across object files, which is not commonly supported. It depends upon the compiler having inlining support - the library is targetting arbitrary compilers on bare metal platforms, so it's not necessarily a valid assumption. Currently, there stil remain two uses of inlining, and I am aiming to get rid of them too in the next release. This also removes a macro from the porting layer, making it simpler.