3 ms·
> * Textual inclusion: C++20 has modules, where you include sematically, not textually. ... provided that the libraries that you want to use are available as C
by the_why_of_y 7y ago
> * Textual inclusion: C++20 has modules, where you include sematically, not textually.
... provided that the libraries that you want to use are available as C++20 modules, not header files.
> * Leading zero for octal: C++ has custom literals,
... but no way to redefine the built-in "0" prefixed octal literal.
> * Weak typing: With a library, you can have strong aliases which are not interchangeable with the aliased type.
... you can have that in theory, I agree it's very useful, but can you name one widely used C++ library that e.g. defines custom integer or string types purely for the purpose of type safety?
> * Bytestrings: This is a library issue really.
... indeed, and the standard library's std::string is quite unhelpful, there's no way provided to iterate code points if you put UTF-8 in std::string.
> * Errors: C++ is multi-paradigmatic here,
... but none of the paradigms available with just the language and standard library have any static checks that the caller of a function actually handles an error, whether return value or exception.
> * Nulls: With `std::optional` and `gsl::non_null`, and especially with no return types necessary, you can comfortably avoid using `nullptr` in C++ code.
... provided you never use any library from the C++ ecosystem, none of which currently use std::optional or gsl::non_null.
One of the problems I have with C++ is that re-using existing libraries vs. structuring your code to statically avoid sources of bugs is a trade-off; it shouldn't be.
- einpoklum 7y ago> ... provided that the libraries that you want to use are available as C++20 modules, not header files. Yes. This will take time. But if you're writing most of the world from scratch (like with a new programming language), then you can write libraries in modules. > ... but no way to redefine the built-in "0" prefixed octal literal. True, but why use that? It's confusing if you don't know the convention. > ... can you name one widely used C++ library that e.g. defines custom integer or string types purely for the purpose of type safety? Well, custom string types? QString is used in tons of apps; but custom string types are rarely about safety. Integers - there's Boost's safe_numerics library. Granted, I'm not sure it's very popular or just mildly popular, but still. > ... indeed, and the standard library's std::string is quite unhelpful, there's no way provided to iterate code points if you put UTF-8 in std::string. Yes, Unicode support in the C++ standard library is lacking, or where it isn't, it might as well have been. But again - it's not the language. So you can write your string library (or port ICU) in Odin or in C++ > ... but none of the paradigms available with just the language and standard library have any static checks that the caller of a function actually handles an error, whether return value or exception. static checks are a compiler/IDE thing. But - there _is_ a [[nodiscard]] annotation in C++17, so that you can't just ignore a returned status altogether. > ... provided you never use any library from the C++ ecosystem, none of which currently use std::optional or gsl::non_null. Toucheel and the backwards compatibility is a bitch here. But 1. At those libraries' boundary, you have either silent or explicit conversion, which are safe, as long as you act safely on the outside. 2. Most templated standard library code will use optional just fine... > One of the problems I have with C++ is that re-using existing libraries vs. structuring your code to statically avoid sources of bugs is a trade-off; it shouldn't be. Agreed. Having said that - writing lightweight wrappers for an existing library is a middle-of-the-road solution which is a lot less bug prone than just writing unsafe, old-style C++ all over.