Got it. That's very helpful insight! std::weak_ptr and friends works for us today.--On Fri, Jan 27, 2023 at 3:16 PM Adam Barth <aba...@google.com> wrote:That's fine if the SDK libraries are prebuilt, but if they're source libraries, there's no way to prevent people from taking dependencies in supposedly "internal" namespaces. We've had to clean up examples in the past where SDK customers had taken dependencies on "internal" parts of the headers.Someday we'll have C++ modules and we can actually enforce some of these things.AdamOn Fri, Jan 27, 2023 at 8:58 PM Yifei Teng <yif...@google.com> wrote:That makes sense. Would folks consider a subset where these types are published to the SDK, but only allowed to be used by SDK libraries themselves internally? The use cases I had in mind won't expose `fxl::WeakPtr` per se to their public API -- they would internally replace the `std::weak_ptr`s with `fxl::WeakPtr`. One way I imagine this could work is to expose these types under a namespace such as `sdk_internal::`, and maybe with build allowlist/visibility support.On Fri, Jan 27, 2023 at 12:54 PM Jaeheon Yi <jae...@google.com> wrote:Thank you Brett and Adam, these are good insights to keep in mind.JaeheonOn Fri, Jan 27, 2023 at 12:51 PM 'Adam Barth' via api-council <api-c...@fuchsia.dev> wrote:--+1That's a big reason we've avoided putting FXL and FBL into the SDK up to this point.We had to go the other way with fit::function versus std::function because of our extensive use of move-only types, which don't play well with std::function's copy constructor. However, that's required a lot of ongoing investment and has posed exactly these kinds of integration costs on our customers.AdamOn Fri, Jan 27, 2023 at 8:48 PM 'Brett Wilson' via api-council <api-c...@fuchsia.dev> wrote:[I'm not on the API council so this is just some personal feedback.]I think the more our code diverges from standard C++, the more difficult it is to integrate into other projects. The two areas where big projects often start diverging (sometimes with good reason, sometimes without) is in containers and these types of memory management primitives. Once you start using code with alternate implementations of these core library primitives their use starts infecting/affecting everything else.If we want our SDK to be picked up as easily as possible by as many projects as possible, I think we should try very hard to avoid custom implementations of core library objects.Brett--On Fri, Jan 27, 2023 at 11:24 AM 'Yifei Teng' via api-council <api-c...@fuchsia.dev> wrote:Hi API Council,--What are the council's thoughts on adding `fxl::WeakPtr` to the partner SDK, or in general, the `fxl/memory` library? Looks like right now it's in the internal SDK, but I could think of at least two places where it could be useful:- In the union accessors of the new C++ bindings, to detect and assert on use-after-free.- In an upcoming async utility library, to cancel operations where the receiver has gone away.In these cases we could use `std::weak_ptr` as a substitute, so this is not strictly required, but the std versions are less efficient and the atomic operations are not necessary in single-threaded scenarios. One also need to be more careful using `std::weak_ptr` because its API support upgrading a weak pointer to a shared one and arbitrarily prolonging the lifetime, whereas `fxl::WeakPtr` guarantees deterministic destruction by the owner of the referenced object.Thanks,Yifei
You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CANbn4XDkp3zeqG1gewoxEMkc%2BPrzVTGk6g1TxgS8w4Lp4drBdA%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CABiGVV_LT%2BVCWM5e5wBgHZGw6pf%2BpawwZhxdFd0cq0ymrQHzXw%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAP%3D28ceHB5wjYC1LBjRwpOqU%2BtJKyhas5hTMqC_zjhvWcrj4YQ%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CANbn4XB%2BWQ8nSp_1R6tXCrL%3DwJFTVxDi8c2NDT7R%2BubvoSn7wg%40mail.gmail.com.
See David's original comment on why we'd want to use `fbl::RingBuffer` here: https://fuchsia-review.git.corp.google.com/c/fuchsia/+/684203/comment/c0bf135a_836263e3/. TL;DR is that we don't want to allocate memory when someone added a new report to keep allocations out of the InputReport pipeline so that report latency stays consistent.Does `deque` give us this too?
The Report object is not one-to-one equivalent to the FIDL report. Examples of Reports are here:These Reports are then translated to FIDL reports using the `ToFidlInputReport` function.On the other hand, the FIDL reports may also grow in the future as we've only implemented support for a few common HID classes.
--
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 "eng-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eng-council...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/eng-council/CANbn4XDvUva%3DBSSvhE%2BDb%3D5THGMavM0QVrC%3DJtAx2%3DUL-j%2Bq9w%40mail.gmail.com.
If we did want to include custom containers, I believe it will be best to include them in a way where they are shared (from the same source) rather than duplicate them. i.e. +1 to "Having the code copied [...] means that if/when [container] is improved, your code won't benefit."
You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAOsj%2BY%3DL8fWj6KLw870L8omYfRa_his3%3D1jdLTi5mcFYEjcozA%40mail.gmail.com.