|
|
|
|
|
|
by ncmncm
1481 days ago
|
|
|
What makes UB in C++ is spelled out in its International Standard; there is no specification for Rust, just an implementation. It has been many years since C++ preprocessors differed notably from one implementation to the next. Nothing in C++ is global except what you choose to make global. In fact today C++ lifetimes are expressed in the type system, and this is an example of what C++ enables a library to provide. If, working as a library designer, Rust was not a big step down, you were neglecting to provide users of your libraries much of the value you could have offered. Your remarks suggest that libraries you delivered were closer to C than C++. |
|
|
That's not true, the standard only specifies that some things are UB, it is not exhaustive, nor is it unambiguous. Furthermore, no current C++ compiler is compliant even with those parts of the standard which everyone agrees on (eg. see proposals to introduce a "bytes" type to LLVM to resolve known miscompilations). There is work to improve this, such as defining an explicit memory model, but Rust is ahead of C++ on this.
> In fact today C++ lifetimes are expressed in the type system, and this is an example of what C++ enables a library to provide.
Do you have an example of this, or are you talking about using smart pointers? Smart pointers are about ownership, not lifetimes.
> Your remarks suggest that libraries you delivered were closer to C than C++.
Most of my remarks were about consuming other libraries from my library, which is not something I have control over. Sure, I can use smart pointers and other modern C++ features in the API I expose... That doesn't change any of the points I mentioned.