Date: Mon, 11 Nov 2019 17:30:37 -0700
I just realized that I did a reply rather than a reply-all, so here was my reply to Jorg.
Howdy,
Excellent questions. My notion was twofold:
1) The use of std::non_owned_ptr<T> clearly declares intent and usage. I am fine with all the situations you mentioned.
2) The primary goal was to make the use of delete yield a compile time error.
3) Yes, experience yields wisdom. Due to the addition of earlier templates, C++ is getting close to solving a very old C problem: T* can mean a lot of different things! Introducing the templates allows us to examine/control how those templates should be combined!
As to the large body of code, I have no desire to break it. Only to offer a notion as to how newer code can be better. It seems I am far from the first to have this particular notion.
I hope I have answered your questions..
Thank you and be well!
From: Jorg Brown <jorg.brown_at_[hidden]>
Sent: Monday, November 11, 2019 01:02
To: std-proposals_at_[hidden]
Cc: Steve Weinrich <weinrich.steve_at_[hidden]>
Subject: Re: [std-proposals] non_owned_ptr
For the sake of market research, are you wanting this pointer because:
(1) You want to be sure you don't accidentally invoke pointer arithmetic?
(1a) accidental *ptr++ when you meant (*ptr)++
(1b) accidental ptr += when you meant (*ptr) +=
(2) You want to block yourself from accidentally assigning to the pointer?
(2a) accidental ptr = 0 when you meant (*ptr) = 0
(2b) accidental ptr = false when you meant (*ptr) = false
(3) You'd like to use reset() and get() on the pointer, for purposes of generic code?
(4) You'd like to pass a shared_ptr or unique_ptr or raw pointer to a routine, without having to worry about whether you need to call get() or not.
(4a) current workaround is to pass &*ptr to the function...
(5) You prefer a coding style where you never have raw pointers?
= - = - = - =
Me personally, I think there's a very large body of code where a given pointer has a unique owner, a fairly-well-defined lifetime, and then a bunch of code that uses the data pointed to by that pointer. Furthermore, these situations occur often with data that isn't heap allocated, that is, a stack object or an object that is encapsulated in some bigger object.
But we all know that shared_ptr is expensive, especially in a multi-threaded context, because of reference counting and mutex acquisition etc.
So I guess what I'm saying is, I want to be able to have just the "weak_ptr"-like functionality of shared_ptr... and to be able to attach it to any class... either:
(A) just like weak_ptr for shared_ptr, with all the weak_ptr objects being protected by atomic operations so that if the object is deleted in one thread, it can be detected in the other,
OR
(b) except that any attempt to use a weak_ptr when its pointer has gone would check-fail. For bonus points, it should be ifdef'd in such a way that I can turn it all into straight pointer semantics once I'm convinced all the lifetime issues have been taken care of.
std::allocate_shared, called with a do-nothing allocator, is nearly perfect for this use case.
= - = - = - =
This is the bane of experience: A new C++ programmer can implement non_owned_ptr in a day. An experienced programmer sees the plurality of options, and comes back after a week with questions rather than code.
-- Jorg
On Sun, Nov 10, 2019 at 7:45 PM Steve Weinrich via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote:
I was thinking that a non_owned_ptr would be a good std addition. The idea is to formalize the current convention of using raw pointers to represent transient pointers (transient_ptr might be a better name).
Aside from a lot of details, it would simply be a template wrapper around a raw pointer. On destruction, the wrapper would do nothing.
This would allow the enforcement of the intended behavior.
What do you all think?
Howdy,
Excellent questions. My notion was twofold:
1) The use of std::non_owned_ptr<T> clearly declares intent and usage. I am fine with all the situations you mentioned.
2) The primary goal was to make the use of delete yield a compile time error.
3) Yes, experience yields wisdom. Due to the addition of earlier templates, C++ is getting close to solving a very old C problem: T* can mean a lot of different things! Introducing the templates allows us to examine/control how those templates should be combined!
As to the large body of code, I have no desire to break it. Only to offer a notion as to how newer code can be better. It seems I am far from the first to have this particular notion.
I hope I have answered your questions..
Thank you and be well!
From: Jorg Brown <jorg.brown_at_[hidden]>
Sent: Monday, November 11, 2019 01:02
To: std-proposals_at_[hidden]
Cc: Steve Weinrich <weinrich.steve_at_[hidden]>
Subject: Re: [std-proposals] non_owned_ptr
For the sake of market research, are you wanting this pointer because:
(1) You want to be sure you don't accidentally invoke pointer arithmetic?
(1a) accidental *ptr++ when you meant (*ptr)++
(1b) accidental ptr += when you meant (*ptr) +=
(2) You want to block yourself from accidentally assigning to the pointer?
(2a) accidental ptr = 0 when you meant (*ptr) = 0
(2b) accidental ptr = false when you meant (*ptr) = false
(3) You'd like to use reset() and get() on the pointer, for purposes of generic code?
(4) You'd like to pass a shared_ptr or unique_ptr or raw pointer to a routine, without having to worry about whether you need to call get() or not.
(4a) current workaround is to pass &*ptr to the function...
(5) You prefer a coding style where you never have raw pointers?
= - = - = - =
Me personally, I think there's a very large body of code where a given pointer has a unique owner, a fairly-well-defined lifetime, and then a bunch of code that uses the data pointed to by that pointer. Furthermore, these situations occur often with data that isn't heap allocated, that is, a stack object or an object that is encapsulated in some bigger object.
But we all know that shared_ptr is expensive, especially in a multi-threaded context, because of reference counting and mutex acquisition etc.
So I guess what I'm saying is, I want to be able to have just the "weak_ptr"-like functionality of shared_ptr... and to be able to attach it to any class... either:
(A) just like weak_ptr for shared_ptr, with all the weak_ptr objects being protected by atomic operations so that if the object is deleted in one thread, it can be detected in the other,
OR
(b) except that any attempt to use a weak_ptr when its pointer has gone would check-fail. For bonus points, it should be ifdef'd in such a way that I can turn it all into straight pointer semantics once I'm convinced all the lifetime issues have been taken care of.
std::allocate_shared, called with a do-nothing allocator, is nearly perfect for this use case.
= - = - = - =
This is the bane of experience: A new C++ programmer can implement non_owned_ptr in a day. An experienced programmer sees the plurality of options, and comes back after a week with questions rather than code.
-- Jorg
On Sun, Nov 10, 2019 at 7:45 PM Steve Weinrich via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote:
I was thinking that a non_owned_ptr would be a good std addition. The idea is to formalize the current convention of using raw pointers to represent transient pointers (transient_ptr might be a better name).
Aside from a lot of details, it would simply be a template wrapper around a raw pointer. On destruction, the wrapper would do nothing.
This would allow the enforcement of the intended behavior.
What do you all think?
-- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2019-11-11 18:32:57