14 ms·

Headers? Awkward string manipulation? Very thin standard library? Fragmented build systems? I would describe dealing with those issues as "boilerplate" because

• _gabe_ 4y ago
  > Very thin standard library? I'm not sure we're thinking of the same standard library if you would describe it as thin...[0] [0]: https://docs.microsoft.com/en-us/cpp/standard-library/cpp-standard-library-header-files?view=msvc-170 https://docs.microsoft.com/en-us/cpp/standard-library/cpp-st...
  • lifthrasiir 4y ago
    That is still thin by the modern standard. More accurately speaking, C++ standard library has too many useless things and lacks too many useful things. Compare with D [1], Rust [2] or Zig [3]. [1] https://dlang.org/phobos/ https://dlang.org/phobos/ [2] https://doc.rust-lang.org/std/ https://doc.rust-lang.org/std/ [3] https://ziglang.org/documentation/master/std/ https://ziglang.org/documentation/master/std/
    • _gabe_ 4y ago
      It looks like the only big feature any of these standard libraries contain that C++ doesn't are things like networking and json/xml parsers. I would argue that those should not be part of a standard library, but you can still easily get those through additional C/C++ libraries. I honestly don't know what else you would be looking for in a standard library. C++ provides out of the box: - hash maps - sets - dynamic arrays - fixed length arrays - bit sets - option types - atomics - mutexes - futures - strings - queues/stacks/Deques - tuples - variants - streams - etc In addition, they have a huge range of algorithms that operate on all of these containers. I'm really curious, what does the standard library not have that you think forces you to write boilerplate?
      • lifthrasiir 4y ago
        I believe Rust has the most conservative standard library among those modern languages and it still has many things that the C++ standard library simply don't have (yet): - Unified result types. C++23 is finally going to have `std::expected`, but it will probably take another version or two to see the `std::expected`-only version of standard library. - Iterator utilities. Again, C++23 will see a significant improvement in <ranges> but that still falls short of what Rust `Iterator` provides by default. - Checked arithmetic. Rust and many other languages distinguish checked and unchecked arithmetic and put one of them (typically unchecked one) into the standard library. C++ doesn't have anything like that. - Guarded mutex (that is, a portion of memory by design only accessible when locked) and concurrent queue. C++ does support concurrency out of the box, but its tools are pretty bare bones and this is one example.
        • _gabe_ 4y ago
          Thanks for providing some specific examples! I still don't see how any of these would result in a 30% decrease in boilerplate. My main point was I feel like header files are the biggest piece of boilerplate and it seems weird to accuse the lack of features in the standard library as a reason for all the boilerplate. Just a couple other points though, C++ provides fully customizable iterators. They don't have ranges, but ime the amount of times I need ranges vs just iterating over a container are relatively low. Also, is a lock guard in C++ not the same thing as a guarded mutex? This may be ignorance on my part because I'm not familiar with rust, but it sounds like the same thing to me. A lock guard will lock and automatically release a mutex once it goes out of the current scope.
          • lifthrasiir 4y ago
            You have a good point that featureful standard library doesn't necessarily result in less boilerplate, but I assumed that you kinda implied it by enumerating features. Frankly almost every feature you and I listed is not exactly relevant here---most of them can be easily refactored into external libraries ;-) What I find most lacking from the C++ standard library is actually coherence. Different parts of standard library were developed separately from each other, and while adapters between them exists (e.g. stream iterators can be used with `std::format_to`) they are by definition boilerplates. Some parts are simply not relevant in the modern C++ programming and still have to be retained for compatibillity (e.g. `std::auto_ptr`). In this view C standard library is actually a lot more coherent than C++, even though C standard library itself is less powerful and featureful than C++. > They don't have ranges, but ime the amount of times I need ranges vs just iterating over a container are relatively low. I think this is simply because C++ iterators are less usable. All iterators can be technically rewritten as loops, so you may have internalized to avoid using iterators when iterators would be beneficial but difficult to use. I personally find myself using iterators a lot more in Rust than in C++. > Also, is a lock guard in C++ not the same thing as a guarded mutex? This may be ignorance on my part because I'm not familiar with rust, but it sounds like the same thing to me. A lock guard will lock and automatically release a mutex once it goes out of the current scope. I actually don't know the exact term (the name "guarded mutex/lock" was what I've used in the past), but I meant a mutex that is strongly coupled with some additional data so that the API prevents or at least discourages to access the data without acquiring the mutex. In a hypothetical design `std::mutexed<T>` will be `T` plus `std::mutex` and `std::lock_guard<std::mutexed<T>>` would have `operator *` which allows the access to `T`. In Rust [1] this is actually the default, and you never have a bare `std::mutex` (though it can be simulated with placeholder data, `Mutex<()>`). [1] https://doc.rust-lang.org/std/sync/struct.Mutex.html https://doc.rust-lang.org/std/sync/struct.Mutex.html