From 2384218445744979597 X-Google-Thread: 7894ca11fe,98decb90a5fd464a X-Google-Attributes: gid7894ca11fe,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!newsfeed.stanford.edu!news.kjsl.com!news.alt.net!frodo.cs.rpi.edu!not-for-mail From: SG Newsgroups: comp.std.c++ Subject: Re: Inconsistencies in unique_ptr and shared_ptr APIs Date: Mon, 8 Jun 2009 13:20:44 CST Organization: http://groups.google.com Lines: 42 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: Mon, 8 Jun 2009 10:00:49 -0700 (PDT) X-Submission-Address: std-c++@netlab.cs.rpi.edu Xref: g2news2.google.com comp.std.c++:837 On 8 Jun., 04:16, 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? I have to agree I find this a little odd. > 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. I asked myself the same question. In addition to Daniel's points I'd like to make the following: A unique_ptr type that is "deleter- agnostic" requires some kind of dynamic memory allocation and polymorphism. For shared_ptr this is not a big issue since a reference counter needs to be allocated anyways and both, reference counter and deleter, can be combined into a single object. But for unique_ptr forcing this kind of polymorhism onto it doesn't seem like a good idea. Instead it should be optional (for example via std::function as the deleter's type). Cheers! SG -- [ 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 ]