Hacker News Reader

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

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.

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.

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.

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.

Reply on news.ycombinator.com