On Tue, 22 Jun 2021 at 17:03, Matthias Kretz wrote:
>
> On Dienstag, 22. Juni 2021 17:20:41 CEST Jonathan Wakely wrote:
> > On Tue, 22 Jun 2021 at 14:21, Matthias Kretz wrote:
> > > This does a try_lock on all lockabes even if any of them fails. I think
> > > that's
> > > not only more expensive
On Dienstag, 22. Juni 2021 17:20:41 CEST Jonathan Wakely wrote:
> On Tue, 22 Jun 2021 at 14:21, Matthias Kretz wrote:
> > This does a try_lock on all lockabes even if any of them fails. I think
> > that's
> > not only more expensive but also non-conforming. I think you need to defer
> > locking
On Tue, 22 Jun 2021 at 14:21, Matthias Kretz wrote:
> On Tuesday, 22 June 2021 14:51:26 CEST Jonathan Wakely wrote:
> > With your suggestion
> > to also drop std::tuple the number of parameters decides which
> > function we call. And we don't instantiate std::tuple. And we can also
> > get rid of
On Tuesday, 22 June 2021 14:51:26 CEST Jonathan Wakely wrote:
> With your suggestion
> to also drop std::tuple the number of parameters decides which
> function we call. And we don't instantiate std::tuple. And we can also
> get rid of the __try_to_lock function, which was only used to deduce
>
On Tue, 22 Jun 2021 at 10:07, Matthias Kretz wrote:
>
> On Monday, 21 June 2021 19:31:59 CEST Jonathan Wakely via Gcc-patches wrote:
> > +// Lock the last element of the tuple, after all previous ones are
> > locked. +template
> > + inline __enable_if_t<_Idx + 1 ==