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

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

Re: make_shared and friends.

Show all headers | View raw

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

Back to comp.std.c++ | Previous | Next — Previous 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