Topic: N2369 editorial: Needless redundant effect description in [util.smartptr.shared.create]


Author: =?iso-8859-1?q?Daniel_Kr=FCgler?= <daniel.kruegler@googlemail.com>
Date: Thu, 23 Aug 2007 16:57:51 CST
Raw View
The newly proposed make_shared and allocate_shared function templates
have a redundant effects clause in [util.smartptr.shared.create]/p.2:

"Effects: Allocates memory suitable for an object of type T and
constructs
an object in that memory via the placement new expression new (pv) T()
or
new (pv) T(std::forward<Args>(args)...).[..]"

According to variadic template syntax emptypack expansions and empty
parameter packs are feasible such that the first mentioned expression
is
already described by the second one.

Proposed resolution:

Replace above wording in [util.smartptr.shared.create]/p.2 by:

"Effects: Allocates memory suitable for an object of type T and
constructs
an object in that memory via the placement new (pv)
T(std::forward<Args>(args)...).[..]"

Greetings from Bremen,

Daniel Kr   gler


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: pete@versatilecoding.com (Pete Becker)
Date: Thu, 23 Aug 2007 22:22:02 GMT
Raw View
On 2007-08-23 12:57:51 -0400, Daniel Kr=FCgler=20
<daniel.kruegler@googlemail.com> said:

> The newly proposed make_shared and allocate_shared function templates
> have a redundant effects clause in [util.smartptr.shared.create]/p.2:
>=20
> "Effects: Allocates memory suitable for an object of type T and
> constructs
> an object in that memory via the placement new expression new (pv) T()
> or
> new (pv) T(std::forward<Args>(args)...).[..]"
>=20
> According to variadic template syntax emptypack expansions and empty
> parameter packs are feasible such that the first mentioned expression
> is
> already described by the second one.
>=20

That was my reaction when I merged the paper into the working draft.=20
Thanks for reminding me. (You can send editorial fixes to=20
editorial@versatilecoding.com)

--=20
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The=20
Standard C++ Library Extensions: a Tutorial and Reference=20
(www.petebecker.com/tr1book)


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: Peter Dimov <pdimov@gmail.com>
Date: Tue, 28 Aug 2007 15:55:23 CST
Raw View
On Aug 24, 1:57 am, Daniel Kr   gler <daniel.krueg...@googlemail.com>
wrote:
> The newly proposed make_shared and allocate_shared function templates
> have a redundant effects clause in [util.smartptr.shared.create]/p.2:
>
> "Effects: Allocates memory suitable for an object of type T and
> constructs
> an object in that memory via the placement new expression new (pv) T()
> or
> new (pv) T(std::forward<Args>(args)...).[..]"
>
> According to variadic template syntax emptypack expansions and empty
> parameter packs are feasible such that the first mentioned expression
> is already described by the second one.

Correct in principle. The motivation behind the redundancy was that
the reference variadic template implementation expanded 'new T(a...)'
into 'new T' when a was empty. This matters when T is a POD. We've
since discussed this issue and the correct expansion was clarified to
indeed be 'new T()'.

Nevertheless, I won't be surprised if some compilers get this wrong at
first, and when one needs to be able to convince a compiler/stdlib
vendor that make_shared<int>() should initialize the int to 0, having
explicit wording in the standard helps.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: =?iso-8859-1?q?Daniel_Kr=FCgler?= <daniel.kruegler@googlemail.com>
Date: Wed, 29 Aug 2007 10:08:41 CST
Raw View
On Aug 28, 11:55 pm, Peter Dimov <pdi...@gmail.com> wrote:
> Correct in principle. The motivation behind the redundancy was that
> the reference variadic template implementation expanded 'new T(a...)'
> into 'new T' when a was empty. This matters when T is a POD. We've
> since discussed this issue and the correct expansion was clarified to
> indeed be 'new T()'.
>
> Nevertheless, I won't be surprised if some compilers get this wrong at
> first, and when one needs to be able to convince a compiler/stdlib
> vendor that make_shared<int>() should initialize the int to 0, having
> explicit wording in the standard helps.

I understand the noble reasons for the current writing, but I have
still
two reasons why I think that the current text should be changed:

1) IMO the current writing of the criticized paragraph is more
ambigious
than my corrected version. Isn't there at least a trailing ",
respectively"
missing (if my foreigner english takes me right...) to make clear that
only *one* of those cases apply?

2) Your basic argument holds, but I strongly think that exactly this
paragraph is the wrong place to clarify this issue. Please note that
we could argue for similar reasons that the description of
[allocator.members]/13 should have this important note, the
current text is simply given by:

template <class... Args> void construct(pointer p, Args&&... args);
Effects: ::new((void *)p) T(std::forward<Args>(args)...)

A call to std::allocator::construct with only a single argument *will*
invoke the above template overload of construct.
I have to possible locations in my mind where a proper
implementation-relevant note could be added:

a) [expr.new]/16, second (or third?) bullet: Add a footnote which says
something
along the lines of: "An empty parameter expansion is equivalent to the
form ()"

b) [dcl.init]/8: As part of the already given note just after the
sentence
starting with "The form () is permitted[..]" add one further sentence
along the
lines of "An empty parameter expansion is equivalent to the form ()".

What do you think?

Greetings from Bremen,

Daniel






---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]