Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c++ > #496

Re: make_shared and friends.

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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