svector
refl-cpp
| svector | refl-cpp | |
|---|---|---|
| 3 | 3 | |
| 92 | 1,015 | |
| - | - | |
| 3.8 | 0.0 | |
| 7 months ago | over 1 year ago | |
| C++ | C++ | |
| MIT License | 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.
svector
-
If you limit an std::string in a class to be < 15 characters, can you assume that any time the string is read it will stay on the stack due to SSO?
It would be possible to do a much more compact SSO, but I think they've done it this way for performance reason. E g. I've implemented a vector with SSO, and there i only have 1 byte overhead: https://github.com/martinus/svector
- GitHub - martinus/svector: Small Vector optimization
refl-cpp
-
Out of bounds memory access in V8 in Google Chrome prior to 120.0.6099.224
You'd be surprised how much friction you'd have for C++ reflection. First, since it's a custom build step, you can do a mix of custom code gen and C++ constexpr/consteval for static reflection. Here's a header-only implementation for adding compile time reflection purely within the language [1]. And v8 already does dynamic code gen as part of its build process (to generate the snapshot to speedup instantiation of the isolate). Dynamic reflection is a must since JS is a dynamic language with reflection support.
Now of course, I don't know the specific details of reflection needed for the abstractions you reference and clearly V8 is still doing some amount of manual IR generation, so it's possible it would be a substantial investment to actually retrofit those techniques into v8. One would have to do a careful analysis of historical security exploits & specific techniques and their ability to prevent to figure out if it's worth adding those abstractions (especially since there is a potential performance tradeoff as you mention). As I said, I think there's insufficient research in this area to establish a compelling body of best practices (not to take away from the contributions of the GraalJS team to this space).
[1] https://github.com/veselink1/refl-cpp
-
C++ Reflection for Component Serialization and Inspection
I’ve been using https://github.com/veselink1/refl-cpp for my recent project where i needed reflections, especially for serialization. Cant wait for c++48 and reflections in standard
- Show HN: Static reflection for C++17 (enumeration, attributes, proxies, ...)
What are some alternatives?
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
entt - Gaming meets modern C++ - a fast and reliable entity component system (ECS) and much more
Nameof C++ - Nameof operator for modern C++, simply obtain the name of a variable, type, function, macro, and enum
crunchy-bytes - C++ 17 Schema Serialization Library
small_vector - A fully featured single header library implementing a vector container with a small buffer optimization.
json - JSON for Modern C++
tomlplusplus - Header-only TOML config file parser and serializer for C++17.
scope_guard - A modern C++ scope guard that is easy to use but hard to misuse.
BLIB - Small organized collection of common code I have accumulated over the years that has amassed into a proper 2d game engine
robin-hood-hashing - Fast & memory efficient hashtable based on robin hood hashing for C++11/14/17/20
zxorm - Zach's ORM - A C++20 ORM for SQLite