5 ms·

How is it more flexible exactly? I hate this idiom every time I come across it. I like to look at the header file to see the interface and important documentat

How is it more flexible exactly? I hate this idiom every time I come across it. I like to look at the header file to see the interface and important documentation, and this just obscures it. Depending on your compiler it can make debugging a huge pain as well.

micahcc 5y ago
Its a slow to compile idiom. The only reason to use it is if you expect people to download the header and plop it in. Basically its an end-run around build systems.
- flohofwoe 5y ago
  In my tests with STB-style headers written in C between a few thousand to a few tens of thousands of line of code, the compilation speed difference between including the header with disabled implementation, versus including with the implementation section removed from the file is absolutely negligible. This is because the implementation block is already skipped in the preprocessor, and never parsed by the compiler frontend. Again, this is different from typical C++ single-header-libraries (e.g. pretty much all C++ stdlib headers) where the implementation code is inlined or in template code.
veltas 5y ago
It does seem that 'modern' idioms tend to just be doing the same thing in a more obfuscated manner. Just a .c/.h pair would have been easier to add to your source.
- NavinF 5y ago
  That would be easier if the most popular build systems weren’t terrible
  - pjmlp 5y ago
    Or I don't know, people actually bothered to learn them.
    - wizzwizz4 5y ago
      Learning something doesn't stop it being terrible. One time I ran `cmake`, and forgot to run `sudo -k` beforehand. It reconfigured my system.
      - pjmlp 5y ago
        That has more to do with sudo than cmake.
        wizzwizz4 5y ago
        This might be an unpopular opinion, but compiling a program into a local directory shouldn't try to install packages globally. `make install`, I could understand doing that. I had no idea that cmake would do this, after reading quite a lot of things about cmake v.s. make and how to write various makefiles for them. I posit that the C build tools are fundamentally hard to comprehend.
        pjmlp 5y ago
        Any build tool can do whatever they feel like. Blindly trusting it will lead to the same outcome, regardless of the programming language ecosytem.
        charcircuit 5y ago
        Sure, but should it? Do you really want nasal demons from your build tool?
        pjmlp 5y ago
        Due to the success of build tools like Gradle, build.rs or any other one that packages a Turing complete language to steer a build, apparently many want such daemons on their homedir.
  - wott 5y ago
    If the library is installed separately, the terribleness is about adding "-lfunkylib" to your linker command. If you embed the source in your project, the terribleness is about adding to your Makefile: funkylib.o: funkylib.c $(CC) $< myfinalexe: ... funkylib.o ... # your existing executable creation (linking) command
- krychu 5y ago
  This is a valid point. I was on the fence between doing .c/.h pair and a single .h. But finally took the inspiration from: https://github.com/nothings/stb https://github.com/nothings/stb.
  - veltas 5y ago
    Overall I think the code in the library is good, this was just the thing that stuck out to me most. Congrats on getting shared on HN.
flohofwoe 5y ago
> I like to look at the header file to see the interface and important documentation This still works nicely: the important stuff (documentation and public interface) is at the top, followed by the 'unimportant' implementation at the botton of the file. STB-style headers are a bit different from typical C++ 'single header libraries' in that they put the declaration and implementation into separate sections in the header file (with the implementation inside an #ifdef/#endif pair), while C++ headers are usually a wild mix of class declarations intermixed with implementation code in template and inline functions (which is indeed harder to read). I don't quite understand how debugging is affected? E.g. there are (usually) no inline functions in STB-style headers.

micahcc 5y ago

Its a slow to compile idiom. The only reason to use it is if you expect people to download the header and plop it in. Basically its an end-run around build systems.

flohofwoe 5y ago
In my tests with STB-style headers written in C between a few thousand to a few tens of thousands of line of code, the compilation speed difference between including the header with disabled implementation, versus including with the implementation section removed from the file is absolutely negligible. This is because the implementation block is already skipped in the preprocessor, and never parsed by the compiler frontend. Again, this is different from typical C++ single-header-libraries (e.g. pretty much all C++ stdlib headers) where the implementation code is inlined or in template code.

veltas 5y ago

It does seem that 'modern' idioms tend to just be doing the same thing in a more obfuscated manner. Just a .c/.h pair would have been easier to add to your source.

NavinF 5y ago
That would be easier if the most popular build systems weren’t terrible
- pjmlp 5y ago
  Or I don't know, people actually bothered to learn them.
  - wizzwizz4 5y ago
    Learning something doesn't stop it being terrible. One time I ran `cmake`, and forgot to run `sudo -k` beforehand. It reconfigured my system.
    - pjmlp 5y ago
      That has more to do with sudo than cmake.
      - wizzwizz4 5y ago
        This might be an unpopular opinion, but compiling a program into a local directory shouldn't try to install packages globally. `make install`, I could understand doing that. I had no idea that cmake would do this, after reading quite a lot of things about cmake v.s. make and how to write various makefiles for them. I posit that the C build tools are fundamentally hard to comprehend.
        pjmlp 5y ago
        Any build tool can do whatever they feel like. Blindly trusting it will lead to the same outcome, regardless of the programming language ecosytem.
        charcircuit 5y ago
        Sure, but should it? Do you really want nasal demons from your build tool?
        pjmlp 5y ago
        Due to the success of build tools like Gradle, build.rs or any other one that packages a Turing complete language to steer a build, apparently many want such daemons on their homedir.
- wott 5y ago
  If the library is installed separately, the terribleness is about adding "-lfunkylib" to your linker command. If you embed the source in your project, the terribleness is about adding to your Makefile: funkylib.o: funkylib.c $(CC) $< myfinalexe: ... funkylib.o ... # your existing executable creation (linking) command
krychu 5y ago
This is a valid point. I was on the fence between doing .c/.h pair and a single .h. But finally took the inspiration from: https://github.com/nothings/stb https://github.com/nothings/stb.
- veltas 5y ago
  Overall I think the code in the library is good, this was just the thing that stuck out to me most. Congrats on getting shared on HN.

flohofwoe 5y ago

> I like to look at the header file to see the interface and important documentation This still works nicely: the important stuff (documentation and public interface) is at the top, followed by the 'unimportant' implementation at the botton of the file. STB-style headers are a bit different from typical C++ 'single header libraries' in that they put the declaration and implementation into separate sections in the header file (with the implementation inside an #ifdef/#endif pair), while C++ headers are usually a wild mix of class declarations intermixed with implementation code in template and inline functions (which is indeed harder to read). I don't quite understand how debugging is affected? E.g. there are (usually) no inline functions in STB-style headers.