211–220 of 247 posts
>> When we call malloc, we just hope that we have enough stack space for it, we almost never check. Does Rust or Zig's malloc allocate on stack? Those millennials.
It's a function, when you call it, it allocates a frame on the stack.
Earlier quoted context omitted.
The lifetime of the space can be different, but must enclose, the objects created in that space. C++ doesn't track lifetimes. Such a separation is only useful in specific situations, such as the one the original article mentions. It could be useful in avionics or industrial control, where you often avoid memory pools and have arrays of specific kinds of objects instead.
Depends on what kind of lifetimes, yes C++ doesn't do Rust like lifetimes check, at least not without help from static analysis. However C++23 has introduced compiler aware functions to start specific lifetimes out of raw memory pools. https://en.cppreference.com/w/cpp/language/lifetime
Earlier quoted context omitted.
Is this syntax new(&something) a new addition? I don't remember it, but then I used to program in C++03
I assume it’s been around forever. https://en.cppreference.com/w/cpp/language/new (Placement-new is the thing you are talking about.) C++20 has `std::construct_at` which does the same thing but is usable at compile time (in a `constexpr` context) https://en.cppreference.com/w/cpp/memory/construct_at
edit: not sure why they didn't just bless placement new with constexpr powers though.
Earlier quoted context omitted.
> This separates construction, which is a typed thing, from allocation. But this is what C++ actually does! C++ ctors run after memory has been allocated (on the stack, on the heap, from a pool, etc.) Or maybe you mean something different?
The lifetime of the space can be different, but must enclose, the objects created in that space. C++ doesn't track lifetimes. Such a separation is only useful in specific situations, such as the one the original article mentions. It could be useful in avionics or industrial control, where you often avoid memory pools and have arrays of specific kinds of objects instead.
Of course, C++ does not have lifetimes (in the Rust sense), but your original claim was that C++ does not seperate allocation from construction.
> Such a separation is only useful in specific situations, such as the one the original article mentions.
It is actually quite common. You don't even have to reach for advanced things like memory/object pools. For example, if you want to implement a dynamically sized array type (std::vector), you typically want to increase the storage independently from the number of objects.
But then again, maybe you are talking about something different here...
---
Also, I may need to clarify some things about C++ allocators. They are not used to allocate storage for the object itself, but rather control how an object allocates memory for its subobjects. Keep in mind that the object itself may exist in a different kind of storage than its subobjects. For example, the object may live on the stack, but its subobjects must be allocated dynamically.
Earlier quoted context omitted.
This is exactly how C++ work. union { MyObject space; }; // just a bunch of bytes MyObject * myObject = new(&space) MyObject(); // invoke the constructor myObject->~MyObject(); // invoke the destructor If you want RAII use some wrapper like Optional.
Is this syntax new(&something) a new addition? I don't remember it, but then I used to program in C++03
Earlier quoted context omitted.
Frankly, my reason for using Rust is not memory semantics (I'd be happy for most applications with a Gc), it's the type system. I could be writing in Haskell for an even more powerful type system, of course, (especially now that Haskell has gained linear types) but the language never took hold outside of academia.
I know this is facile, and it's speaking as someone with a lot more enthusiasm about than expertise with Haskell, but whenever I write some toy Haskell code and have to think about "remember to close this file handle before the end of this block" or "make sure not to use this file handle outside this block (because we just used a combinator to close it)", I'm baffled that Rust has mostly figured out that whole class…
Have you heard of `withFile`?
https://www.stackage.org/haddock/lts-20.16/base-4.16.4.0/Sys...
Earlier quoted context omitted.
Yes to the appreciating simplicity bit, but if you go to Rust expecting to not sweat over having to control tiny details you are in for a ride.
To be honest I just clone and unwrap everywhere when writing the first iteration. If I care more, then I'll refactor to remove unnecessary clones. I really haven't felt the pain of the borrow checker like some people say.
Earlier quoted context omitted.
JIT compilers don’t actually need that low-level programming, and compilers in general use memory in a very haphazard way so they are likely better off with a GC. In fact, you probably loose way more by not being able to write as many/great optimizations in a low-level language than what you lose on a slight overhead — e.g. Java’s Graal JIT compiler is nowadays performing better (written in Java itself) than the “ori…
Indeed, having played with doing compiler / parser / transformation type work (for relational query transformation, etc) in Rust, and got stuck in a maze of borrow-checker disasters around the tree of references... what I'd say is: this kind of thing is actually better done in a higher level statically typed garbage collected language. For myself, I'd use a mature functional something like OCaml/StandardML or a Lisp…
Earlier quoted context omitted.
Malloc isn’t free, either.
`malloc` doesn't make up a meaningful percentage of performance-oriented software's execution time. Most of those programs bulk allocate and manage memory internally, so the cost of `malloc` isn't a relevant argument against managing memory manually. Indeed it's entirely possible to write a program that doesn't ever use `malloc` while still using allocations internally, from a stack allocator. The point isn't to `mal…
Of course a Sufficiently Smart Compiler can remove the overhead, but well...
Earlier quoted context omitted.
It's still bizarre though that Rust is capturing such ridiculous mindshare. I suspect it has a lot to do with web developers being plugged into Mozilla, and Mozilla spending quite a lot on Rust development and marketing. And Zig may be being roped into it. It seems to be a temporary low-level programming zeitgeist driven by YouTube and Reddit recommendation algorithms to an audience that has never done it and probabl…
> It's still bizarre though that Rust is capturing such ridiculous mindshare. I don't think it's that bizarre. The two big headline features that bring Rust such popularity are: #1 "70% of bugs are memory-safety bugs" [1] and Rust can help solve those, and #2 C/C++ have a couple of package manager solutions - none of which have critical mass and Rust "comes with" cargo. Those two make me really eager to continue expe…
70% of security bugs.
Approximately 0% of bugs that I had to deal in my career are memory-safety bugs.
That doesn't mean it is not important to fix or avoid security bugs (it indeed is!), but you have to be clear what you are selling.