gcpp
wg-allocators
gcpp | wg-allocators | |
---|---|---|
12 | 18 | |
912 | 199 | |
- | 5.5% | |
10.0 | 0.0 | |
about 5 years ago | over 3 years ago | |
C++ | ||
MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gcpp
- C++: Deferred_ptr, Deferred_heap, Deferred_allocator
-
What feature would you like to see in C++26?
static reflection and pattern-matching, as everyone is saying, but I'd also like to see a garbage-collecting smart-pointer in the standard library similar in design to Herb Sutter's deferred_ptr
-
Rust went from side project to world’s fastest growing language
There are definitely fringe edge cases where C++ can do things that Rust simply cannot, currently.
I'm thinking of things like Herb Sutter's deferred_heap (https://github.com/hsutter/gcpp) that give you GC-like abstraction. It's pretty cool that this is possible to write in vanilla C++ with decent ergonomics. I tried to make something similar awhile back and hit a wall in terms of making something that would be pleasant to use.
Rust has several on-going experiments with making a nice GC, along with good support for arenas. (If you can use arenas, they're great.)
-
Now the C++ removed garbage collector support, is it still possible the have a global garbage collector in a C++ application?
Check out this library: https://github.com/hsutter/gcpp
-
tracked_ptr - when shared_ptr is not enough
Hm, yeah, that's pretty unclear. My understanding is based off the link to Herb's proposal in the OP, which I understand this to be an evolution of.
-
What do you think will be the future direction for C++ evolution?
Re garbage collection: My understanding was that the standard API was intended for interop with managed languages, not for pure C++ code to use, although I could be mistaken. I don't think garbage collection is entirely a lost cause, for instance Herb Sutter's work, which I think he wants to integrate in Cppfront, would be a great way to do it. Imo, his garbage collection ([1] [2]) could be much better than D or Nim, because it has easily controllable performance characteristics. You don't pay for it if you won't use it, and it's unlikely that libraries you pull in would need it, which is imo what makes programming without the "optional" GC in D and Nim difficult.
- Any guesses as to how C++ will turn out w.r.t. garbage collection?
-
Why do people want a garbage collector in C++?
Herb Sutter
-
New "Java to C++" code converter tool for beginners
Something like gcpp would be quite nice. That and a intelligent scope detector could make use of isolated and local GC when it detects that some objects stays together and have similar lifetime.
wg-allocators
-
Anouncing `stabby` 1.0!
Tracking issue for Storages, and a TLDR on what it is
- What backwards-incompatible changes would you make in a hypothetical Rust 2.0?
-
Custom allocators in Rust
I must have gotten confused, since from your brief discussion with CAD97 it seemed like there was a way for the concepts to live separately and that Storage could complicate things in comparison. But if implementing Allocator in terms of Storage is basically equivalent and Storage is flexible enough that I could write one to pass memory out to unsafe code, that works just as well.
-
Zig and Rust
https://rust-lang.github.io/rfcs/1974-global-allocators.html was the original RFC.
My vague understanding is that there's a working group https://github.com/rust-lang/wg-allocators
The further I get from working on Rust day to day, the less I know about these things, so that's all I've got for you.
-
Rust went from side project to world’s fastest growing language
If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe. If you self-reference using offsets from the struct's base pointer, you need a splash of unsafe but your struct can be freely moved without invalidating its self-referential "pointers".
Per-struct allocators are a work in progress (see https://github.com/rust-lang/wg-allocators/issues/48).
Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads (without moving it).
- Rust is coming to the Linux kernel
-
FunDSP 0.1.0, an audio processing and synthesis library
Besides that allocation is not really a problem for no_std. It's resolved by using alloc crate directly, so anything usable with custom allocators is supported. Example in dasp sources - https://github.com/RustAudio/dasp/blob/master/dasp_slice/src/boxed.rs#L14-L19 . Also worth looking at this issue to check what is usable already - https://github.com/rust-lang/wg-allocators/issues/7
-
Andrew Kelley claims Zig is faster than Rust in perfomance
But that's on track for rust as well: https://github.com/rust-lang/wg-allocators/issues/7
-
Which important features from C/C++ are missing in Rust
Here: https://github.com/rust-lang/rfcs/pull/1398. there is also a working group for this: https://github.com/rust-lang/wg-allocators.
-
Box<T> allocator override?
It's unstable. wg-allocators contains discussions about design and a tracking issue for collections that need an allocator https://github.com/rust-lang/wg-allocators/issues/7
What are some alternatives?
sgcl - Smart Garbage Collection Library for C++
www.ziglang.org
graph_ptr - A smart ptr implementation that can handle cycles, similar to herb sutter's deferred_ptr.
serde-plain - A serde serializer that serializes a subset of types into plain strings
convey - Layer 4 load balancer with dynamic configuration loading
enum-map
pkg-fmt - Metadata to support C++ packaging
rules_rust - Rust rules for Bazel
ergo - std-alternative prototyping / education library
cryptography - cryptography is a package designed to expose cryptographic primitives and recipes to Python developers.
cargo-script-mvs - Pre-RFC for merging cargo-script into cargo
dpp - Directly include C headers in D source code