Talk:cpp/memory/shared ptr

For some reason, in the "Implementation Notes" section, the link to "allocate_shared" links to "http://en.cppreference.com/w/cpp/memory/shared_ptr/allocate_sharod", both on hover, copy, and click. Looking at the markup, the referred-to page-name looks correctly spelt... I don't get it. Manually going to http://en.cppreference.com/w/cpp/memory/shared_ptr/allocate_shared works.

It's a typo in MediaWiki:Simple-search-list and MediaWiki:Geshi-keyword-list-cpp, User:P12 can fix that. --Cubbi 11:45, 6 June 2012 (PDT)

Fixed. Thanks. -- P12 13:01, 6 June 2012 (PDT)

missing operator->*

Is there a reason why shared_ptr does not overload operator->*? That operator would ease the access of the pointee's member via "pointer to member":

I'd like to access them via shp->*member but that does not work, and I have to write (*shp).*member which looks awkward and unnaturally to me. --31.18.70.70 06:37, 15 December 2014 (PST)

You could also write shp.get()->*member or (&*shp)->*member if you want the correct operator to be called. Some early smart pointers overloaded ->*, but the boost implementation of shared_ptr, on which C++ is based, didn't. I see it was recently brought up on stackoverflow with no conclusive answer. --Cubbi (talk) 06:50, 15 December 2014 (PST)

shared_ptr for arrays wasn't applied to WP

std::shared_ptr for arrays from libfun1 was approved by LWG to merge into C++17, but the wording didn't match up and the editor bumped this part back to LWG for a more precise wording.. Should we undo the changes here? It's pretty certain it will be part of C++17 since it passed all approvers, it was just a merge conflict. (note; the changes were [1][2][3][4][5], [6], [7], [8], [9], [10], [11], [12], and new pages cpp/memory/shared_ptr/operator_at and Template:cpp/memory/shared ptr/dsc operator at ) --Cubbi (talk)

Oh hm. I'm okay with leaving it here. Implementations have been running so far ahead of the standard lately that it seems like doing so will be pretty harmless. --Nate (talk) 19:44, 3 April 2016 (PDT)

looks like it's going to be applied after all (as an NB comment, I guess?): p0414r0 has the new wording. --Cubbi (talk) 20:08, 15 July 2016 (PDT)

Inconsistency about empty shared pointer

In the main page it written that "A shared_ptr may also own no objects, in which case it is called empty (an empty shared_ptr may have a non-null stored pointer if the aliasing constructor was used to create it)". and also that "The stored pointer is the one accessed by get()" So, checking if a shared pointer is empty is not equivalent to "get() != nullptr". Continued to read the documentation I found that operator bool "checks if there is associated managed object". But then, the page about operator bool says the opposite: "Checks if *this stores a non-null pointer, i.e. whether get() != nullptr".

Can one explain what I'm missing here?

Ronen --31.168.225.1 03:11, 1 December 2016 (PST)

looks like the one-liner description of operator bool should have said "stored" rather than "managed", updated. --Cubbi (talk) 06:09, 1 December 2016 (PST)

Is aliasing constructor limited to shared_ptr?

I see that the aliasing ctor is defined in the constructor (option 8), but is this concept applicable to things other than shared_ptr? Should it be its own term and defined similarly to move constructor, etc.?
ticotico (talk) 11:48, 1 November 2021 (PDT)

the only other things with aliasing constructors are things that are very much like std::shared_ptr. Besides the obvious boost::shared_ptr, first hit in my search was this gc_ptr. So it's a term, but far less notable compared to move or even converting constructors: it gets no special language treatment. --Cubbi (talk) 13:46, 1 November 2021 (PDT)