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


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

Re: make_shared and friends.

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>

Show all headers | View raw


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 | 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