A C++ Mixin System
A proposed C++ mixin system aims to improve code organization by using Rust-like error handling, data constructors, and CRTP, though the author is uncertain about its practical implementation.
Read original article
The article discusses a proposed C++ mixin system that aims to enhance code organization and logic through the use of mixins, drawing inspiration from Rust traits and C++ concepts. The author envisions a framework that diverges from traditional C++ by adopting a Rust-like standard library approach, where errors are managed through Result<> or Option<> classes instead of exceptions. Key features of this system include the use of data constructors for object initialization, factory functions for non-trivial object creation, and a default constructor that initializes objects to a no-operation (NOP) state. The author also emphasizes the importance of assertion errors for invalid interactions with NOP objects. The mixin concept is illustrated through a Clone trait example, which includes a clone() method and compile-time assertions for interface implementation. The article further explores the Curiously Recurring Template Pattern (CRTP) to avoid virtual table overhead while allowing for polymorphic behavior. The author acknowledges that while some ideas may already exist in the C++ standard library, the proposed system could serve as a demonstration of CRTP's capabilities and provide utility for earlier C++ versions. Ultimately, the author expresses uncertainty about the practicality of implementing this system but finds the concept intriguing.
- The proposed C++ mixin system aims to enhance code organization and logic.
- It draws inspiration from Rust traits and emphasizes error handling through Result<> or Option<> classes.
- Key features include data constructors, factory functions, and a NOP state for objects.
- The Curiously Recurring Template Pattern (CRTP) is utilized to minimize virtual table overhead.
- The author finds the concept interesting but is uncertain about its practical implementation.
Related
Rewriting Rust
The author expresses frustration with Rust's slow progress and unimplemented features, proposing a fork to enhance safety and usability, while raising concerns about supply chain risks and complexity in the language.
Code Generation in Rust vs. C++26
The blog post compares code generation in Rust and upcoming C++26, focusing on reflection features. It highlights Rust's procedural macros and proposes a C++ solution using annotations for similar capabilities.
Cursed Rust
The article "Cursed Rust" humorously explores quirks of the Rust programming language, including the `Copy` and `Clone` traits, if statements as place expressions, naming conventions, and the utility of the `&*` operator.
Lessons learned from a successful Rust rewrite
The transition from C++ to Rust improved code performance and safety but revealed challenges like undefined behavior, memory management issues, and tooling limitations, highlighting the need for a stable ABI.
Speculations on arenas and custom strings in C++
The author explores arena allocation and custom strings in C++, aiming to simplify complexity by minimizing advanced features. Challenges with static initialization are noted, with proposed workarounds for compile-time construction.
- Several commenters question the necessity of mixins in C++, given the language's existing features like ad-hoc polymorphism and function templates.
- There are references to past systems and libraries, such as GNU C++ Signatures and Alexandrescu's work, indicating that similar concepts have been explored before.
- Some users express confusion about the article's content and the proposed design, suggesting it may be overly complex or not intuitive.
- Concerns about C++'s aesthetic and ergonomic issues are raised, with suggestions for improving code readability.
- Overall, there is a general sense of uncertainty regarding the mixin system's implementation and its potential benefits.
15 commentsAn interesting option in this space is rpp [1], which bills itself as a “Minimal Rust-inspired C++20 STL replacement”
A signature resembles a class declaration in that it specifies member functions. A signature is never instantiated. Rather any class which has those member functions conforms to the signature, and a signature-typed pointer can point to instances of that class. Thus signatures bring about quack-like-a-duck polymorphism not requiring inheritance.
You can just declare by convention that a freestanding clone(T x) -> T function should exist for it to be 'cloneable'.
std::optional<T&>
How does a mixin compare to role or interface in languages that do not have multiple inheritance?
void foo(auto& t) { t.bar(); }
which can be called with any class that has the .bar() method anyway.
static
auto create(const char* data) -> Result<String>
static auto
create(const char* data)
-> Result<String>
Related
Rewriting Rust
The author expresses frustration with Rust's slow progress and unimplemented features, proposing a fork to enhance safety and usability, while raising concerns about supply chain risks and complexity in the language.
Code Generation in Rust vs. C++26
The blog post compares code generation in Rust and upcoming C++26, focusing on reflection features. It highlights Rust's procedural macros and proposes a C++ solution using annotations for similar capabilities.
Cursed Rust
The article "Cursed Rust" humorously explores quirks of the Rust programming language, including the `Copy` and `Clone` traits, if statements as place expressions, naming conventions, and the utility of the `&*` operator.
Lessons learned from a successful Rust rewrite
The transition from C++ to Rust improved code performance and safety but revealed challenges like undefined behavior, memory management issues, and tooling limitations, highlighting the need for a stable ABI.
Speculations on arenas and custom strings in C++
The author explores arena allocation and custom strings in C++, aiming to simplify complexity by minimizing advanced features. Challenges with static initialization are noted, with proposed workarounds for compile-time construction.