5 ms·

At the office c++ fans are using modules to fight back against the vast simplifications go, rust come with wrt to builds, dependency management. Alas modules ar

• pjmlp 5y ago
  And 40 years of mature libraries.
  • mtzet 5y ago
    In my experience the important libraries I need to interact with are C libraries, not C++ libraries. Of course certain niches have very important C++ libraries, but I don't think the C++ library story in general is that great. Care to expand?
    • fsloth 5y ago
      Not OP, but several domains have large non-trivial C++ codebases. For example, numerics, computational geometry and computer graphics have large mature libraries that would need to be rewritten by subject experts. The number of subject experts in these fields is not that large to start with, and the algorithms are complex and non-trivial, so "exothermic" explosion to new languages like Rust is unlikely to happen very fast.
    • ziotom78 5y ago
      Not the OP, but the first libraries that come to my mind are Qt and wxWidgets (for GUI programming).
    • pjmlp 5y ago
      CUDA, SYSCL, DP++, Qt, MFC and WinUI, Metal Shading Language, DirectX, most COM APIs in Windows, WinRT infrastructure, macOS IO/Driver Kit, ARM Mbed, Arduino, the native implementation of most well known ML libraries, all major game engines middleware, LLVM and GCC, just from the top of my head.
  • tialaramex 5y ago
    Mmm. 40 years ago is 1981. So, if you do have a 1981 API it's completely incompatible with how you'd actually write C++ in 2021 and will need a wrapper, putting it squarely in the same situation as Rust where you would also want to wrap this 1981 API.
    • jcelerier 5y ago
      > So, if you do have a 1981 API it's completely incompatible with how you'd actually write C++ in 2021 is it though. I have plenty of .h in my /usr/include with copyrights between 1980 and 1985. Sure, it's not modern best practices, but at least it's possible... and for a one-off task there's definitely not much point in doing a wrapper.
      • tialaramex 5y ago
        Yes. So, modern C++ says you want a unique_ptr to any owned resource you're not sharing, and otherwise a shared_ptr (or some equivalent smart pointer). Your 1981 API doesn't do that because those don't exist in 1981. Maybe it gives you a raw pointer to new resources. In 2021 those are just loose references which don't signify ownership, you need the wrapper to avoid this confusion leaking into your program. Maybe it gives you an integer handle which needs to be passed to some other API call to "release" the handle when you're done with it. Again you'll want a wrapper to handle this properly in your code or you may leak resources. You'll also want a wrapper because one integer is the same as another, but you probably shouldn't finished_with_cow(dog_number) or clean_up_dog(cow_number) even though those compile. Being forty years old it invariably won't be thread safe, so you'd also want to wrap it for that reason unless (as is often the case in C++) your code isn't thread safe anyway. "at least it's possible" isn't a differentiator. As I said you could also access this 40 year old API from Rust, but you'd want to build a wrapper for it because it the behaviour is so violently different from what's expected in the modern ecosystem.
        • jcelerier 5y ago
          > Maybe it gives you a raw pointer to new resources. In 2021 those are just loose references which don't signify ownership, you need the wrapper to avoid this confusion leaking into your program. you can use unique_ptr directly for that. take for instance the 197x API, fopen: you can just do using file_handle = std::unique_ptr<FILE, decltype([] (FILE* file) { fclose(file); })>; and then store a file_handle in your class. > Maybe it gives you an integer handle which needs to be passed to some other API call to "release" the handle when you're done with it. Again you'll want a wrapper to handle this properly in your code or you may leak resources. You'll also want a wrapper because one integer is the same as another, but you probably shouldn't finished_with_cow(dog_number) or clean_up_dog(cow_number) even though those compile. it needs a one-time class to coax an int into behaving like a pointer but otherwise it's the same principle
• jcelerier 5y ago
  > It'll be decades before our existing c++ code base is converted to modules > I'm trying to move to go when I can and pure rust otherwise. I don't understand in which universe replacing includes by imports takes more time than a full rewrite in a different language
  • speters 5y ago
    It is not as if the same effort will be dedicated to switching to modules than a rewrite (which probably won't happen for the OP)