4 ms·

Thank you for sharing. The only thing I don't understand why this is a header only implementation with a macro that goes in a C++ file. #define CANVAS_ITY_

Thank you for sharing. The only thing I don't understand why this is a header only implementation with a macro that goes in a C++ file. #define CANVAS_ITY_IMPLEMENTATION

socalgal2 8mo ago
that's a common pattern in C++ land because there is no standard way to use libraries in C++ https://github.com/p-ranav/awesome-hpp https://github.com/p-ranav/awesome-hpp
- pjmlp 8mo ago
  It is a common pattern among those that don't want to learn build systems, which isn't exactly the same.
  - capisce 8mo ago
    Or among those who want to support any build system
    - pjmlp 8mo ago
      We managed during the last 20 years just fine.
  - socalgal2 8mo ago
    In my experience. I've run into the issue quite often. You find some library, it has its own build system (meaning not the one you're using). It has special rules etc... Integrating into your build system is time consuming and frustrating. Compiler errors from includes, linker errors, etc.. None of that happens with a single file C++ library.
    - pjmlp 8mo ago
      Yeah, and? There isn't a single build system without issues, other than siloed languages without language standards. Header libraries only started to be a thing when scripting generation educated in Python and Ruby during the 2010's turned into compiled languages.
      - tw061023 8mo ago
        That's... definitely a way to describe Sean Barrett, whose excellent libraries popularized this style.
  - chris37879 8mo ago
    And what build system do you recommend the entire ecosystem support? Well, I choose (arbitrarily different and incompatible one to prove a point). Do you see the problem?
    - pjmlp 8mo ago
      I see a learning problem, because there is hardly a programming language in widespread use using a single one. And if you're going to point out Go or Rust, it kind of works as long, nothing else is used, and they don't need to interact with platform SDKs.
  - CyberDildonics 8mo ago
    Everything is easier with single file headers. This idea that a build system and single header libraries are mutually exclusive is silly. You can take multiple single file libraries and put them into one compilation unit. Then you have minimal files and minimal compilation units. Compilation is faster, everything is simpler.
    - pjmlp 8mo ago
      What is silly is pretending everything is a scripting language.
      - CyberDildonics 8mo ago
        I don't know what that is supposed to mean and I don't think it means anything. I'm talking about real pragmatic benefits and you're making some vague hand wavy judgement without any tangible explanation.
  - on_the_train 8mo ago
    I wrote a mildly popular header only library with exactly this pattern once. Then there came a guy adding cmake. I didn't really know it back then so I didn't stop him. The downloads went to literally zero lol. Cmake is an extremely vocal minority.
    - pjmlp 8mo ago
      Who said anything about cmake specifically?
erwincoumans 8mo ago
It is common for header-only libraries: you need to include this header in one c++ using the macro for linking (don't use that macro in other c++ files to avoid duplicate symbols). In C++, you can declare a function as many times as you want, but you can only define it (write the actual body) once in the entire project.
- ddtaylor 8mo ago
  I understand that part, but I don't see why do this instead of basic Makefile or CMake setup. It seems like more work than a regular linker at that point. For what purpose?
  - elteto 8mo ago
    Because not everyone is using Makefiles or CMake. A true header-only library should be build-system agnostic and this is one way to do that. We can argue about build systems for C++ all day long and never come to an agreement. With this approach this piece of code can be used anywhere.
    - pjmlp 8mo ago
      We can also argue C++ is not a scripting language, which is what is approach is all about. When C and C++ were the main programming languages during the 1990's, and commercial compilers abounded strangely we could manage handling all those build systems approaches.
      - elteto 8mo ago
        I think you are romanticizing the past. I’m pretty sure integration of third party C or C++ code sucked as much back then if not more. You just didn’t have as much of those dependencies because open source was in its infancy and the number of available libraries was much smaller too.

Thank you for sharing. The only thing I don't understand why this is a header only implementation with a macro that goes in a C++ file. #define CANVAS_ITY_IMPLEMENTATION

socalgal2 8mo ago

that's a common pattern in C++ land because there is no standard way to use libraries in C++ https://github.com/p-ranav/awesome-hpp https://github.com/p-ranav/awesome-hpp

pjmlp 8mo ago
It is a common pattern among those that don't want to learn build systems, which isn't exactly the same.
- capisce 8mo ago
  Or among those who want to support any build system
  - pjmlp 8mo ago
    We managed during the last 20 years just fine.
- socalgal2 8mo ago
  In my experience. I've run into the issue quite often. You find some library, it has its own build system (meaning not the one you're using). It has special rules etc... Integrating into your build system is time consuming and frustrating. Compiler errors from includes, linker errors, etc.. None of that happens with a single file C++ library.
  - pjmlp 8mo ago
    Yeah, and? There isn't a single build system without issues, other than siloed languages without language standards. Header libraries only started to be a thing when scripting generation educated in Python and Ruby during the 2010's turned into compiled languages.
    - tw061023 8mo ago
      That's... definitely a way to describe Sean Barrett, whose excellent libraries popularized this style.
- chris37879 8mo ago
  And what build system do you recommend the entire ecosystem support? Well, I choose (arbitrarily different and incompatible one to prove a point). Do you see the problem?
  - pjmlp 8mo ago
    I see a learning problem, because there is hardly a programming language in widespread use using a single one. And if you're going to point out Go or Rust, it kind of works as long, nothing else is used, and they don't need to interact with platform SDKs.
- CyberDildonics 8mo ago
  Everything is easier with single file headers. This idea that a build system and single header libraries are mutually exclusive is silly. You can take multiple single file libraries and put them into one compilation unit. Then you have minimal files and minimal compilation units. Compilation is faster, everything is simpler.
  - pjmlp 8mo ago
    What is silly is pretending everything is a scripting language.
    - CyberDildonics 8mo ago
      I don't know what that is supposed to mean and I don't think it means anything. I'm talking about real pragmatic benefits and you're making some vague hand wavy judgement without any tangible explanation.
- on_the_train 8mo ago
  I wrote a mildly popular header only library with exactly this pattern once. Then there came a guy adding cmake. I didn't really know it back then so I didn't stop him. The downloads went to literally zero lol. Cmake is an extremely vocal minority.
  - pjmlp 8mo ago
    Who said anything about cmake specifically?

erwincoumans 8mo ago

It is common for header-only libraries: you need to include this header in one c++ using the macro for linking (don't use that macro in other c++ files to avoid duplicate symbols). In C++, you can declare a function as many times as you want, but you can only define it (write the actual body) once in the entire project.

ddtaylor 8mo ago
I understand that part, but I don't see why do this instead of basic Makefile or CMake setup. It seems like more work than a regular linker at that point. For what purpose?
- elteto 8mo ago
  Because not everyone is using Makefiles or CMake. A true header-only library should be build-system agnostic and this is one way to do that. We can argue about build systems for C++ all day long and never come to an agreement. With this approach this piece of code can be used anywhere.
  - pjmlp 8mo ago
    We can also argue C++ is not a scripting language, which is what is approach is all about. When C and C++ were the main programming languages during the 1990's, and commercial compilers abounded strangely we could manage handling all those build systems approaches.
    - elteto 8mo ago
      I think you are romanticizing the past. I’m pretty sure integration of third party C or C++ code sucked as much back then if not more. You just didn’t have as much of those dependencies because open source was in its infancy and the number of available libraries was much smaller too.