Arthur O'Dwyer
Arthur O'Dwyer
> should someone tap the merge button or will it done at some point automatically? Someone should tap the merge button; but I'm not a maintainer, just an interested bystander,...
@emasab: I haven't tested #4724. At the moment, it has merge conflicts. Our working hypothesis is still that https://github.com/confluentinc/librdkafka/pull/4667 fixes a leak of one `rd_kafka_toppar_keep`. All our observations are consistent...
In #4486 I wrote: > My employer has also tentatively bisected an issue to https://github.com/confluentinc/librdkafka/commit/8e20e1ee79b188ae610aac3a2d2517f7f12dd890. We see that if we have a groupconsumer, and the broker goes down (that is,...
@trcrsired: The `next` branch seems the same as `main` in this respect. I'm talking about for example here: https://github.com/cppfastio/fast_io/blob/next/include/fast_io_dsal/impl/vector.h#L1201-L1203 IIUC, this is saying "To construct a `vector` from an iter/sentinel...
Almost. The bits I called out at first are probably fixed; but grepping for `is_trivially_relocatable`, I see a few more problems. I'm pretty sure you want this: ``` --- a/include/fast_io_dsal/impl/vector.h...
> Has it fixed? I have added into the test. Drive-by comment on the diffs in `next` branch since yesterday: `array::max_size()` should always return `N`, just like `size()` does. Your...
> proposing an is_zero_default_initialization Yes, Giuseppe D'Angelo wrote [P2782 "A type trait to detect if value initialization can be achieved by zero-filling"](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2782r0.html) (January 2023) and it got a 7–8–6–2–0 vote...
> I am still confused on what uninitialized_relocate is supposed to do @trcrsired: Ah. See [[uninitialized.relocate]/1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p1144r10.html#wording-uninitialized.relocate). `uninitialized_relocate` simply relocates a range of objects from source to destination. Before the operation...
> Why are not these uninitialized functions constexpr? These functions (`uninitialized_move` etc.) were introduced in C++17. Prior to C++20, it was impossible to manually construct or destroy objects at constexpr...
Yep, I just looked at the current `next` (after #721, i.e. 98121f646b122706652924efac24fc661935fc78), and `erase` looks fine to me now. I didn't look at anything else this time. You should consider...