Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Daniel Krügler<daniel.kruegler@googlemail.com> |
|---|---|
| Newsgroups | comp.std.c++ |
| Subject | Re: make_shared and friends. |
| Date | 2012-04-27 11:47 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <jnep30$d2s$1@dont-email.me> (permalink) |
| References | <5583145.28.1335476739188.JavaMail.geo-discussion-forums@ynnn35> |
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 -- [ 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