Date: Tue, 25 Feb 2025 20:59:32 +0000
Hi Simon,
It is a discussion that needs to be had and is being had. There is talk of making subscript array access bounds checked by default. That is paying for what you don't use (if you code correctly) just to get safety (a slap on the wrist) if you don't . The need for safety has become a more anxious issue and the hit on performance is low. That is why cars have airbags. They didn't used to when we were strongly focused on just getting them to work but then after lots of accidents with them we became focused on making them safe. The same with C++.
This isn't the place to have a defining discussion on this but it is correct to acknowledge that it is there and make reference to it when assessing this proposal, its design priorities and safety obligations.
Cheers,
John.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Simon Schröder via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, February 25, 2025 7:11 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Simon Schröder <dr.simon.schroeder_at_[hidden]>
Subject: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership
On Feb 24, 2025, at 11:02 PM, JOHN MORRISON via Std-Proposals <std-proposals_at_[hidden]> wrote:
The motivation isn't better performance than shared_ptr but I don't want it substantially worse either. It is going to be used to optimize painting routines so they don't cause screen lag. I suspect that setting and testing locks may have more latency and there can be a lockout on the GUI thread if a lock get hit.
I can confirm that this is really important in GUI programming. If you are drawing a 1000 objects on screen, you cannot acquire a lock for each of them during painting. You’ll never get a responsive UI this way.
I guess the major discussion should be a meta-discussion. What do we prioritize in C++:
* thread safety?
* or the zero overhead principle (you don’t pay for what you don’t use)?
Is the zero overhead principle not a major thing in C++ anymore? Does it not get trumped by the safety discussion? Is C++ not classical C++ anymore? (I don’t really know.)
This discussion about a general direction of C++ should inform the implementation of ptr_to_unique. As long as we hold to the zero overhead principle ptr_to_unique should not check if it is running in the correct thread (by default) and should definitely not use locking (by default). I already suggested to have a template parameter which can select between safety and performance. The question is then what should be the default. Should we opt out to get zero overhead? Or is zero overhead the default and we opt in to safety? Can we use profiles which change the default?
It is a discussion that needs to be had and is being had. There is talk of making subscript array access bounds checked by default. That is paying for what you don't use (if you code correctly) just to get safety (a slap on the wrist) if you don't . The need for safety has become a more anxious issue and the hit on performance is low. That is why cars have airbags. They didn't used to when we were strongly focused on just getting them to work but then after lots of accidents with them we became focused on making them safe. The same with C++.
This isn't the place to have a defining discussion on this but it is correct to acknowledge that it is there and make reference to it when assessing this proposal, its design priorities and safety obligations.
Cheers,
John.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Simon Schröder via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, February 25, 2025 7:11 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Simon Schröder <dr.simon.schroeder_at_[hidden]>
Subject: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership
On Feb 24, 2025, at 11:02 PM, JOHN MORRISON via Std-Proposals <std-proposals_at_[hidden]> wrote:
The motivation isn't better performance than shared_ptr but I don't want it substantially worse either. It is going to be used to optimize painting routines so they don't cause screen lag. I suspect that setting and testing locks may have more latency and there can be a lockout on the GUI thread if a lock get hit.
I can confirm that this is really important in GUI programming. If you are drawing a 1000 objects on screen, you cannot acquire a lock for each of them during painting. You’ll never get a responsive UI this way.
I guess the major discussion should be a meta-discussion. What do we prioritize in C++:
* thread safety?
* or the zero overhead principle (you don’t pay for what you don’t use)?
Is the zero overhead principle not a major thing in C++ anymore? Does it not get trumped by the safety discussion? Is C++ not classical C++ anymore? (I don’t really know.)
This discussion about a general direction of C++ should inform the implementation of ptr_to_unique. As long as we hold to the zero overhead principle ptr_to_unique should not check if it is running in the correct thread (by default) and should definitely not use locking (by default). I already suggested to have a template parameter which can select between safety and performance. The question is then what should be the default. Should we opt out to get zero overhead? Or is zero overhead the default and we opt in to safety? Can we use profiles which change the default?
Received on 2025-02-25 20:59:36