Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Jason McKesson <jmckesson@gmail.com> |
|---|---|
| Newsgroups | comp.std.c++ |
| Subject | Re: make_shared and friends. |
| Date | 2012-04-28 17:02 -0700 |
| Organization | http://groups.google.com |
| Message-ID | <17423064.271.1335555821298.JavaMail.geo-discussion-forums@vbq5> (permalink) |
| References | <5583145.28.1335476739188.JavaMail.geo-discussion-forums@ynnn35> <jnep30$d2s$1@dont-email.me> |
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>(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 ]
Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar
make_shared and friends. Jason McKesson <jmckesson@gmail.com> - 2012-04-27 11:12 -0700
Re: make_shared and friends. Daniel Krügler<daniel.kruegler@googlemail.com> - 2012-04-27 11:47 -0700
Re: make_shared and friends. Jason McKesson <jmckesson@gmail.com> - 2012-04-28 17:02 -0700
Re: make_shared and friends. Daniel Krügler <daniel.kruegler@googlemail.com> - 2012-04-29 23:59 -0700
Re: make_shared and friends. Jason McKesson <jmckesson@gmail.com> - 2012-05-01 11:29 -0700
Re: make_shared and friends. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-05-02 11:11 -0700
Re: make_shared and friends. Daniel Krügler <daniel.kruegler@googlemail.com> - 2012-05-02 11:12 -0700
Re: make_shared and friends. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-04-28 17:00 -0700
csiph-web