C++ Logo

std-proposals

Advanced search

Re: Formalisation of std::get<>'s behavior with regards to concurrency

From: Dejan Milosavljevic <dmilos_at_[hidden]>
Date: Fri, 12 Jul 2019 21:27:00 +0200
... and consisted to good well known `struct` also.
or everything ( array, pair, tuple, vector-like-containers ) should be as
`struct`, regarding TS.

On Sat, Jun 8, 2019 at 1:30 PM Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi,
>
> Il 07/06/19 19:12, Francois Chabot via Std-Proposals ha scritto:
> > As far as I can tell, there is no particular reason why two threads
> > shouldn't be able to write to different fields of a `std::tuple<>`, a
> > `std::array<>` or a `std::pair<>` using `std::get<>()` concurently, yet
> > this is currently not allowed by ommision.
> >
> > Would a proposal to add language similar to
> > [container.requirements.dataraces] in order to formalize this be
> receivable?
>
> How about raising a defect? I don't see why std::get on tuple/array/pair
> shouldn't _already_ be thread-safe (given that ultimately it ends up
> accessing different subobjects).
>
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2019-07-12 14:30:09