From e18d1c09bd7125d2da7ccd7ac6edf2a633058212 Mon Sep 17 00:00:00 2001 From: HKalbasi <45197576+HKalbasi@users.noreply.github.com> Date: Sat, 2 Sep 2023 18:28:28 +0330 Subject: [PATCH] Update how_it_compares.md --- book/src/how_it_compares.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/book/src/how_it_compares.md b/book/src/how_it_compares.md index 100334e..063baea 100644 --- a/book/src/how_it_compares.md +++ b/book/src/how_it_compares.md @@ -1,21 +1,21 @@ # How it compares to other tools? -Zngur is not the only tool in the Rust/C++ interoperability space. It's pros and cons relative to other popular tools are described -in this page. +Zngur is not the only tool in the Rust/C++ interoperability space. Its pros and cons relative to other popular tools are described +on this page. ## CXX CXX says: -> Be aware that the design of this library is intentionally restrictive and opinionated! It isn't a goal to be powerful enough to handle arbitrary signatures in either language. Instead this project is about carving out a reasonably expressive set of functionality about which we can make useful safety guarantees today and maybe extend over time. +> Be aware that the design of this library is intentionally restrictive and opinionated! It isn't a goal to be powerful enough to handle arbitrary signatures in either language. Instead, this project is about carving out a reasonably expressive set of functionality about which we can make useful safety guarantees today and maybe extend over time. -Zngur also makes safety guarantees, but also tries to be powerful enough to handle arbitrary signatures from Rust code. And we believe +Zngur also makes safety guarantees but also tries to be powerful enough to handle arbitrary signatures from Rust code. And we believe Rust types are expressive enough so that there is no need to support C++ types in Rust. For example, instead of defining a C++ opaque type and using it in Rust by an `UniquePtr`, you can define the behavior of that type in a Rust normal trait, implement that trait for your C++ type, and then convert that type into a `Box` and use it in Rust. Zngur benefits over CXX are: - Zngur supports owning Rust variables on the C++ stack, saving some unnecessary allocations. -- CXX has a limited support for some types in the standard library, but Zngur supports almost everything (`Vec`, `Vec>`, `HashMap`, +- CXX has limited support for some types in the standard library, but Zngur supports almost everything (`Vec`, `Vec>`, `HashMap`, `Box<[T]>`, `Arc`, ...) with almost full API. - Zngur keeps the Rust side clean and normal, moving all glue code in the C++ side. But using CXX you will see the foreign types and glue codes in both languages. @@ -38,14 +38,14 @@ for your C++ type, and then convert that type into a `Box` and use it ## AutoCXX -AutoCXX is different. It also tries to be powerful enough to handle arbitrary signatures, but from C++ code. It does a nice job, but due +AutoCXX is different. It also tries to be powerful enough to handle arbitrary signatures but from C++ code. It does a nice job, but due the fundamental difference between Rust and C++, it has several drawbacks: - It wraps every function result that is not behind a reference in a `UniquePtr`, which has both performance and ergonomic costs. - Every potentially mutable reference (`&mut`, `Box`, ...) should be wrapped in a `Pin`, similar to CXX. - It has poor support for templates, though it might be temporary and an ideal AutoCXX might fix some of its problems with template. -So, an auto generated binding for a C++ library using AutoCXX is not an idiomatic and ergonomic Rust. So unless you are writing a very little +So, an auto-generated binding for a C++ library using AutoCXX is not an idiomatic and ergonomic Rust. So unless you are writing a very little amount of Rust code, or can tolerate `UniquePtr` and `Pin` to be propagated in your Rust code, you will need to write a Rustic wrapper for your C++ classes. This is even recommended in the AutoCXX docs: @@ -59,8 +59,8 @@ in C++ that operate on Rust types. Using those, you should be able to create idi Idiomatic C++ and idiomatic Rust are like night and day, so a glue code between them must exist. The difference between Zngur and AutoCXX is that using AutoCXX that glue code will live in Rust and using Zngur it will live in C++. By writing the glue code in C++, you will become able to -construct C++ objects in stack without a macro, calling their move and copy constructors using `=` operator, and ... without hitting any major -problem in using Rust types. +construct C++ objects in the stack without a macro, calling their move and copy constructors using `=` operator, and ... without hitting any major +problems in using Rust types. -All being said, if you want to have fully auto generated bindings for both sides, nothing will prevent you from using Zngur and AutoCXX at the same +All being said, if you want to have fully auto-generated bindings for both sides, nothing will prevent you from using Zngur and AutoCXX at the same time.