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 ? That operator would ease the access of the pointee's member via "pointer to member":

I'd like to access them via   but that does not work, and I have to write   which looks awkward and unnaturally to me. --31.18.70.70 06:37, 15 December 2014 (PST)
 * You could also write or  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 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   , , , , , , , , 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)