4 ms·

You can always just use Boost. I don't think I've ever worked on a C++ project that didn't use it! std::filesystem = boost::filesystem - 1.30.0, 2003 std::opt

You can always just use Boost. I don't think I've ever worked on a C++ project that didn't use it! std::filesystem = boost::filesystem - 1.30.0, 2003 std::optional = boost::optional - 1.30.0, 2003

jb1991 3y ago
Keep in mind that when boost features are eventually adopted into the C++ standard library, it is often only after their implementation has been strictly defined in ways that diverge from the boost implementations, which are often inefficient. Boost contains a lot of full-featured but inefficient code; for example, some Boost tools allow for arbitrary memory allocation which is often undesirable and their standard library versions do not allow for it. There are other design issues as well, such as how to consistently handle exceptions in edge cases, etc. Boost versions of some of these don't as comprehensively consider those situations.
- physicsguy 3y ago
  Of course, but aside from standardisation defined details, it also depends on your compiler's standard library implementation, and those are not all made equal, especially if you've got to build something both for Windows and Linux.
  - jb1991 3y ago
    Well, your compiler's standard library implementation should follow the C++ standard, and if your code expects what the standard requires, in most cases you should be fine. The problem is when code is written with certain behavior in mind that is not in the standard because the developer has gotten used to a particular compiler's liberties that extend beyond the standard, and then if they port to another platform, complications can ensue.
suby 3y ago
There is no reasonable solution to reflection. That we don't have an official solution here is an indictment of the C++ update process. Look to projects like Unreal Engine to see the horror and lengths that real projects have to go through to get around this.

You can always just use Boost. I don't think I've ever worked on a C++ project that didn't use it! std::filesystem = boost::filesystem - 1.30.0, 2003 std::optional = boost::optional - 1.30.0, 2003

jb1991 3y ago

Keep in mind that when boost features are eventually adopted into the C++ standard library, it is often only after their implementation has been strictly defined in ways that diverge from the boost implementations, which are often inefficient. Boost contains a lot of full-featured but inefficient code; for example, some Boost tools allow for arbitrary memory allocation which is often undesirable and their standard library versions do not allow for it. There are other design issues as well, such as how to consistently handle exceptions in edge cases, etc. Boost versions of some of these don't as comprehensively consider those situations.

physicsguy 3y ago
Of course, but aside from standardisation defined details, it also depends on your compiler's standard library implementation, and those are not all made equal, especially if you've got to build something both for Windows and Linux.
- jb1991 3y ago
  Well, your compiler's standard library implementation should follow the C++ standard, and if your code expects what the standard requires, in most cases you should be fine. The problem is when code is written with certain behavior in mind that is not in the standard because the developer has gotten used to a particular compiler's liberties that extend beyond the standard, and then if they port to another platform, complications can ensue.

suby 3y ago

There is no reasonable solution to reflection. That we don't have an official solution here is an indictment of the C++ update process. Look to projects like Unreal Engine to see the horror and lengths that real projects have to go through to get around this.