Arthur O'Dwyer
Arthur O'Dwyer
I just took another close look at the code in the `master` branch, in order to update my blog post ["Who uses P2786 and P1144 trivial relocation?"](https://quuxplusone.github.io/blog/2024/06/15/who-uses-trivial-relocation/) with a `fast_io`...
> It is established convention that iterators denoting a range are passed in pairs of arguments, begin and end. Breaking that pair with another argument will be a constant source...
> Actually aren't all Boost.Containers ('platonically') trivially relocatable (simply by the fact of not being self-referential)? Yes, _if_ their components are. For example, ``` template using ShmAlloc = boost::interprocess::allocator; static_assert(!is_trivially_relocatable_v);...
That's an excellent writeup IMHO. :) Your point about how `std::hash` shouldn't be documented as a niebloid (even if some rando creates an `template inline constexpr auto myHash = std::hash()`...
@OlafvdSpek ping!
> Is the infinite recursion hit in practice though? Yes, certainly if the offending `operator!=` is ever actually called, it'll infinite-recurse. I don't know whether it's ever actually called anywhere...
The change to `.gitignore` seems superfluous; the Makefile doesn't create an `a.out`, does it? I suggest adding test cases for `explain int *restrict p` and `explain restrict int* p` (do...
> Well, it's absolutely UB, so anything can happen. [...] In release mode you won't have an assertion, but UB. Okay, so whatever the failure mode is, it's not something...
> Sorry for not replying earlier. Right, Boost can't detect this issue, so I will close the issue. And thanks for using Boost.Interprocess for your allocator_aware inplace_vector paper. Maybe I...
> This does not seem to apply, since ICU requires C++17 Right, but given that every other place uses `make_pair`; and given that `pair`'s behavior is different-and-less-desirable compared to `make_pair`,...