3 ms·

If you’re allocating from multiple arenas, you’re not going to be using `new` in C++ or `Box` in Rust. Nothing stops you from writing an arena allocator that ca

If you’re allocating from multiple arenas, you’re not going to be using `new` in C++ or `Box` in Rust. Nothing stops you from writing an arena allocator that can return an error code in Rust any more than C++ does.

ncmncm 5y ago
Hint: nobody uses "new" in C++ anymore. All the C++ containers, and make_unique etc. know how to use local arenas. I gather there has been some effort to get Rust library components aware of such things. Handling exhaustion in them is an interesting research topic.
- msbarnett 5y ago
  > Hint: nobody uses "new" in C++ anymore "nobody" ~/chromium (main)$ rg --stats -t cpp "[=\(][ ]*new " ... 17639 matches 17536 matched lines 7162 files contained matches 96561 files searched 1539692 bytes printed 763109193 bytes searched 1.119265 seconds spent searching 1.428974 seconds That's surely a lot of non-usage. Maybe it's just Chrome, though? ~/llvm-project (main)$ rg --stats -t cpp "[=\(][ ]*new " ... 7447 matches 7394 matched lines 2245 files contained matches 35148 files searched 541938 bytes printed 385115019 bytes searched 0.425689 seconds spent searching 0.485431 seconds Hmmmm.
  - ncmncm 5y ago
    You have found lots of old code. ... which we already knew existed.
    - deleted 5y ago
      [deleted]
tialaramex 5y ago
If you run nightly you can already Box::new_in(thing, my_allocator) if that is what you want. Or indeed, if you want to keep Nathan here happy, you can even Box::try_new_in(thing, my_allocator) and get Errors when your allocator says it can't help you (which you likely won't ever bother handling meaningfully). In the event you're as desperate for those last dregs of performance as the author of the "Why not rust?" article, (and let's assume you actually measured your performance problem before jumping to the step where you make everything more complicated and more buggy for no good reason?) you can even Box::try_new_uninit_in() and unsafely do all the initialization in place as needed yourself as you might do by default in C++. Now, I don't know when Allocators will be stabilized, the Working Group has been making steady progress for some years now but this is a tricky business, witness the many languages that get it quite badly wrong...
- ncmncm 5y ago
  Imagining that any of this has to do with "last dregs of performance" demonstrates that you have completely misunderstood the topic.

ncmncm 5y ago

Hint: nobody uses "new" in C++ anymore. All the C++ containers, and make_unique etc. know how to use local arenas. I gather there has been some effort to get Rust library components aware of such things. Handling exhaustion in them is an interesting research topic.

msbarnett 5y ago
> Hint: nobody uses "new" in C++ anymore "nobody" ~/chromium (main)$ rg --stats -t cpp "[=\(][ ]*new " ... 17639 matches 17536 matched lines 7162 files contained matches 96561 files searched 1539692 bytes printed 763109193 bytes searched 1.119265 seconds spent searching 1.428974 seconds That's surely a lot of non-usage. Maybe it's just Chrome, though? ~/llvm-project (main)$ rg --stats -t cpp "[=\(][ ]*new " ... 7447 matches 7394 matched lines 2245 files contained matches 35148 files searched 541938 bytes printed 385115019 bytes searched 0.425689 seconds spent searching 0.485431 seconds Hmmmm.
- ncmncm 5y ago
  You have found lots of old code. ... which we already knew existed.
  - deleted 5y ago
    [deleted]

tialaramex 5y ago

If you run nightly you can already Box::new_in(thing, my_allocator) if that is what you want. Or indeed, if you want to keep Nathan here happy, you can even Box::try_new_in(thing, my_allocator) and get Errors when your allocator says it can't help you (which you likely won't ever bother handling meaningfully). In the event you're as desperate for those last dregs of performance as the author of the "Why not rust?" article, (and let's assume you actually measured your performance problem before jumping to the step where you make everything more complicated and more buggy for no good reason?) you can even Box::try_new_uninit_in() and unsafely do all the initialization in place as needed yourself as you might do by default in C++. Now, I don't know when Allocators will be stabilized, the Working Group has been making steady progress for some years now but this is a tricky business, witness the many languages that get it quite badly wrong...

ncmncm 5y ago
Imagining that any of this has to do with "last dregs of performance" demonstrates that you have completely misunderstood the topic.