From -4947117061425200998 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.211.136 with SMTP id nc8mr16808280pbc.6.1335897000240; Tue, 01 May 2012 11:30:00 -0700 (PDT) MIME-Version: 1.0 Path: r9ni120531pbh.0!nntp.google.com!news2.google.com!goblin2!goblin1!goblin.stu.neva.ru!news.albasani.net!.POSTED!not-for-mail From: Jason McKesson Newsgroups: comp.std.c++ Subject: Re: make_shared and friends. Date: Tue, 1 May 2012 11:29:57 -0700 (PDT) Organization: http://groups.google.com Lines: 95 Sender: std-cpp-request@vandevoorde.com Approved: james.dennett@gmail.com Message-ID: <14621972.860.1335819954688.JavaMail.geo-discussion-forums@ynce8> References: <5583145.28.1335476739188.JavaMail.geo-discussion-forums@ynnn35> <17423064.271.1335555821298.JavaMail.geo-discussion-forums@vbq5> NNTP-Posting-Host: 1bm6TeNtLp0t8ISewk8qZiASYLZTOpK3UGRFAW+w888= X-Trace: news.albasani.net 5nIKjEcQLA/eP0DAZ6HqotPi/CWr6egfYHWNI3sqV9CX12MG8CXkcaCOCb9VIrvV2060RIClMQAseJ4XZPxcjA== X-Complaints-To: abuse@albasani.net NNTP-Posting-Date: Tue, 1 May 2012 18:29:59 +0000 (UTC) X-Mailer: Perl5 Mail::Internet v2.05 X-Submission-Address: std-cpp-submit@vandevoorde.com Cancel-Lock: sha1:r/0jqMMGvagqAqdmpb20hfTkAMk= X-Original-Date: Mon, 30 Apr 2012 14:05:54 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1 On Sunday, April 29, 2012 11:59:51 PM UTC-7, Daniel Kr�gler wrote: > Am 29.04.2012 02:02, schrieb Jason McKesson: > [..] > > > > 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`. > > > I don't understand your question: Surely it cannot be the > responsibility of a library implementation to enforce user code to use > some particular component. A good API makes it difficult if not impossible to do things incorrectly. And if a particular object has `enable_shared_from_this` as a base class, then it is incorrect to create an instance of that object *without* a shared_ptr. So you have to either force the user to use `make_shared` or force the user to use factory functions. Enforcing either requires the use of private constructors. > > 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. > > > I don't understand what you are trying to say here. See above. You usually enforce the use of factory functions by making constructors private. > > 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. > > > Even if some particular implementations decides to do so, this won't be > portable code anymore. Standardizing this for this special function > template would also seem very odd, a more general policy should be > considered, if needed. Extending it to `emplace` member functions wouldn't be a bad idea. > In regard to the "burden" I think you are > mislead. The guarantee that the actual code is called in a particular > location is *not* sufficient. Todays high-quality implementations of > the Standard Library usually provide a lot of static concept-checking > to ensure that user-types satisfy the requirements of the standard. > One requirement is that > > "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." > > If a static concept-checking tool attempts to validate this it won't > help that you have assigned friendship to the function: The > static-tool machinery would also require this friendship. The wording would have to be changed. That expression would be valid, but *only* within the make_shared function itself. So any concept checking (if it's still possible) would have to be done within the function, not in extra classes and so forth. > Don't feel attempted to hope that assigning friendship to types or > functions other than those under your control is a feasible approach. > In fact, you really should *know* the one, to whom you become friend > with ;-) > > > Also, allocate_shared won't help, because that's about the allocation > > of the block of memory, not the calling of the constructor. > > > Yes, the current wording is defective in this regard, but the proposed > resolution of > > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2070 > > would ensure that the allocator's construct and destroy function will > be used. gcc 4.8 has already implemented the P/R for evaluation > purposes. True, but that requires a *lot* of boilerplate to do something that ought to be very, very simple. You have to make a special allocator to be used for instances of the class, and most of its methods will just call the std::allocator function. It requires the user to use the less-well-known `allocate_shared` instead of `make_shared`. It's less idiomatic. -- [ 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 ]