4 ms·

?? You're telling me C++ devs don't use libraries?

• rapsey 6y ago
  To the degree of Rust no.
  • self_awareness 6y ago
    It's probably because of the complication of adding a library dependency in C++. If the ecosystem would use a Cargo-like management, I think C++ would have as much libraries, eagerly used, as Rust.
    • Cloudef 6y ago
      One could leverage something like Arch PKGBUILDs or nix recipes to create C/C++ "package manager". C/C++ libraries aren't really hard, all you need is "root directory" with the common {/include,/lib} layout. For C you could even have binary libraries, but for C++ binary libraries are gonna be quite a problem, because there's no ABI compatiblity and even different compiler flags can cause ABI incompatibility.
      • oblio 6y ago
        > One could One could, but no one has. That's the whole discussion, there are multiple partial implementations with limited adoption.
        • Cloudef 6y ago
          MSYS2 actually has one based on pacman and PKGBUILDs. I remember unofficial vita SDK going similar route as well. Probably there's tons of similar solutions but not marketed well enough.
          • oblio 6y ago
            The marketing part is the hard part, ideas are a dime a dozen, unfortunately. These solutions need to be almost ubiquitous to be truly useful.
      • self_awareness 6y ago
        It's easy to do on the beginning until you want to add a library that has a set of custom perl scripts to do the actual build. Then you want to add a library that compiles fine on Fedora, but fails on ArchLinux, because they've moved some header file from `/usr/include` to `/usr/include/subdir`. Then you want to add another library, but you want to statically link it, only to find out that the package manager installs a version of the library that allows only dynamic linkage. Then you want to add Windows support, and the whole thing detonates because Visual Studio uses completely different compilation switches than what you'd expect from a compiler in a unix world. Next there are 1000 other problems, including people who insist on using raw Makefiles because they think they know better. By the way, the fact that C doesn't use rich signatures is a problem, not a feature. C ABI can also be changed by using different compilation options, but the user won't even know it until the app explodes (crashes). At least C++ will emit a linker error in such case (sometimes, other times it will explode as well).
        • Cloudef 6y ago
          >Then you want to add a library that compiles fine on Fedora, but fails on ArchLinux, because they've moved some header file from `/usr/include` to `/usr/include/subdir`. This is why pkg-config exists. >Then you want to add another library, but you want to statically link it, only to find out that the package manager installs a version of the library that allows only dynamic linkage. This sounds like a problem in such "package manager" or problem in the upstream build system. >Then you want to add Windows support, and the whole thing detonates because Visual Studio uses completely different compilation switches than what you'd expect from a compiler in a unix world This is a valid point. Visual studio already has its own solution however. I personally avoid visual studio anyways, because it sucks for C. >Next there are 1000 other problems, including people who insist on using raw Makefiles because they think they know better. These aren't really problems unless you rely only on the upstream build system. PKGBUILDs, nix recipes they can do their own thing.