Re: [TECH TOPIC] Rust for Linux

Laurent Pinchart
2021-07-07T22:44:07Z

Hi Miguel,

On Thu, Jul 08, 2021 at 12:11:16AM +0200, Miguel Ojeda wrote:
> On Wed, Jul 7, 2021 at 10:32 PM Bart Van Assche wrote:
> >
> > Thank you for having shared your opinion. You may want to know that
> > every C++ project I have worked on so far enabled at least the following
> > compiler flags: -fno-exceptions and -fno-rtti.
> >
> > What the C++ operator new does if not enough memory is available depends
> > on the implementation of that operator. We could e.g. modify the
> > behavior of operator new as follows:
> > - Add -fno-builtin-new to the compiler flags.
> > - Define a custom version of operator new.
>
> The issue is that, even if people liked C++ a lot, there is little
> point in using C++ once Rust is an option.
>
> Even if you discuss "modern C++" (i.e. post-C++11, and even
> post-C++17), there is really no comparison.
>
> For instance, you mentioned `std::span` from the very latest C++20
> standard; let's build one:
>
> std::span<int> f() {
> int a[] = { foo() };
> std::span<int> s(a);
> return s;
> }
>
> Now anybody that accesses the returned `std::span` has just introduced
> UB. From a quick test, neither Clang nor GCC warn about it. Even if
> they end up detecting such a simple case, it is impossible to do so in
> the general case.
>
> Yes, it is a stupid mistake, we should not do that, and the usual
> arguments. But the point is UB is still as easy as has always been to
> introduce in both C and C++. In Rust, that mistake does not happen.

You're comparing apples and pears though. A C++ function that is meant
to transfer unique ownership of an object to the caller should return a
std::unique_ptr<> on a container that stores the data. We're getting
off-topic though, this mail thread isn't about comparing C++ and rust
:-)

--
Regards,

Laurent Pinchart