Date: Fri, 26 May 2023 16:53:50 +0200
You can have many different implementations of a thread-safe STL depending
on the requirements. It all imposes different pros and cons. To arbitrarily
choose one way of implementing thread safety would cause it to be
suboptimal in other cases, and someone could say, C++ should provide
different configurations.
Now imagine you develop a library that uses STL. How can you make sure that
it will work optimally with all those settings? You also have to implement
all possible settings? You cannot just choose, because your library may not
be compatible with other libraries with different settings. What if you
want to provide only a DLL/.so and header files, but no source code?
Global switches in STL are a great way to make C++ self-incompatible.
Phil Bouchard via Std-Proposals <std-proposals_at_[hidden]> ezt írta
(időpont: 2023. máj. 25., Cs, 22:53):
>
>
> On 5/25/23 16:49, Jason McKesson via Std-Proposals wrote:
> > On Thu, May 25, 2023 at 4:18 PM Phil Bouchard <boost_at_[hidden]> wrote:
> >>
> >>
> >>
> >> On 5/25/23 16:12, Jason McKesson via Std-Proposals wrote:
> >>>
> >>> Um, no. That would break the performance of any number of applications
> >>> that don't need thread safety or have handled it properly themselves.
> >>
> >> You just turn it on or off depending on the need, defaulting to off
> >> obviously.
> >
> > Again, no. In order to make operations on the same `std::vector<int>`
> > thread-safe, every such object would have to carry some kind of
> > mutually-exclusive payload. Therefore, every such object would have to
> > carry a cost. Even if we somehow standardized the ability to switch it
> > on and off, that would break if I used a library that had a different
> > setting from the one I compile for myself. Our objects wouldn't be the
> > same objects.
>
> Ok I won't argue here but it's pretty easy to make derived thread-safe
> versions anyways. So I'll write my own versions then, thanks.
>
> --
> Logo <https://www.fornux.com/>
> *Phil Bouchard* facebook icon
> <https://www.linkedin.com/in/phil-bouchard-5723a910/>
> Founder & CEO
> T: (819) 328-4743
> E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada
>
> Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les
> documents l'accompagnant, sont destinés uniquement aux personnes
> identifiées et peuvent contenir des informations privilégiées,
> confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce
> message par erreur, veuillez le détruire.
> This communication (and/or the attachments) is intended for named
> recipients only and may contain privileged or confidential information
> which is not to be disclosed. If you received this communication by
> mistake please destroy all copies.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
on the requirements. It all imposes different pros and cons. To arbitrarily
choose one way of implementing thread safety would cause it to be
suboptimal in other cases, and someone could say, C++ should provide
different configurations.
Now imagine you develop a library that uses STL. How can you make sure that
it will work optimally with all those settings? You also have to implement
all possible settings? You cannot just choose, because your library may not
be compatible with other libraries with different settings. What if you
want to provide only a DLL/.so and header files, but no source code?
Global switches in STL are a great way to make C++ self-incompatible.
Phil Bouchard via Std-Proposals <std-proposals_at_[hidden]> ezt írta
(időpont: 2023. máj. 25., Cs, 22:53):
>
>
> On 5/25/23 16:49, Jason McKesson via Std-Proposals wrote:
> > On Thu, May 25, 2023 at 4:18 PM Phil Bouchard <boost_at_[hidden]> wrote:
> >>
> >>
> >>
> >> On 5/25/23 16:12, Jason McKesson via Std-Proposals wrote:
> >>>
> >>> Um, no. That would break the performance of any number of applications
> >>> that don't need thread safety or have handled it properly themselves.
> >>
> >> You just turn it on or off depending on the need, defaulting to off
> >> obviously.
> >
> > Again, no. In order to make operations on the same `std::vector<int>`
> > thread-safe, every such object would have to carry some kind of
> > mutually-exclusive payload. Therefore, every such object would have to
> > carry a cost. Even if we somehow standardized the ability to switch it
> > on and off, that would break if I used a library that had a different
> > setting from the one I compile for myself. Our objects wouldn't be the
> > same objects.
>
> Ok I won't argue here but it's pretty easy to make derived thread-safe
> versions anyways. So I'll write my own versions then, thanks.
>
> --
> Logo <https://www.fornux.com/>
> *Phil Bouchard* facebook icon
> <https://www.linkedin.com/in/phil-bouchard-5723a910/>
> Founder & CEO
> T: (819) 328-4743
> E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada
>
> Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les
> documents l'accompagnant, sont destinés uniquement aux personnes
> identifiées et peuvent contenir des informations privilégiées,
> confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce
> message par erreur, veuillez le détruire.
> This communication (and/or the attachments) is intended for named
> recipients only and may contain privileged or confidential information
> which is not to be disclosed. If you received this communication by
> mistake please destroy all copies.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2023-05-26 14:54:02