From 2365681835377346078 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 ok7mr2646630pbb.8.1335769194180; Sun, 29 Apr 2012 23:59:54 -0700 (PDT) MIME-Version: 1.0 Path: r9ni114876pbh.0!nntp.google.com!news2.google.com!news3.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!217.73.144.44.MISMATCH!feeder.ecngs.de!ecngs!feeder2.ecngs.de!feeder.erje.net!news.albasani.net!.POSTED!not-for-mail From: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= Newsgroups: comp.std.c++ Subject: Re: make_shared and friends. Date: Sun, 29 Apr 2012 23:59:51 -0700 (PDT) Organization: A noiseless patient Spider Lines: 70 Sender: std-cpp-request@vandevoorde.com Approved: james.dennett@gmail.com Message-ID: References: <5583145.28.1335476739188.JavaMail.geo-discussion-forums@ynnn35> <17423064.271.1335555821298.JavaMail.geo-discussion-forums@vbq5> NNTP-Posting-Host: n0Dg3ojFocbbvrAWpPjnrcCSEElLyW2AWSIMleuAmQE= X-Trace: news.albasani.net DOlwHT59MvXtyzfmzXBwjkJul88Tcr1z+8bxqeFl+WEe48o6ag/bVyNPxzxgDG4QePjXG1pl3OsbelGWYSwhCA== X-Complaints-To: abuse@albasani.net NNTP-Posting-Date: Mon, 30 Apr 2012 06:59:53 +0000 (UTC) X-Mailer: Perl5 Mail::Internet v2.05 X-Submission-Address: std-cpp-submit@vandevoorde.com Cancel-Lock: sha1:r+BiIR7/BYTO56GXL8HT+622gmI= X-Original-Date: Sun, 29 Apr 2012 11:06:33 +0200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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. > 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. > 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. 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. 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. HTH & Greetings from Bremen, Daniel Kr�gler -- [ 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 ]