-
Notifications
You must be signed in to change notification settings - Fork 12
Why not single file and header only?
I do appreciate lots of header-only libraries which made integration so simple and relaxing.
Integrating header-only libraries is so relaxing. It is a life saver on windows, because there is no such a place you could usually find dependency libraries to link. You usually have to find somewhere to place your libs, and set PATH to them, then modify the project properties accordingly. Though nowadays we have cmake to do these stuffs for you, it is still a bit complicated to config all the things right.
For *nix systems, header only libraries are still easier to use than those who need pre-compilation.
That is to say, for light-weight libraries, I have a strong preference to choose header only libraries over those who have to compile and link externally, though header only means compiling every single time which takes time. I choose portability rather than compilation time.
One more step of header-only, now you can drag-and-drop this file into your project, how hard can it be??
Main reason is for encapsulation of old c code interacting with low-level system ports.
In zupply, currently it is inevitably to write c code calling old style system dependent APIs, for example POXIS-compliant headers("<sys/...>") and "Windows.h".
If these inclusions are in header, then the global space is polluted. Naming conflicts, duplicate #define issues are out-of-control.I don't like that, so I just put the dirty part into the cpp file, users who include header file will have pure and clean environment.
Basically it is a personal choice, maybe sometime later I would include a header-only single file version. Now two files are still under-control.