cppcoro
compiler-team
Our great sponsors
cppcoro | compiler-team | |
---|---|---|
24 | 46 | |
3,235 | 380 | |
- | 2.6% | |
0.0 | 6.8 | |
4 months ago | 12 days ago | |
C++ | HTML | |
MIT License | Apache License 2.0 |
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.
cppcoro
-
Struggle with C++ 20 Coroutines
PS: Take a look at cppcoro; this might help as well, especially generator<>, if you're looking to generate numbers, and stuff;
-
Does C++23 have a coroutine task promise type?
This is the only viable implementation.
-
Stop Comparing Rust to Old C++
Kind of sounds like whatever library you were using provided leaky abstractions. Something like cppcoro provides really good abstractions for coroutines, the user really doesn't need to understand why any of it works.
-
Sane coroutine imitation with macros; copyable, serializable, and with reflection
Is there a usecase for copying/serializing such coroutines? If not, I would use the normal C++20 coroutines (cppcoro?).
-
Is Tokio::sync::Mutex lock-free?
C++ has the popular CppCoro library. Async_mutex is its equivalent of Tokio::sync::Mutex, providing exclusive access to data shared between tasks.
- My experience with C++ 20 coroutines
-
My thoughts and dreams about a standard user-space I/O scheduler
Because the whole application is running under a single thread there is no need for atomic operations in synchronization primitives(which most of the time requires seq_cst memory order and CMPXCHG which is an expensive instruction in CPU). for example what async_mutex would look like if it knows it's running in a single-threaded scheduler (a non-atomic state variable and waiters queue).
-
[Discussion] What are some old C++ open source projects you wish were still active?
Maybe not old, but I wish cppcoro was still updated. It was such a nice start!
-
A high-level coroutine explanation
You can get generator<> from https://github.com/lewissbaker/cppcoro
-
C++ Coroutines Do Not Spark Joy
It is possible to compose them more easily than described in the article; Lewis Baker's cppcoro library for example provides a recursive_generator<> type[0] that allows this without using any macros. It's up to the library part of coroutines to make things easy, end users are not expected to write low-level coroutine code themselves.
I wonder about the allocation elision. Return value optimization became mandatory, and some compilers can already elide calls to new/delete and malloc()/free() in normal code, so perhaps it will be possible to guarantee allocation elision in the future in the most used cases.
[0]: https://github.com/lewissbaker/cppcoro#recursive_generatort
compiler-team
-
The Rust Calling Convention We Deserve
> Also, why aren't we size-sorting fields already?
We are for struct/enum fields. https://camlorn.net/posts/April%202017/rust-struct-field-reo...
There's even an unstable flag to help catch incorrect assumptions about struct layout. https://github.com/rust-lang/compiler-team/issues/457
- Rust proposal for ABI for higher-level languages
-
The Linux Kernel Prepares for Rust 1.77 Upgrade
Are you talking about https://github.com/rust-lang/compiler-team/issues/688 ? I think that issue provides a lot of interesting context for this specific improvement.
-
Progress toward a GCC-based Rust compiler
And mips64, which rustc recently dumped support for after their attempt to extort funding/resources from Loongson failed:
https://github.com/rust-lang/compiler-team/issues/648
This is the biggest problem with the LLVM mentality: they use architecture support as a means to extract support (i.e. salaried dev positions) from hardware companies.
GNU may have annoyingly-higher standards for merging changes, but once it's in there and supported they will keep it for the long haul.
-
Cargo has never frustrated me like npm or pip has. Does Cargo ever get frustrating? Does anyone ever find themselves in dependency hell?
See https://github.com/rust-lang/compiler-team/issues/688
- Rust: Drop MIPS to Tier 3
-
There is now a proposal to switch Rustc Nightly to use a parallel frontend
The work has been going on for some time now and it seems we are quite close to it being enabled as a default for nightly builds, I am super thrilled upwards of 20% faster clean builds and possibly more are on the horizon. Hope everything works out without triggering some unseen ICE. https://github.com/rust-lang/compiler-team/issues/681 Edit: If you want to discuss this feature reach out on Zulip
-
Rust 1.72.0
I'd recommend reading the MCP[1] they linked regarding the decision as well as their target tier policy [2].
They are dropping tier 1 support for Win 7 and Win 8. That means they are no longer going to guarantee that the project builds on those platforms and passes all tests via CI.
As long as it is feasible they will probably keep CI runs for those platforms and if interested parties step up and provide sufficient maintenance support, it will remain tier 2. i.e a guarantee that it builds on those platforms via CI but not necessarily that all features are supported and guaranteed via passing tests.
If interested parties can provide sufficient maintenance that all tests continue passing, it will be tier 1 in all but name. However the rest of the development community won't waste their time with issues like Win 7 and 8's partial support for UTF-8.
And once CI stops being feasible for the compiler team to host, it'll drop down to tier 3. If there's sufficient interest from the community towards maintaining these targets, in practice you should see comparable support to with tiers 1 or 2 however now any CI will be managed externally by the community and the compiler team will stop worrying about changes that could break compilation on those targets.
TLDR: They aren't saying "it'll no longer work" but rather "if you want it to stay maintained for these targets, you have to pitch in dev hours to maintain it and eventually support the infrastructure to do this because we don't see a reason to continue doing this". So if you care for these targets, you'll have to contribute to keep it maintained.
[1]: https://github.com/rust-lang/compiler-team/issues/651
- Experimental feature gate for `extern "crabi"` ABI
-
Prerequisites for a Windows XP 3D game engine
(The already broken) XP support was removed almost 3 years ago: https://github.com/rust-lang/compiler-team/issues/378
What are some alternatives?
libunifex - Unified Executors
libvfio-user - framework for emulating devices in userspace
drogon - Drogon: A C++14/17/20 based HTTP web application framework running on Linux/macOS/Unix/Windows
llvm-mos - Port of LLVM to the MOS 6502 and related processors
Folly - An open-source C++ library developed and used at Facebook.
ua-parser-js - UAParser.js - Free & open-source JavaScript library to detect user's Browser, Engine, OS, CPU, and Device type/model. Runs either in browser (client-side) or node.js (server-side).
C-Coroutines - Coroutines for C.
namespacing-rfc - RFC for Packages as Optional Namespaces
Flow - Flow is a software framework focused on ease of use while maximizing performance in closed closed loop systems (e.g. robots). Flow is built on top of C++ 20 coroutines and utilizes modern C++ techniques.
cargo-show-asm - cargo subcommand showing the assembly, LLVM-IR and MIR generated for Rust code
coproto - A protocol framework based on coroutines
libgccjit-patches - Patches awaiting review for libgccjit