 |
lua-l archive |
|
|
||
|
The annoying problem though, is that LuaJIT+FFI, however great (and it is great!), isn't really a portable solution. Maybe some people don't care, but I do. I want to gain the benefits when possible, but still have the _ability_ to run with normal Lua (which is portable).
I gave up on trying to wrap "struct dirent", as I simply can't even be sure how many variants are there (OSX has it one way, Linux another, cygwin third way, and not sure about mingw).
It's still portable in "C" because macro-processor is still available, but somehow I would rather find better API's that are consistent across platforms at price of some memory overusage, for example:
Apache APR's apr_finfo_t http://apr.apache.org/docs/apr/trunk/structapr__finfo__t.html Seems like it's the same structure everywhere.Few years ago in the company, we had a video library that was using the graphics library. Somehow our coders agreed to have a specific field in external structure available only for DEBUG builds. I was against that, but the "mode" back then was memory saving (PS2, Xbox1, etc) - what this prevented me from doing was mixing debug and release libs - not something you would do normally - but I've mostly used the lib I was working in debug, and the rest in release - thus speeding up my development cycle, while still maintaining good frame rate (as the game was unplayable in debug.... due... to... ahem C++ templaaaaaars!)