Comments and discussion on ptr_to_unique

[make-cpp-nice]

Please post here any feedback, comments or observations. Just a comment to say you are making use of it would be very valued. If you have any suggestions for improving it, please discuss it here first.

You will have to log in to GitHub before posting.

[Quuxplusone]

Hi John, I sent you this in reply to your std-proposals thread(s), but you never acknowledged receipt.

My initial reaction was the same as the list's in general: "Don't you just want shared_ptr + weak_ptr?" But it sounds like you're at least aware of the general landscape (which is more than can be said for even some regular list participants), so that's nice. :) It's possible that you have programmed something that is useful but that it's just the naming that is muddying the waters, and picking better names for the building blocks might suddenly unstick some of the critique.

So I went back to look at your GitHub repo: https://github.com/make-cpp-nice/ptr_to_unique/tree/main
and gave it a very superficial glance.

The glaring omission there is that you have no test cases. An English-prose README is no substitute for an actual "tests.cpp" file! Please add some tests showing expected usage; both "happy path" and "sad path"/"corner case" examples.

I wonder if you're aware of boost::local_shared_ptr<T>.
https://www.boost.org/doc/libs/1_87_0/libs/smart_ptr/doc/html/smart_ptr.html#local_shared_ptr
It's not the same as what you're describing (IIUC), but it's prior art for a thing that is "like a shared_ptr, but without the expensive thread-safety." Perhaps you can use an analogy to local_shared_ptr to ease the explanation, in the English prose and/or in your choice of name for the thing.

In the code, you explain that "cbx" stands for "ctrl block conneXion"; but is a "connexion" perhaps the same thing as a "handle" and/or a "pointer", or what is it?
And you never explain what "xnr" stands for.

Bikeshed: The comparisons against raw pointer seem unmotivated and unusual. Generally we provide (a == b) only when a and b come from the same domain, i.e. when a can be implicitly converted to b and/or vice versa. For example, we provide (p == nullptr) for std::unique_ptr, and we provide (optx == x) for std::optional, and we provide (s == charptr) for std::string, but we do not provide (p == rawptr) for std::unique_ptr nor (vec == integer) for std::vector<int>. (Despite the fact that std::unique_ptr<T>(rawptr) and std::vector<int>(42) are both legal as explicit conversions. But the conversions are explicit and the operator==s do not exist precisely because the two sides come from different domains.)

Another (relatively minor) omission is that you never say what versions of C++ this code is supposed to work for. It clearly isn't intended as idiomatic C++20, because of the pre-C++20 treatment of operator!=; but is it supposed to be safe to use in C++20, or should I expect that it produces ambiguous overload resolutions etc. in C++20 and later? Vice versa, can it be used unmodified in C++14? C++11? This could go in the first sentence of the README. Alternatively, it could be implied by the set(s) of build flags used in your test suite and/or CI, if you had a test suite and/or CI.

Cheers,
Arthur

[make-cpp-nice]

Hi Arthur,

Thanks for your comments and advice.

You wrote: “The glaring omission there is that you have no test cases. An English-prose README is no substitute for an actual "tests.cpp" file! Please add some tests showing expected usage; both "happy path" and "sad path"/"corner case" examples. ”

A tests.cpp is a bit of a challenge for a need that usually occurs in an event driven GUI application but I'm working on it. I do have a Windows application that gives ptr_to_unique a good thrashing but the code is untidy and uses an early prototype of a GUI interface I've been developing. Although it works very well, it somehow doesn't feel presentable - looking for the relevant code would not be easy. It needs to be something that people can more easily see and perhaps get exited about.

You mentioned names: This where it is hard to get out of my own bubble especially on internals. What everyone calls a control block I was calling a reference counted validity flag because that was how I saw it.
The names ptr_to_unique, notify_ptrs and notifying_unique_ptr aren't pretty. I've been through several iterations of what to call things. I settled for names that are uniquely descriptive. I am open to suggestions but I won't get any until people see what it is for.
Yes “cbx” is a lazy prototyping non-name. I'm not sure what to call it though. It is a kind of specialised smart pointer so that there is a class that embraces construction and destruction of the control block as well as its actions that isn't templated.

On the comparison with a raw pointer. I can see how shared_ptr and unique_ptr should not be compared because they should never point at the same object. But a raw pointer can point at the same object as a unique_ptr or ptr_to_unique, there are good reasons to want to know if it does and I don't see any way it can be dangerous.

I think it will work from C ++ 11 onwards – that was the enabling version. Definitely C++ 14 and I use it in C++20.

I don't feel entirely qualified to make the decision between lean and mean or adding a tiny bit more overhead to catch non threadsafe use with an exception. Everyone is concerned about thread safety. As an engineer I would say that if the cast of safety is low and the consequences of not having it can be grave then pay and have it. But not all those who scrutinise it will be engineers, some of them will be lawyers. I don't know how they will see paying for something you hope to never use.

Again, as an engineer, I think C++ should take a look at other engineering fields like car design. At first all the focus was on getting them to work by whatever means but once they were out in the world being used by everybody, accidents started to happen and it got ugly. So efforts started to make them safer. Now you can't sell a car if it doesn't a range of established safety features that you hope to never use. Cars still perform very well. I see the same evolution occurring with C++.

Anyway the only thing I can find to lever the lawyers with is bounds checking – if you write your code correctly it is redundant. So that should be a foot in the door,

I now have some work to do.

Cheers and thanks for taking time to look at this. ,

