From -138259699990578476 X-Google-Thread: 7894ca11fe,98decb90a5fd464a X-Google-Attributes: gid7894ca11fe,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news2.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!news.alt.net!frodo.cs.rpi.edu!not-for-mail From: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= Newsgroups: comp.std.c++ Subject: Re: Inconsistencies in unique_ptr and shared_ptr APIs Date: Mon, 8 Jun 2009 09:36:52 CST Organization: http://groups.google.com Lines: 95 Sender: cppmods@cs.rpi.edu Approved: stephen.clamage@sun.com Message-ID: References: NNTP-Posting-Host: netlab.cs.rpi.edu Content-Type: text/plain; charset=ISO-8859-1 To: (Usenet) Return-Path: X-Original-Date: Sun, 7 Jun 2009 23:51:17 -0700 (PDT) X-Submission-Address: std-c++@netlab.cs.rpi.edu Xref: g2news2.google.com comp.std.c++:831 On Jun 8, 4:16 am, Scott Meyers wrote: > In September 2005, Joe Gottman posted to this group about inconsistencies in the > interfaces for unique_ptr and shared_ptr that bore no apparent relationship to > their fundamental functionality (http://tinyurl.com/nmjwuu). He noted that: > - "Shared_ptr has only operator ==, operator !=, and operator <. Unique_ptr has > these three plus operator >, operator <=, and operator>=." > - Only unique_ptr has special support for arrays. > - Only shared_ptr supports const_pointer_cast, static_pointer_cast, and > dynamic_ptr_cast. > > These discrepancies are also present in the current C++0x draft (N2857), so > presumably there is a reason for them. Can somebody please explain what is is? Concerning the comparison operators I think that they are present, even though they are not individually specified in terms of effects. Note that according to [memory]/2 header synopsis *all* comparison operators are listed, just search for the block "// 20.8.13.2.7, shared_ptr comparisons:" Now it's true that [util.smartptr.shared.cmp] doesn't list the remaining four, but this is not really necessary, because [operators] does explicitly say so "In this library, whenever a declaration is provided for an operator! =, operator>, operator>=, or operator<=, and requirements and semantics are not explicitly provided, the requirements and semantics are as specified in this clause." Joe Gottman's original posting was probably true, because the remaining comparison operator where added afterwards after applying the proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf during the Sophia Antipolis meeting 2008. I have no special position whether shared_ptr should support array pointers and I'm not aware of the reasons why it currently does not support them explicitly. The suggested additions of moving casts for unique_ptr look interesting. > I'd also be interested to know why the type of the deleter is part of the type > of a unique_ptr but is not part of the type of a shared_ptr. Both smart pointer types have different use cases. Unique_ptr is the de facto replacement for auto_ptr, but it added the deleter facility to support more general deletion concepts. This should be done to allow the least necessary memory overhead which has the slight disadvantage that the deleter influences the type of unique_ptr. This disadvantage can be worked- around with by using a deleter delegating to function pointers or polymorphic functors. Shared_ptr is intentionally designed to be *only* dependent on the stored pointer of some given type, so the deleter is not part of the smart pointer type. Their are much less advantages to put the deleter into the type, because this pointer type is restricted to native pointers. This is not so for unique_ptr, which basically supports any pointer-like type, because it considers whether it's deleter provides a corresponding typedef. It is probably true, that shared_ptr could be extended like that, but no convincing arguments had been provided yet to do so. > Finally, I'd like to know why unique_ptr gets its own subsection in the standard > (20.8.12) rather than being under "Smart pointers" (20.8.13) with shared_ptr and > weak_ptr. This is a pure editorial decision and it may happen that will be restructured. Greetings from Bremen, Daniel Kr�gler -- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]