3 ms·

C relies vastly on dynamic linking. C++ cannot dynamically link templates, so it's pretty common for a C++ library to be made entirely of header files. Also, t

C relies vastly on dynamic linking. C++ cannot dynamically link templates, so it's pretty common for a C++ library to be made entirely of header files. Also, that's really only true of a small number of Linux and BSD flavors. Applications shipped on Windows, macOS, Android, iOS, or any of the Linux "application bundle" systems like the Steam runtime, Docker, FlatPak, will deliberately avoid using globally-specified dependencies. It's also commonplace to avoid declaring dependencies in C by vendoring them, like how VLC basically includes its own implementation of a bunch of data structures [1], and the entire universe of single-file libraries [2]. [1]: https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-deeper https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-... [2]: https://github.com/nothings/stb/blob/master/docs/stb_howto.txt https://github.com/nothings/stb/blob/master/docs/stb_howto.t...

ziml77 5y ago
That first link is a good analysis of the situation when it comes to dependencies. It's really not straightforward unless you are targeting a specific OS distribution.
oytis 5y ago
C++ ABI is PITA indeed, but exposing a C API for external linking is totally possible and is being actively used. Various cases of static linking (or header-only files) do indeed exist, but no sane C++ project (I'm not sure one can call ROS that without reservations) uses nearly as many static dependencies as typical Rust one does. > Also, that's really only true of a small number of Linux and BSD flavors. This is true on all major Linux distributions. > Applications shipped on Windows, macOS, Android, iOS If we are talking about security closed-source walled gardens are out of consideration right? > or any of the Linux "application bundle" systems like the Steam runtime, Docker, FlatPak This is sad indeed. Docker used right is just a distro inside a distro though, so anything that applies to distros applies here too.
- jcelerier 5y ago
  > If we are talking about security closed-source walled gardens are out of consideration right? yes, because there are no open-source apps on Windows and macOS of course...
- notriddle 5y ago
  > This is true on all major Linux distributions. Except Android, ChromeOS, and other Linux systems that get deployed as immutable images (stuff like Buildroot). Except servers, that’s almost all of the world’s Linux installs.
  - oytis 5y ago
    > Except Android, ChromeOS Well, yes, these are proprietary walled gardens only using Linux as a kernel. > stuff like Buildroot Embedded Linux is special indeed. Core OE layers are well-maintained IMO, but as you use community ones the maintenance quality can vary. You have to take care of OTA of course which is a problem with no standardized solution so far, but the same applies if you develop in Rust for these platforms. But yeah, with embedded Linux you have to take responsibility for your whole system, so not much difference with Rust here (except at least if you have several apps having the same dependency you can be sure they'll use the same version of it). > Except servers, that’s almost all of the world’s Linux installs What do you mean? Most servers I've worked with would run one of the popular distributions, probably hardened and stripped of GUI stuff.
    - notriddle 5y ago
      > What do you mean? What I mean is that the situation you describe, with C libraries deployed in distro package managers, is a reality only on servers and extremely niche desktop platforms. Most of the world of software, even in the C programming language, does not work that way.

ziml77 5y ago

That first link is a good analysis of the situation when it comes to dependencies. It's really not straightforward unless you are targeting a specific OS distribution.

oytis 5y ago

C++ ABI is PITA indeed, but exposing a C API for external linking is totally possible and is being actively used. Various cases of static linking (or header-only files) do indeed exist, but no sane C++ project (I'm not sure one can call ROS that without reservations) uses nearly as many static dependencies as typical Rust one does. > Also, that's really only true of a small number of Linux and BSD flavors. This is true on all major Linux distributions. > Applications shipped on Windows, macOS, Android, iOS If we are talking about security closed-source walled gardens are out of consideration right? > or any of the Linux "application bundle" systems like the Steam runtime, Docker, FlatPak This is sad indeed. Docker used right is just a distro inside a distro though, so anything that applies to distros applies here too.

jcelerier 5y ago
> If we are talking about security closed-source walled gardens are out of consideration right? yes, because there are no open-source apps on Windows and macOS of course...
notriddle 5y ago
> This is true on all major Linux distributions. Except Android, ChromeOS, and other Linux systems that get deployed as immutable images (stuff like Buildroot). Except servers, that’s almost all of the world’s Linux installs.
- oytis 5y ago
  > Except Android, ChromeOS Well, yes, these are proprietary walled gardens only using Linux as a kernel. > stuff like Buildroot Embedded Linux is special indeed. Core OE layers are well-maintained IMO, but as you use community ones the maintenance quality can vary. You have to take care of OTA of course which is a problem with no standardized solution so far, but the same applies if you develop in Rust for these platforms. But yeah, with embedded Linux you have to take responsibility for your whole system, so not much difference with Rust here (except at least if you have several apps having the same dependency you can be sure they'll use the same version of it). > Except servers, that’s almost all of the world’s Linux installs What do you mean? Most servers I've worked with would run one of the popular distributions, probably hardened and stripped of GUI stuff.
  - notriddle 5y ago
    > What do you mean? What I mean is that the situation you describe, with C libraries deployed in distro package managers, is a reality only on servers and extremely niche desktop platforms. Most of the world of software, even in the C programming language, does not work that way.