6 ms·

Let's say you need zip lib functionality in your project. If it will be available as set of .h files you would include it by one line `#include zip.h` in your

Let's say you need zip lib functionality in your project. If it will be available as set of .h files you would include it by one line `#include zip.h` in your .c file. But libzip is made of .c files. How you would include it in your multiplatform project ? Visual Studio, XCode, etc... In general it would be great if C has `#include source "some.c"` feature. So you would add single file zip-lib.c that will contain `#include source ...` references to all needed .c files. But C/C++ has no modules as other languages so we need palliatives like make files, etc.

badsectoracula 9y ago
I am not comparing many-c-files (like your libzip example) with single header, i am comparing the single header with a pair of c/h files.
pjmlp 9y ago
Easy, one links to the binary library. It really feels strange that young devs find it so hard to use a linker.
- yoklov 9y ago
  It feels strange that you're unfamiliar with the headaches that brings for cross platform projects.
  - pjmlp 9y ago
    Those headers have code that most likely require linking with other libraries, many of each are not available in source code that one can dump into an header file. So it appears like a little convenience just for not having to deal with installing binary libraries, at the expense of wasting everyone's time. The time I waste installing a binary library? Once per platform for the longevity of the project. The time I waste building software with header only library? Every single time I do make all.
    - merlish 9y ago
      The point of single-file header libraries is that generally they are relatively small, and do not rely on linking with other libraries (outside the C runtime).
      - pjmlp 9y ago
        That might be the point, but it doesn't mirror many use cases.
    - ocornut 9y ago
      Dealing with pre-compiled libs in the Visual Studio ecosystem is more complicated that you make it sound like. For a start there are 4 incompatible standard libraries (dll vs static, debug vs optimized) and that's already a big headache. Also to a mix, a bunch of Visual Studio versions with enough difference to make it frequent that one compiled for e.g. 2010 doesn't work with 2015 or vice-versa. To me the nature of those small libraries (regardless of the number of source files) is that they are highly portable and designed to always be compiled from source code to prevent those issues.

badsectoracula 9y ago

I am not comparing many-c-files (like your libzip example) with single header, i am comparing the single header with a pair of c/h files.

pjmlp 9y ago

Easy, one links to the binary library. It really feels strange that young devs find it so hard to use a linker.

yoklov 9y ago
It feels strange that you're unfamiliar with the headaches that brings for cross platform projects.
- pjmlp 9y ago
  Those headers have code that most likely require linking with other libraries, many of each are not available in source code that one can dump into an header file. So it appears like a little convenience just for not having to deal with installing binary libraries, at the expense of wasting everyone's time. The time I waste installing a binary library? Once per platform for the longevity of the project. The time I waste building software with header only library? Every single time I do make all.
  - merlish 9y ago
    The point of single-file header libraries is that generally they are relatively small, and do not rely on linking with other libraries (outside the C runtime).
    - pjmlp 9y ago
      That might be the point, but it doesn't mirror many use cases.
  - ocornut 9y ago
    Dealing with pre-compiled libs in the Visual Studio ecosystem is more complicated that you make it sound like. For a start there are 4 incompatible standard libraries (dll vs static, debug vs optimized) and that's already a big headache. Also to a mix, a bunch of Visual Studio versions with enough difference to make it frequent that one compiled for e.g. 2010 doesn't work with 2015 or vice-versa. To me the nature of those small libraries (regardless of the number of source files) is that they are highly portable and designed to always be compiled from source code to prevent those issues.