From 1080514197960484259 X-Google-Thread: f78e5,6f5c74c3d7959916 X-Google-NewGroupId: yes X-Google-Attributes: gid7894ca11fe,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.131.71 with SMTP id ok7mr116571pbb.8.1335657732324; Sat, 28 Apr 2012 17:02:12 -0700 (PDT) MIME-Version: 1.0 Path: r9ni109992pbh.0!nntp.google.com!news1.google.com!news.glorb.com!news2.arglkargh.de!news.albasani.net!.POSTED!not-for-mail From: Jason McKesson Newsgroups: comp.std.c++ Subject: Re: make_shared and friends. Date: Sat, 28 Apr 2012 17:02:09 -0700 (PDT) Organization: http://groups.google.com Lines: 75 Sender: std-cpp-request@vandevoorde.com Approved: james.dennett@gmail.com Message-ID: <17423064.271.1335555821298.JavaMail.geo-discussion-forums@vbq5> References: <5583145.28.1335476739188.JavaMail.geo-discussion-forums@ynnn35> NNTP-Posting-Host: Px3IfCnRCoh02HimVY1OJcl0tohpv8lJketUj35wj7w= X-Trace: news.albasani.net r1wKd2ZqbUtsysYBQMF3ujQX+HsXJSSOOox1cO5FFiNdV2C2ol4iMh3XLgy90G8SBHOiujXlOkqLulu1KWt6OA== X-Complaints-To: abuse@albasani.net NNTP-Posting-Date: Sun, 29 Apr 2012 00:02:11 +0000 (UTC) X-Mailer: Perl5 Mail::Internet v2.05 X-Submission-Address: std-cpp-submit@vandevoorde.com Cancel-Lock: sha1:otbcnulisQesghyvKOSRvIaXAsE= X-Original-Date: Fri, 27 Apr 2012 12:43:41 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1 On Friday, April 27, 2012 11:47:05 AM UTC-7, Daniel Kr�gler wrote: > Am 27.04.2012 20:12, schrieb Jason McKesson: > > Does the C++11 specification allow you to say that the `make_shared` > > template is a friend, and thus guarantee that it can access the > > appropriate private constructors of a class? Yes, there is syntax that > > would make `make_shared` a friend. But does the spec *require* that > > the constructors are called directly from `make_shared` itself, since > > it cannot transfer friendship to any subsidiary object types? > > I cannot read anything from this from the specification. To the > contrary, there is a general requirement: > > "The expression ::new (pv) T(std::forward(args)...), where pv has > type void* and points to storage suitable to hold an object of type T, > shall be well formed" > > and there is nothing in the wording that allows to conclude that this > requirement is context-based. Requirements in the standard are general > context-free (The standard does not say so explicitly, but the lack of > such guarantee gives evidence for this interpretation). The wording form > used in [structure.requirements] p4 > > "Requirements are stated in terms of well-defined expressions that > define valid terms of the types that satisfy the requirements." > > and p6: > > "In some cases the semantic requirements are presented as C++ code. Such > code is intended as a specification of equivalence of a construct to > another construct, not necessarily as the way the construct must be > implemented." > > clearly indicates that implementations can use indirection techniques, > so I would strongly discourage any assumption that friendship dedication > to library components could be done portably. > > Further, there is some rewording intended due to > > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2070 > > This rewording effectively makes the semantics more general and more > indirect again. > > The only chance I see for you is to use std::allocate_shared with a > user-provided allocator where you have assigned friendship to the > construct function (I guess that one is of interest for you?) of the > allocator. > > If that does not work for you: What kind of problem are you trying to solve? > > HTH& Greetings from Bremen, > > Daniel Kr�gler It's not so much a problem as wondering how this is supposed to work. Without the ability to have `make_shared` be a friend (in a useful way), it is impossible to *force* users to use `make_shared`. You also can't effectively combine factory functions with `make_shared`. So you lose a lot of the benefits of them when dealing with factories. It shouldn't be too much of a burden on implementations to force them to do the final construction of the type within `make_shared` itself, rather than in some object they create. Also, allocate_shared won't help, because that's about the allocation of the block of memory, not the calling of the constructor. -- [ comp.std.c++ is moderated. To submit articles, try posting with your ] [ newsreader. If that fails, use mailto:std-cpp-submit@vandevoorde.com ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]