4 ms·

Linus has been critical of C, before, too (e.g. https://lkml.org/lkml/2018/6/5/769 https://lkml.org/lkml/2018/6/5/769). If you look at Linus's criticism of C++

• jcelerier 5y ago
  > Rust, as it happens, doesn't do any of that. Rust does not allocate implicitly when you use Vec or String (or any other container) ? come on..
  • Ericson2314 5y ago
    https://github.com/rust-lang/rust/pull/84266 https://github.com/rust-lang/rust/pull/84266 We have been excising this with a new opt-out mechanism so there are no allocations behind your back but the same abstractions are notheless used as the rest of the Rust ecosystem.
  • geofft 5y ago
    No, it allocates explicitly when you do that. Vec and String are heap-allocated types, so whenever you use them, you know you're doing an allocation. In C++ you can write code like this: #include <string> #include <iostream> void print(const std::string &s) { std::cout << s << std::endl; } int main() { print("Hello world!"); } This compiles with no warnings, and at no point in the function "main" do you see that you're causing a memory allocation and a copy by implicitly converting your static message to a std::string, passing it to the function, and deallocating it. If you code-review "main", it doesn't look like you're doing an allocation because you're passing a const char *; if you code-review "print", it doesn't look like you're doing an allocation because you're accepting a std::string, which has already been allocated. So you get an extra, unneeded allocation in the chasm between the two, and it's very hard to track down the performance problem (or, in the worst case, a hang - memory allocation can block on flushing buffers or swapping things out, so you'd better not run into this situation in code that could itself be involved in writing to disk!). Compare the equivalent Rust code: fn print(s: &String) { println!("{}", s); } fn main() { print("Hello world!"); } which produces a "mismatched types" error: "expected reference `&String`, found reference `&'static str`." To get this to compile, you have to write something like print(&"Hello world!".to_owned()); , where you specifically instruct an allocation to happen. The objection is to implicit allocations. Explicit allocations are fine.
    • jcelerier 5y ago
      > This compiles with no warnings, and at no point in the function "main" do you see that you're causing a memory allocation and a copy by implicitly converting your static message to a std::string, passing it to the function, and deallocating it Such a warning would be a bug in this specific case as "Hello World!" is under the SSO size though - there is no call to malloc/new in this specific std::string creation. I fail to see how that is relevant though: the kernel does not use the C standard library - it's not going to use the standard C++ library either except maybe the freestanding, compile-time-only bits such as type_traits, concepts, ... In which case it is trivial to have a string type akin to rust's: class kstring { public: explicit kstring(const char* str, std::size_t len); private: const char* m_storage{}; std::size_t m_len{}; }; auto operator""_to_owned(const char* str, std::size_t len) { return kstring{str, len}; } void print(const kstring& str) { // ... } int main() { // fails: // print("foo"); // ok print("foo"_to_owned); } Here, the correct answer would be std::string_view anyways (or a custom c_string_view). > If you code-review "main", it doesn't look like you're doing an allocation because you're passing a const char *; if you code-review "print", it doesn't look like you're doing an allocation because you're accepting a std::string, which has already been allocated. My experience really disagrees with this part, every time I've been involved in code reviews, it was common knowledge that a function taking a const& or && can cause an allocation at the call site. It's barely a beginner mistake to not take it into account.
  • tialaramex 5y ago
    Amusingly if you create a Vec or String that operation is guaranteed not to allocate :D The new() functions for these types are const (ie they can be evaluated at compile time) and produce an "empty" placeholder. Because Rust's Strings don't have NUL termination, the empty string doesn't need any backing storage, likewise for an empty vector. When (and more importantly in many programs if) you actually add something to the string or vector that may prompt an allocation, but you called an explicit method to do that, so it oughtn't to come as any surprise.
• tialaramex 5y ago
  The allocations thing in particular. You can watch serious C++ practitioners staring at a class definition and usage and trying to figure out answers to a quiz question, "How many allocations does this do?". Is that line a Move or a Copy? That's a bad sign for a language you'd supposedly want to write OS kernels in. Rust got luckier here, by the time Rust was invented programmers knew they really care about this, and so Rust explicitly distinguishes Copy (this object is just bits, so you can duplicate it by copying the bits), from Clone (this object can be duplicated, but you need to call its clone() method to explicitly do that work) and gives Move semantics to all assignments of types which do not have Copy. So in Rust "let a = b" definitely isn't doing memory allocation, it just moves bits. If you misunderstand the situation and assumed b is still valid because it was Copy, but actually it isn't, the compiler has your back and will politely refuse to let you use variable b after it was Moved. If you did still need b you can write "let a = b.clone()" and now they both still exist but anybody can see this code might be doing something expensive 'cos it calls this clone method. And if the compiler says "Ahem, you can't Clone that" then you've just learned something very important about the thing that a minute ago you assumed was just a few trivially duplicated bits.
  • blub 5y ago
    Given that this is the kernel, using typical C++ libraries would be out of the question, so it should be easy enough to design things right from the start. C++ is after all used in embedded contexts where allocations are forbidden and it offers excellent support for this use case. In such a project where allocations matter one would not stare at class definitions, one would ensure that there are no allocations by forbidding use of libraries like the STL and for example disabling operator new and the copy constructor. If the project is safety-critical there are tools which can enforce such rules. Edit: I've clarified that I was referring to C++ libraries only.
    • kibwen 5y ago
      Using Rust's stdlib isn't out of the question for the kernel, at least not the most fundamental bits of the stdlib. Rust offers a well-defined subset of its stdlib, called libcore, that is suitable for embedded work: no allocations, no OS-provided abstractions, etc. So you don't get HashMap or Vec, but you do get Option, Iterator, str (but not String, the heap equivalent), etc.
• blub 5y ago
  Exception handling and implicit allocations are very easy to control in C++, especially in a project where one would not use the STL or any other typical user space libraries. The language has been used in safety-critical projects and low-level embedded work for decades, so it must support such use cases well.