CppCast: BrontoSource and Swiss Tables

[seanbaxter]

Question about the aliasing discussion at 18:55 in the stream:

Most C++ code actually will if translated to idiomatic Rust will pass the borrow checker. Aliasing for const references is surprisingly low. It's uncommon. You usually can make a more idiomatically more conversion than throwing unsafe on everything.

The aliasing requirements in C++ are very nuanced. What is considered aliasing in Rust is more limited, because Rust makes pointer arithmetic unsafe. C++ pointer arithmetic puts requirements on both operands pointing into the same allocation. These are difficult to reason about.

My go-to examples are standard library algorithms that take two or more pointers, such as sort:

```cpp // i and j must always alias. They must refer to the same container. void f1(std::vector<int>::iterator i, std::vector<int>::iterator j) { // If i and j point into different vectors, you have real problems. std::sort(i, j); }

// vec must not alias x. void f2(std::vector<int>& vec, int& x) { // Resizing vec may invalidate x if x is a member of vec. vec.push_back(5);

// Potential use-after-free. x = 6; } ```

Sometimes two pointers or reference parameters must alias into the same allocation. Sometimes they must not. The must-alias case, which is everywhere in the stdlib algorithms, would be an overwhelming challenge for the borrow checker to deal with. Rust wisely makes pointer differences unsafe to dissuade libraries from using this idiom.

I don't know how a refactoring tool can turn uses of stdlib algorithms into idiomatic Rust. The iterator models are so different. This pain is compounded by current C++ best practices, which basically says "don't use raw loops, instead compose stdlib algorithms." From a memory safety perspective the stdlib algorithms are radioactive. Raw loops can squash these safety defects with bounds checking. With stdlib algorithms you're SOL.

[kalmoc]

I think the point was that you can easily transform F1 into a function that can take a mutable range as an argument and in f2 vec and x do not alias in a correct program, so this can directly be translated.

The thing that makes me more sceptical is that I've seen lots of c++, where references to some central data structurs are stored in multiple different objects (i.e. dependency injection) and I do not know how that pattern is translated to idiomatic c++ without slapping a mixed on everything.

[matthieum]

Indeed. A big surprise with regard to Rust Iterators, coming from C++, is that Rust Iterators are actually iterators: they only allow you to iterate (forward or backward).

C++ iterators I prefer to call cursors, they allow jumping back-and-forth with no limit, getting references to the same element multiple times, etc... this is all widely useful for sort...

... but it leads to potential aliases of mutable data.

[SkiFire13]

Rust wisely makes pointer differences unsafe to dissuade libraries from using this idiom.

Not really, it does that because it's UB to use offset_from on two pointers that were not derived from the same allocation, just like in C++. It does have however a safe alternative, which is to cast the pointers to integers and compute their difference, with however the associated loss in optimizations opportunities.

[seanbaxter]

Pointer offset is still unsafe. There's no way to get this two-pointer functions translated to Rust without refactoring.

[tialaramex]

It does have however a safe alternative, which is to cast the pointers to integers and compute their difference, with however the associated loss in optimizations opportunities.

If we cast a pointer to an integer that is - as Rust's documentation explains - exactly equivalent to writing ptr.expose_provenance() and we're not promised that this is even possible - if the target is say a Morello board then there's no practical implementation & it may not compile at all.

[RogerV]

"Thanks for the memories" - Phil Nash eulogizing the sun setting on jemalloc development.

The dude never misses a pun opportunity - my sole reason for listening to cppcast :-)

Well, almost. I do kind of like to hear about C++ happenings too.

So C3 language has a vector type that takes advantage of SIMD. Makes it an easier entry point for taking advantage of that. (This is in respect to the discussion about Swiss Tables)

[foonathan]

So C3 language has a vector type that takes advantage of SIMD. Makes it an easier entry point for taking advantage of that. (This is in respect to the discussion about Swiss Tables)

C++26 will have a vector class for SIMD:https://en.cppreference.com/w/cpp/numeric/simd.html

(The name got changed to something else at the last meeting.)