node-foundationdb
pfr
node-foundationdb | pfr | |
---|---|---|
1 | 4 | |
112 | 1,268 | |
- | 1.4% | |
1.5 | 7.9 | |
6 days ago | about 1 month ago | |
TypeScript | C++ | |
GNU General Public License v3.0 or later | Boost Software License 1.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.
node-foundationdb
-
The Serde Rust Framework
Thats fantastic.
I maintain the nodejs bindings for foundationdb. Foundationdb refuses to publish a wire protocol, so the bindings are implemented as native code wrapped by n_api. The code is a rat's nest of calls to methods like `napi_get_value_string_utf8` to parse javascript objects into C. (Eg [1]). As well as being difficult to read and write, I'm sure there's weird bugs lurking somewhere in all that boilerplate code.
I'd much prefer all that code to just be in rust. That looks way easier to use than all the goopy serialization nonsense I'm doing now. (Though I'd want a serde_napi variant instead of going straight to v8).
[1] https://github.com/josephg/node-foundationdb/blob/master/src...
pfr
-
Rooting for P1061 "Structured Bindings can introduce a Pack"
This single feature opens a world of new possiblities. For example, it makes implementing "getting the number of fields" trivial. Furthrmore, and much more importantly, it enables turning a struct into a tuple. Currently, this can only be done by enumerating cases (therefore it's not fully generic), as with Boost PFR. By the way, PFR greatly simplifies our codebases, especially for parts with serialization and/or reflection.
-
Minimum viable declarative GUI in C++
The code is relatively short and can be groked with a few coffees: https://github.com/boostorg/pfr/tree/develop/include/boost/pfr ; if you're using C++17 it uses a binary search (https://github.com/boostorg/pfr/blob/develop/include/boost/pfr/detail/fields_count.hpp) to count the number of fields in a struct, by starting by the observation that a likely majorant on the number of fields in a struct is sizeof(the struct) * CHAR_BIT, assuming not too many [[no_unique_address]] tomfooleries. Then once this count is known it's possible to simply map them as a tuple through sheer brute force and destructuring: https://github.com/boostorg/pfr/blob/develop/include/boost/pfr/detail/core17_generated.hpp
-
The Serde Rust Framework
I wonder if the c++ approach of boost.pfr would be portable to rust ? It allows reflection on aggregates without needing to annotate anything: https://github.com/boostorg/pfr
-
Counting the number of fields in an aggregate in C++20
It is an 'interesting' meta-programming problem though (wasted many weeks on it myself, fixed a small gcc bug - a 'uniform init' edge case and filed an issue with magic_get Reflecting array members of aggregate structs).
What are some alternatives?
nanoserde - Serialisation library with zero dependencies
Magic Enum C++ - Static reflection for enums (to string, from string, iteration) for modern C++, work with any enum type without any macro or boilerplate code
sapio - A Bitcoin Programming Language
magic_get - std::tuple like methods for user defined types without any macro or boilerplate code
manifold - Manifold is a Java compiler plugin, its features include Metaprogramming, Properties, Extension Methods, Operator Overloading, Templates, a Preprocessor, and more.
MLV-App - All in one MLV processing app.
serde_v8 - Moved to https://github.com/denoland/deno
ComLightInterop - Cross-platform COM interop library for .NET Core 2.1 or newer
create-rust-app - Set up a modern rust+react web app by running one command.
Rocket - A web framework for Rust.
EU4ConsolePatcher - A simple memory patcher which enables the internal developer console in ironman mode