New C++ FIDL bindings are here (an update on LLCPP)
Yifei Teng
~ You may ignore if you don't write C++ ~
TLDR: We've added safe and ergonomic data types to the LLCPP FIDL bindings, and documented them. The combination is now called new C++ bindings.
The generated FIDL types in LLCPP, called "wire types'', aren't very easy to use: they're optimized for low-level, allocation-sensitive contexts (that's where the name "low-level C++ bindings'' originated). We've since introduced higher level, ergonomics focused generated types, called "natural types" or "natural domain objects", as well as client and server APIs that speak those types.
With this addition, LLCPP is no longer "low-level". It is now renamed to ✨ new C++ FIDL bindings ✨.
(You may have heard the name "unified C++ bindings" tossed around; that's what this used to be called but it didn't make the most sense hence this rebranding)
Check out the fuchsia.dev tutorials for more details on how to use them. As part of documenting the natural types we've revamped the wire types tutorials too!
More about the natural domain objects
The natural types embrace std:: containers and idioms. For example, a table is represented as a collection of std::optional<Field>s. A vector is std::vector<T>, etc. They also implement idiomatic C++ moves and copies and equality: a value type will be copyable, while a resource type is only movable.
If you've been using HLCPP in-tree, you're encouraged to switch to the new C++ bindings
- Using servers and clients from multiple threads is supported in a principled way.
- Client calls can turn into fpromise:: promises, easily avoid callback hell.
- Know exactly which async call failed, better error logging and error handling.
- Fallible operations are represented using fitx::result, playing nice with Fuchsia C++ at large.
If you've been using LLCPP, consider using the natural domain objects
The natural types own their children so you could move them around and return them from functions without worrying about lifetimes. The wire types (what you're likely using today) use unsafe borrowing hence are prone to use-after-frees. If you've been bothered by these errors or have written boilerplate to extend wire object lifetimes, switching to the natural domain objects in targeted places has the potential to simplify code.
Other minor mechanical things
When you use the wire types the FIDL library dependency used to have a suffix "_llcpp". As part of the rename, the build dependency suffix will become "_cpp_wire". You can use that suffix today and we'll migrate the rest.
Similarly, the header include pattern will become #include <lib/fidl/cpp/wire/…>. You can use that include pattern today.
Next steps in new C++ FIDL bindings
Fully support out-of-tree usage. Tracked by fxb/80525 (wire types) and fxb/92356 (natural types) respectively.
Cheers,
Yifei
Shai Barack
--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to announce+u...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/announce/CANbn4XBaBCfBQWU5KE9O5vcbpzBdj--0JdH9jh0jaz1%3DP%2B0mgA%40mail.gmail.com.
Suraj Malhotra
--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "fidl-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fidl-dev+u...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/fidl-dev/CANbn4XBaBCfBQWU5KE9O5vcbpzBdj--0JdH9jh0jaz1%3DP%2B0mgA%40mail.gmail.com.
Devon H. O'Dell
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/fidl-dev/CAFFy6-Be7jNEU3kgP521nZvPTkCAPLwy%2BYu52D4e2r75jXJc%2Bg%40mail.gmail.com.
Yifei Teng
Really happy to see this. Does this announcement mean that HLCPP usage is defacto deprecated (at least in tree)? Are there any plans to limit new usages via an allow list?
Ian McKellar
On Thursday, July 28, 2022 at 3:00:32 PM UTC-7 Suraj Malhotra wrote:Really happy to see this. Does this announcement mean that HLCPP usage is defacto deprecated (at least in tree)? Are there any plans to limit new usages via an allow list?+ian...@google.com is planning to circulate an RFC to discuss these plans.