• arendjr@programming.dev
      link
      fedilink
      arrow-up
      7
      arrow-down
      1
      ·
      3 days ago

      Well, let’s be real: many C programs don’t want to rely on Glib, and licensing (as the other reply mentioned) is only one reason. Glib is not exactly known for high performance, and is significantly slower than the alternatives supported by the other languages I mentioned.

        • arendjr@programming.dev
          link
          fedilink
          arrow-up
          7
          arrow-down
          1
          ·
          3 days ago

          Which one should I pick then, that is both as fast as the std solutions in the other languages and as reusable for arbitrary use cases?

          Because it sounds like your initial pick made you loose the machine efficiency argument and you can’t have it both ways.

    • calcopiritus@lemmy.world
      link
      fedilink
      arrow-up
      4
      arrow-down
      2
      ·
      3 days ago

      Glib us licensed under LGPL. So unless your project is happy with that, it’s as if it didn’t exist. That’s one of the problems of having a small standard library.

      • atzanteol@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        5
        ·
        3 days ago

        It’s one of the more permissive licenses - who the hell is going to have a problem with lgpl? You can ship it with proprietary applications.

      • aubeynarf@lemmynsfw.com
        link
        fedilink
        arrow-up
        3
        ·
        3 days ago

        It’s a single counterexample. there are many, many such libraries for C and the programmer does not have to roll their own.