It was stabilized in 2019 by accident:
369 karma · joined February 18, 2015
const EMPTY: String = String::new();
let a: [String; 1000] = [EMPTY; 1000];
const NONE: Option<String> = None;
let b: [Option<String>; 1000] = [NONE; 1000];
const SEVEN: AtomicU32 = AtomicU32::new(7);
let c: [AtomicU32; 200] = [SEVEN; 200];https://github.com/sponsors/m-ou-se/
*: Much of which has already landed: On Windows, mutexes etc. are no longer heap-allocated. And on many platforms, thread parking now directly uses futex(-like) syscalls/APIs.
**: That is, how a format_args!() is represented at runtime, which is relevant for all println!(), format!(), etc. macros that do any formatting.
So neither `&'a i32` nor `MutexGuard<'a, i32>` are 'static (unless 'a is), because you shouldn't keep references like that around longer than the stuff it points to. But i32 by itself satisfies i32: 'static, because it's perfectly fine to keep an i32 around forever. (But that doesn't mean that every i32 will stick around forever.)
Python doesn't really do multithreading: https://wiki.python.org/moin/GlobalInterpreterLock
It uses Python 3 of course. Using Python 2 these days would be a crime.
The numpy crate helps if you need to convert large arrays to Python, as numpy does not store every element separately on the heap.
For all the small vectors and matrices, things like Vector3 and Matrix3x3 from nalgebra work fine. A few generic things we had to change from statically sized to dynamically sized arrays/matrices, but since these were rather big already, the difference in performance was neglegible. The type safety was maintained by directly wrapping those in a generic struct where the template parameter describes the contents of the matrix or vector. Such template parameter is basically a struct where the members describe the meaning of all the columns/rows of the related vector/matrix. A custom derive proc macro generated the conversions to and from this type (which are all optimized away by the compiler). It looks something like this:
struct Foo<T: VectorLike> {
matrix: DynanamicallyAllocatedMatrix<f64>,
}
impl<T: VectorLike> Foo<T> {
fn new() {
Foo { matrix: DynanamicallyAllocatedMatrix::zeros(T::N, T::N) }
}
fn get_diagonal(&self) -> T { ... }
...
}
In the end, keeping track of the meaning of the entire vector/matrix in the type system provides us with even a lot more safety than only keeping the size of them in the type system. And it has the advantage that you don't need const generics, since you're keeping track of whole types, and not just numbers. The downside is that we have to maintain a few procedural macro implementations.
We'll be changing our company name in a few weeks, followed by the launch of a new website which should have a lot more information than the current one.
We don't use STM chips though. Since the way we do state estimation and fault tolerant control requires a lot of computational power, we settled on 64-bit ARM Cortex A series processors. Since there was nothing available that fit our requirements, we produce the hardware ourselves as well.
When we started a bit more than two years ago, we started in C++, but have been slowly switching to Rust starting less than a year later. Now that everything is in Rust, our productivity went up a lot, together with the reliability of our systems (which is our main selling point).
The thing we miss most from C++ is the Eigen library, but the alternatives in Rust are pretty okay, though less complete. We are adding features and optimizations to some of these libraries, which we'll publish open source in a few months probably.
.thing {
background: url(data:image/png;base64,iVBO...);
width: ...px;
height: ...px;
}
C++ doesn't even use @ and $, yet ;)
std::set does have a contains() function, it's called count(): http://en.cppreference.com/w/cpp/container/set/count
Or get the latest public draft from https://wg21.link/standard
Or an html version: http://eelis.net/c++draft/
const auto x = f().x1;