John.

[make-cpp-nice]

Hi Arthur, I'm sorry I missed your e-mail. I've been following the public list rather than my e-mail. I'm going to take some time to digest what you have said before replying but I will answer one question straightaway xnr comes from an article I published on the The Code Project in 2014 called XONOR pointers: eXclusive Ownership & Non Owning Reference pointers - written before I had access to unique_ptr or R-value references https://www.codeproject.com/Articles/26068/XONOR-pointers-eXclusive-Ownership-Non-Owning-Refe I used xnr as a namespace. It is an abbreviation of XONOR and the three letters type easy. I have never seen anyone else use it in 10 years so I've stuck with it. I would rather be able to write std:: Cheers, John.

…

________________________________ From: Quuxplusone ***@***.***> Sent: Monday, February 24, 2025 11:09 PM To: make-cpp-nice/ptr_to_unique ***@***.***> Cc: Make C++ nice ***@***.***>; Author ***@***.***> Subject: Re: [make-cpp-nice/ptr_to_unique] Comments and discussion on ptr_to_unique (Discussion #1) Hi John, I sent you this in reply to your std-proposals thread(s), but you never acknowledged receipt. My initial reaction was the same as the list's in general: "Don't you just want shared_ptr + weak_ptr?" But it sounds like you're at least aware of the general landscape (which is more than can be said for even some regular list participants), so that's nice. :) It's possible that you have programmed something that is useful but that it's just the naming that is muddying the waters, and picking better names for the building blocks might suddenly unstick some of the critique. So I went back to look at your GitHub repo: https://github.com/make-cpp-nice/ptr_to_unique/tree/main and gave it a very superficial glance. The glaring omission there is that you have no test cases. An English-prose README is no substitute for an actual "tests.cpp" file! Please add some tests showing expected usage; both "happy path" and "sad path"/"corner case" examples. I wonder if you're aware of boost::local_shared_ptr<T>. https://www.boost.org/doc/libs/1_87_0/libs/smart_ptr/doc/html/smart_ptr.html#local_shared_ptr It's not the same as what you're describing (IIUC), but it's prior art for a thing that is "like a shared_ptr, but without the expensive thread-safety." Perhaps you can use an analogy to local_shared_ptr to ease the explanation, in the English prose and/or in your choice of name for the thing. In the code, you explain that "cbx" stands for "ctrl block conneXion"; but is a "connexion" perhaps the same thing as a "handle" and/or a "pointer", or what is it? And you never explain what "xnr" stands for. Bikeshed: The comparisons against raw pointer<https://github.com/make-cpp-nice/ptr_to_unique/blob/main/ptr_to_unique.h#L598-L617> seem unmotivated and unusual. Generally we provide (a == b) only when a and b come from the same domain, i.e. when a can be implicitly converted to b and/or vice versa. For example, we provide (p == nullptr) for std::unique_ptr, and we provide (optx == x) for std::optional, and we provide (s == charptr) for std::string, but we do not provide (p == rawptr) for std::unique_ptr nor (vec == integer) for std::vector<int>. (Despite the fact that std::unique_ptr<T>(rawptr) and std::vector<int>(42) are both legal as explicit conversions. But the conversions are explicit and the operator==s do not exist precisely because the two sides come from different domains.) Another (relatively minor) omission is that you never say what versions of C++ this code is supposed to work for. It clearly isn't intended as idiomatic C++20, because of the pre-C++20 treatment of operator!=; but is it supposed to be safe to use in C++20, or should I expect that it produces ambiguous overload resolutions etc. in C++20 and later? Vice versa, can it be used unmodified in C++14? C++11? This could go in the first sentence of the README. Alternatively, it could be implied by the set(s) of build flags used in your test suite and/or CI, if you had a test suite and/or CI. Cheers, Arthur — Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AX3TWQ5GWQWMC7GCOMPAUXL2ROKBPAVCNFSM6AAAAABR7UNT3WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMZQGYYDENY>. You are receiving this because you authored the thread.

[Quuxplusone]

A tests.cpp is a bit of a challenge for a need that usually occurs in an event driven GUI application but I'm working on it. I do have a Windows application that gives ptr_to_unique a good thrashing but the code is untidy and uses an early prototype of a GUI interface I've been developing.

By "tests," I mean something like https://github.com/llvm/llvm-project/tree/main/libcxx/test/std/utilities/smartptr/unique.ptr or https://github.com/Quuxplusone/SG14/tree/master/test . The idea is to make sure that each member of the class's API behaves the way you expect, e.g.

static_assert(!std::is_copy_constructible_v<xnr::pointer_to_unique<int>>);
static_assert(std::is_move_constructible_v<xnr::pointer_to_unique<int>>);
int main() {
  xnr::pointer_to_unique<int> p;
  assert(p == nullptr);
}

and so on.

On the comparison with a raw pointer [...] a raw pointer can point at the same object as a unique_ptr or ptr_to_unique, there are good reasons to want to know if it does and I don't see any way it can be dangerous.

It's not a question of "danger," except in the moral-hazard sense that mixing up what type you're dealing with can be dangerous. Removing the ability to write (smartp == rawp) doesn't at all prevent people from writing (smartp.get() == rawp) if that's what they really intend. But it does require people to write the comparison in that more verbose way, in the same way that they have to write smartp = ptr_to_unique<int>(rawp); or smartp.reset(rawp); instead of smartp = rawp; if that's what they really intend. It's just a way of improving the type-safety of the code.