--089e01183f10f06da605321a6b7c
Content-Type: multipart/alternative; boundary=089e01183f10f06d9e05321a6b7a

--089e01183f10f06d9e05321a6b7a
Content-Type: text/plain; charset=UTF-8

Hello all,

The following paper has been in development under SG14 for quite some time
but has never been brought here to std-proposals. I wanted to get some more
eyes on it.

The paper proposes the following new algorithms:

uninitialized_value_construct, uninitialized_value_construct_n
uninitialized_default_construct, uninitialized_default_construct_n
uninitialized_move, uninitialized_move_n
destroy, destroy_n, destroy_at

It also makes some wording changes to [specialized.algorithms].

Any thoughts are appreciated.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTtav6T2Gp_dFEba2WLW7Ap5ziZ7KWUDWK46WaEGiyFmg%40mail.gmail.com.

--089e01183f10f06d9e05321a6b7a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello all,<div><br></div><div>The following paper has been=
 in development under SG14 for quite some time but has never been brought h=
ere to std-proposals. I wanted to get some more eyes on it.</div><div><br><=
/div><div>The paper proposes the following new algorithms:</div><div><br></=
div><div>uninitialized_value_construct, uninitialized_value_construct_n</di=
v><div>uninitialized_default_construct, uninitialized_default_construct_n</=
div><div>uninitialized_move, uninitialized_move_n</div><div>destroy, destro=
y_n, destroy_at</div><div><br></div><div>It also makes some wording changes=
 to [specialized.algorithms].</div><div><br></div><div>Any thoughts are app=
reciated.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTtav6T2Gp_dFEba2WLW7Ap5ziZ7K=
WUDWK46WaEGiyFmg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTtav6T=
2Gp_dFEba2WLW7Ap5ziZ7KWUDWK46WaEGiyFmg%40mail.gmail.com</a>.<br />

--089e01183f10f06d9e05321a6b7a--
--089e01183f10f06da605321a6b7c
Content-Type: text/html; charset=UTF-8; name="P0040R3 - d1.html"
Content-Disposition: attachment; filename="P0040R3 - d1.html"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_inuh4xa30

PCFET0NUWVBFIGh0bWw+PGh0bWw+PGhlYWQ+PG1ldGEgY2hhcnNldD0idXRmLTgiPjx0aXRsZT5Q
MDA0MFIzPC90aXRsZT4NCjxzdHlsZT4NCmluc3sgY29sb3I6cmdiKDAsMTI4LDApO30NCi5zdHJp
a2V7IGNvbG9yOnJlZDsgdGV4dC1kZWNvcmF0aW9uOiBsaW5lLXRocm91Z2g7IH0NCi5zZWMtYmVn
aW57IGZvbnQtd2VpZ2h0OmJvbGQ7IH0NCi5zZWMtYmVnaW4gc3BhbnsgZmxvYXQ6cmlnaHQgfQ0K
ZGVse2NvbG9yOnJlZDt9DQo8L3N0eWxlPg0KDQo8L2hlYWQ+PGJvZHkgaWQ9InByZXZpZXciPg0K
PHA+TEVXRywgU0cxNDogUDAwNDBSMzxicj4NCjIwMTYtMDUtMTxicj4NCkJyZW50IEZyaWVkbWFu
PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmZvdXJ0aGdlZWtAZ21haWwuY29tIj5mb3VydGhnZWVrQGdt
YWlsLmNvbTwvYT48L3A+DQo8aDE+PGEgaWQ9IkV4dGVuZGluZ19tZW1vcnlfbWFuYWdlbWVudF90
b29sc181Ij48L2E+RXh0ZW5kaW5nIG1lbW9yeSBtYW5hZ2VtZW50IHRvb2xzPC9oMT4NCjxibG9j
a3F1b3RlPg0KPGk+QW5kIHNvIGl0IGlzIHRoYXQgd2UsIGFzIG1lbiwgZG8gbm90IGV4aXN0IHVu
dGlsIHdlIGRvOyBhbmQgdGhlbiBpdCBpcyB0aGF0IHdlIHBsYXkgd2l0aCBvdXIgd29ybGQgb2Yg
ZXhpc3RlbnQgdGhpbmdzLCBhbmQgb3JkZXIgYW5kIGRpc29yZGVyIHRoZW0sIGFuZCBzbyBpdCBz
aGFsbCBiZSB0aGF0IG5vbi1leGlzdGVuY2Ugc2hhbGwgdGFrZSB1cyBiYWNrIGZyb20gZXhpc3Rl
bmNlIGFuZCB0aGF0IG5hbWVsZXNzIHNwaXJpdHVhbGl0eSBzaGFsbCByZXR1cm4gdG8gVm9pZCwg
bGlrZSBhIHRpcmVkIGNoaWxkIGhvbWUgZnJvbSBhIHZlcnkgd2lsZCBjaXJjdXMuPC9pPg0KPGZv
b3Rlcj4NCuKAlCBPbWFyIEtoYXl5YW0gUmF2ZW5odXJzdCBhbmQgTWFsYWNseXBzZSB0aGUgWW91
bmdlciwgUHJpbmNpcGlhIERpc2NvcmRpYSwgcGcgMDAwNTgNCjwvZm9vdGVyPg0KPC9ibG9ja3F1
b3RlPg0KPGgyPjxhIGlkPSJJX01vdGl2YXRpb25fNyI+PC9hPkkuIE1vdGl2YXRpb248L2gyPg0K
PHA+SXQgaXMgY29tbW9uIGZvciBib3RoIHRoZSBzdGFuZGFyZCBsaWJyYXJ5IGFuZCB1c2VyIGxp
YnJhcmllcyB0byBtYW5hZ2UgbWVtb3J5IHdpdGhvdXQgdGhlIHVzZSBvZiBzdGFuZGFyZC1jb21w
bGlhbnQgYWxsb2NhdG9ycy4gVGhleSBtYXkgdXNlIGludGVybmFsIGJ1ZmZlcnMgKGxpa2UgPGNv
ZGU+c3RkOjpvcHRpb25hbDwvY29kZT4pIG9yIHVzZSBhbiBhbGxvY2F0b3IgbW9kZWwgdGhhdCBk
b2VzIG5vdCBtYW5hZ2Ugb2JqZWN0IGxpZmV0aW1lIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv
bS9ibG9vbWJlcmcvYmRlL3dpa2kvQkRFLUFsbG9jYXRvci1tb2RlbCI+W2JkZV08L2E+LCA8YSBo
cmVmPSJodHRwczovL3d3dy5zZ2kuY29tL3RlY2gvc3RsL2FsbG9jLmh0bWwiPltzZ2ldPC9hPiwg
PGEgaHJlZj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIyL3dnMjEvZG9jcy9wYXBl
cnMvMjAwNy9uMjI3MS5odG1sI2Vhc3RsX2FsbG9jYXRvciI+W2Vhc3RsXTwvYT4gPGEgaHJlZj0i
aHR0cDovL2JpdHNxdWlkLmJsb2dzcG90LmZyLzIwMTAvMDkvY3VzdG9tLW1lbW9yeS1hbGxvY2F0
aW9uLWluLWMuaHRtbCI+W2JpdHNxdWlkXTwvYT4uIFN1Y2ggYWx0ZXJuYXRpdmUgYWxsb2NhdG9y
IG1vZGVscyBhcmUgPGEgaHJlZj0iaHR0cDovL3d3dy5nYW1hc3V0cmEuY29tL2Jsb2dzL1Rob21h
c1lvdW5nLzIwMTQxMDAyLzIyNjg5OC9DdXN0b21fVmVjdG9yX0FsbG9jYXRpb24ucGhwIj5jb21t
b248L2E+IGluIGVmZmljaWVuY3ktY3JpdGljYWwgYXBwbGljYXRpb25zLiBXaGVuIGltcGxlbWVu
dGluZyBzdWNoIGNvbnRhaW5lcnMgaXQgaXMgb2Z0ZW4gbmVjZXNzYXJ5IHRvIG1hbmFnZSBtZW1v
cnkgZGlyZWN0bHkuPC9wPg0KPHA+T3B0aW1pemVkLCBleGNlcHRpb24tY29ycmVjdCBpbXBsZW1l
bnRhdGlvbnMgb2YgdGhlc2UgYWxnb3JpdGhtcyBhcmVuJ3QgbmVjZXNzYXJpbHkgb2J2aW91cy4g
Rm9yIGV4YW1wbGUsIDxjb2RlPmRlc3Ryb3k8L2NvZGU+IGNhbiBiZSBvcHRpbWl6ZWQgaW50byBh
IG5vLW9wIGZvciB0cml2aWFsbHkgZGVzdHJ1Y3RpYmxlIHR5cGVzIGFuZCA8Y29kZT51bmluaXRp
YWxpemVkX3ZhbHVlX2NvbnN0cnVjdDwvY29kZT4gY2FuIGJlIG9wdGltaXplZCB0byBtZW1zZXQg
Zm9yIGludGVncmFsIHR5cGVzLiBIYXZpbmcgYSBzdGFuZGFyZGl6ZWQgaW1wbGVtZW50YXRpb24g
b2YgdGhlc2UgZmVhdHVyZXMgd2lsbCBoZWxwIHRoZSBwZXJmb3JtYW5jZSBhbmQgY29ycmVjdG5l
c3Mgb2YgbGlicmFyaWVzLjwvcD4NCjxoMj48YSBpZD0iSUlfU3VtbWFyeV8xMSI+PC9hPklJLiBT
dW1tYXJ5PC9oMj4NCjxwPlRoZSBmdW5jdGlvbiB0ZW1wbGF0ZXMgPGNvZGU+ZGVzdHJveV9hdDwv
Y29kZT4sIDxjb2RlPmRlc3Ryb3k8L2NvZGU+IGFuZCA8Y29kZT5kZXN0cm95X248L2NvZGU+IGNh
bGwgdGhlIGRlc3RydWN0b3IgZm9yIHNwZWNpZmllZCBlbGVtZW50cy48YnI+DQpUaGUgZnVuY3Rp
b24gdGVtcGxhdGVzIDxjb2RlPnVuaW5pdGlhbGl6ZWRfbW92ZTwvY29kZT4gYW5kIDxjb2RlPnVu
aW5pdGlhbGl6ZWRfbW92ZV9uPC9jb2RlPiBwZXJmb3JtIG1vdmUgY29uc3RydWN0aW9uIG9mIGVs
ZW1lbnRzIG92ZXIgYSByYW5nZSBvZiBtZW1vcnksIHNpbWlsYXIgdG8gPGNvZGU+dW5pbml0aWFs
aXplZF9jb3B5PC9jb2RlPi48YnI+DQpUaGUgZnVuY3Rpb24gdGVtcGxhdGVzIDxjb2RlPnVuaW5p
dGlhbGl6ZWRfdmFsdWVfY29uc3RydWN0PC9jb2RlPiBhbmQgPGNvZGU+dW5pbml0aWFsaXplZF92
YWx1ZV9jb25zdHJ1Y3RfbjwvY29kZT4gcGVyZm9ybSB2YWx1ZS1pbml0aWFsaXphdGlvbm4gb2Yg
b2JqZWN0cyBvdmVyIGEgcmFuZ2Ugb2YgbWVtb3J5Ljxicj4NClRoZSBmdW5jdGlvbiB0ZW1wbGF0
ZXMgPGNvZGU+dW5pbml0aWFsaXplZF9kZWZhdWx0X2NvbnN0cnVjdDwvY29kZT4gYW5kIDxjb2Rl
PnVuaW5pdGlhbGl6ZWRfZGVmYXVsdF9jb25zdHJ1Y3RfbjwvY29kZT4gcGVyZm9ybSBkZWZhdWx0
LWluaXRpYWxpemF0aW9uIG9mIG9iamVjdHMgb3ZlciBhIHJhbmdlIG9mIG1lbW9yeS48L3A+DQoN
CjxwPkRlc3RydWN0aW9uIG9yZGVyIG5vdHdpdGhzdGFuZGluZywgdGhlc2UgYWxnb3JpdGhtcyBh
cmUgaXNvbW9ycGhpYyB0byBjb3JlIGxhbmd1YWdlIGZlYXR1cmVzLiBUaGUgZm9sbG93aW5nIHRh
YmxlIHN1bW1hcml6ZXMgdGhlIHJlbGV2YW50IGV4aXN0aW5nIGFuZCBwcm9wb3NlZCBhbGdvcml0
aG1zLjwvcD4NCg0KPHRhYmxlICBib3JkZXI9IjEiPjx0cj48dGQ+YWxnb3JpdGhtPC90ZD48dGQ+
bGFuZ3VhZ2UgZmVhdHVyZTwvdGQ+PC90cj4NCjx0cj48dGQ+PGNvZGU+dW5pbml0aWFsaXplZF92
YWx1ZV9jb25zdHJ1Y3Q8L2NvZGU+PC90ZD48dGQ+PGNvZGU+VCBkYXRhW05de307PC9jb2RlPjwv
dGQ+PC90cj4NCjx0cj48dGQ+PGNvZGU+dW5pbml0aWFsaXplZF9kZWZhdWx0X2NvbnN0cnVjdDwv
Y29kZT48L3RkPjx0ZD48Y29kZT5UIGRhdGFbTl07PC9jb2RlPjwvdGQ+PC90cj4NCjx0cj48dGQ+
PGNvZGU+dW5pbml0aWFsaXplZF9jb3B5PC9jb2RlPjwvdGQ+PHRkPjxjb2RlPlQgZGF0YVtOXSA9
IG90aGVyX2FycmF5OzwvY29kZT48L3RkPjwvdHI+DQo8dHI+PHRkPjxjb2RlPnVuaW5pdGlhbGl6
ZWRfbW92ZTwvY29kZT48L3RkPjx0ZD48Y29kZT5UIGRhdGFbTl0gPSBtb3ZlKG90aGVyX2FycmF5
KTs8L2NvZGU+PC90ZD48L3RyPg0KPHRyPjx0ZD48Y29kZT51bmluaXRpYWxpemVkX2ZpbGw8L2Nv
ZGU+PC90ZD48dGQ+IChub25lPyk8L3RkPjwvdHI+DQo8dHI+PHRkPjxjb2RlPmRlc3Ryb3k8L2Nv
ZGU+PC90ZD48dGQ+PGNvZGU+IH5UW05dIDwvY29kZT48L3RkPjwvdHI+DQo8dHI+PHRkPjxjb2Rl
PmRlc3Ryb3lfYXQ8L2NvZGU+PC90ZD48dGQ+PGNvZGU+flQ8L2NvZGU+PC90ZD48L3RyPg0KPC90
YWJsZT4NCjwvY29kZT4NCjxwPlRoaXMgcHJvcG9zYWwgKHNwZWNpZmljYWxseSwgdGhlIHdvcmRp
bmcgZm9yIDxjb2RlPmRlc3Ryb3k8L2NvZGU+KSBkZXBlbmRzIG9uIGEgZml4IGZvciA8YSBocmVm
PSJodHRwOi8vY3BsdXNwbHVzLmdpdGh1Yi5pby9MV0cvbHdnLWFjdGl2ZS5odG1sIzI1OTgiPkxX
RyAyNTk4PC9hPi4NCjxoMj48YSBpZD0iSUlJX0Rpc2N1c3Npb25fMTgiPjwvYT5JSUkuIERpc2N1
c3Npb248L2gyPg0KPGgzPiBPcmdhbml6YXRpb24gPC9oMz4NCjxwPiBFYWNoIGZvbGxvd2luZyBz
ZWN0aW9uIGJlZ2lucyB3aXRoIGEgdGFibGUuIFRoZXNlIHRhYmxlcyByZXByZXNlbnQgYW4gaW5m
b3JtYWwgc3VydmV5IG9mIGV4aXN0aW5nIHByYWN0aWNlLCBtYWRlIG1vc3RseSBieSBzZWFyY2hp
bmcgZ2l0aHViIGFuZCB0aGUgVmlzdWFsIFN0dWRpbyBzdGFuZGFyZCBsaWJyYXJ5IGltcGxlbWVu
dGF0aW9uLiBUaGV5IGFyZSBieSBubyBtZWFucyBjb21wbGV0ZSBvciBzY2llbnRpZmljLjxicj4N
Ck1hbnkgc3RhbmRhcmQgbGlicmFyeSBpbXBsZW1lbnRhdGlvbnMgYWxyZWFkeSBjb250YWluIG91
ciBhbGdvcml0aG1zLCBleGNlcHQgaW4gdGhhdCB0aGV5IHRha2UgYW4gYWRkaXRpb25hbCBhbGxv
Y2F0b3IgcGFyYW1ldGVyIGFuZCBmb3J3YXJkIG1lbW9yeSBtYW5hZ2VtZW50IG9wZXJhdGlvbnMg
aW50byB0aGF0IGFsbG9jYXRvciBvYmplY3QuIFRoaXMgcGFwZXIgZG9lcyBub3QgcHJvcG9zZSBh
ZGRpbmcgc3VjaCBhbGdvcml0aG1zLiBIb3dldmVyLCBmb3IgY29tcGxldGVuZXNzLCB0aG9zZSBh
bGdvcml0aG1zIGFyZSBpbmNsdWRlZCBpbiB0aGUgc3VydmV5IGFzICI8cXVvdGU+KyBhbGxvY2F0
b3I8L3F1b3RlPiI8L3A+DQo8aDM+PGNvZGU+ZGVzdHJveTwvY29kZT48L2gzPg0KPHRhYmxlIGJv
cmRlcj0iMSI+DQo8dHI+PHRkPlAwMDQwPC90ZD48dGQ+ZGVzdHJveV9hdDwvdGQ+PHRkPmRlc3Ry
b3k8L3RkPjx0ZD4rIGFsbG9jYXRvcjwvdGQ+PC90cj4NCjx0cj48dGQ+VkMrKzwvdGQ+PHRkPl9E
ZXN0cm95PC90ZD48dGQ+fl9UZW1wX2l0ZXJhdG9yPGJyPnZhbGFycmF5OjpfVGlkeTwvdGQ+PHRk
Pl9EZXN0cm95X3JhbmdlPC90ZD48L3RyPg0KPHRyPjx0ZD5saWJzdGRjeHg8L3RkPjx0ZD48YSBo
cmVmPSJodHRwczovL2dpdGh1Yi5jb20vZ2NjLW1pcnJvci9nY2MvYmxvYi83YWVhNGU3Y2RjZDQw
ZDdiZDQ3YzY0ZTc2MzI1YTYyMTkxODg3ZDFiL2xpYnN0ZGMlMkIlMkItdjMvaW5jbHVkZS9iaXRz
L3N0bF9jb25zdHJ1Y3QuaCNMODciPl9EZXN0cm95PC9hPjwvdGQ+PHRkPjxhIGhyZWY9Imh0dHBz
Oi8vZ2l0aHViLmNvbS9nY2MtbWlycm9yL2djYy9ibG9iLzdhZWE0ZTdjZGNkNDBkN2JkNDdjNjRl
NzYzMjVhNjIxOTE4ODdkMWIvbGlic3RkYyUyQiUyQi12My9pbmNsdWRlL2JpdHMvc3RsX2NvbnN0
cnVjdC5oIj5fRGVzdHJveShmaXJzdCxsYXN0KTwvYT48L3RkPjx0ZD48L3RkPjwvdHI+DQo8dHI+
PHRkPmxpYmN4eDwvdGQ+PHRkPjwvdGQ+PHRkPnNlZSA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5j
b20vbGx2bS1taXJyb3IvbGliY3h4L2Jsb2IvbWFzdGVyL2luY2x1ZGUvdmFsYXJyYXkjTDM2OTgi
PnZhbGFycmF5OjpyZXNpemU8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9sbHZt
LW1pcnJvci9saWJjeHgvYmxvYi84ZjFlNzNkZmQyNTgxMDAwNzQ4NjUyNDg5YzMzMTk4YjMxMmE3
OGJiL2luY2x1ZGUvbWVtb3J5I0wzNTMxIj5fX2Rlc3RydWN0X246Ol9fcHJvY2VzczwvYT48YnI+
IDwvdGQ+PHRkPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9sbHZtLW1pcnJvci9saWJjeHgv
YmxvYi9tYXN0ZXIvaW5jbHVkZS92ZWN0b3IjTDQxOSI+dmVjdG9yOjpfX2Rlc3RydWN0X2F0X2Vu
ZDwvYT48L3RkPjwvdHI+DQo8dHI+PHRkPkVBU1RMPC90ZD48dGQ+PGEgaHJlZj0iaHR0cHM6Ly9n
aXRodWIuY29tL2VsZWN0cm9uaWNhcnRzL0VBU1RML2Jsb2IvNWExZjBmZmNkMTBkNTI0MDYyYmM3
MjdlNjM2YTVkZTg2MzBkOTJmNC9pbmNsdWRlL0VBU1RML21lbW9yeS5oI0wxMjE4Ij5kZXN0cnVj
dDwvYT48L3RkPjx0ZD48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZWxlY3Ryb25pY2FydHMv
RUFTVEwvYmxvYi81YTFmMGZmY2QxMGQ1MjQwNjJiYzcyN2U2MzZhNWRlODYzMGQ5MmY0L2luY2x1
ZGUvRUFTVEwvbWVtb3J5LmgjTDEyMTgiPmRlc3RydWN0KGZpcnN0LGxhc3QpPC9hPjwvdGQ+PHRk
PjwvdGQ+PC90cj4NCjx0cj48dGQ+Zm9sbHk8L3RkPjx0ZD48L3RkPjx0ZD5zZWUgPEEgaHJlZj0i
aHR0cHM6Ly9naXRodWIuY29tL2ZhY2Vib29rL2ZvbGx5L2Jsb2IvMjZkOWYzZjNjYzM0ZDMwZjdl
NzNhNmYxMmEzYmFlNTEwMmM3NTEyZS9mb2xseS9zbWFsbF92ZWN0b3IuaCI+fnNtYWxsX3ZlY3Rv
cjwvYT48L3RkPjx0ZD48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZmFjZWJvb2svZm9sbHkv
YmxvYi9kZWU4YTUxODBhYTU0MmQ5OGQxYjcxYzc0ZjgzYTAwNmU0NjI3OTUyL2ZvbGx5L0ZCVmVj
dG9yLmgjTDM1NyI+U19kZXN0cm95X3JhbmdlX2E8L2E+PC90ZD48L3RyPg0KPHRyPjx0ZD5jb25j
cnQ8L3RkPjx0ZD48L3RkPjx0ZD5zZWUgY29uY3VycmVudF92ZWN0b3I6Ol9EZXN0cm95X2FycmF5
PC90ZD48dGQ+PC90ZD48L3RyPg0KPHRyPjx0ZD5ocHg8L3RkPjx0ZD48L3RkPjx0ZD48YSBocmVm
PSJodHRwczovL2dpdGh1Yi5jb20vU1RFbGxBUi1HUk9VUC9ocHgvYmxvYi85ZGVlZWExNmI3ZDVi
YjQ5MWQ1ZTM1YTEwYjRjNjJmMGI4ZDZkYmZhL2hweC91dGlsL3JlaW5pdGlhbGl6YWJsZV9zdGF0
aWMuaHBwI0w3NyI+cmVpbml0aWFsaXphYmxlX3N0YXRpYzo6ZGVzdHJ1Y3Q8L2E+PC90ZD48dGQ+
PC90ZD48L3RyPg0KPHRyPjx0ZD5ic2w8L3RkPjx0ZD48L3RkPjx0ZD48YSBocmVmPSJodHRwczov
L2dpdGh1Yi5jb20vYmxvb21iZXJnL2JkZS9ibG9iLzI4ZGQ3MjY2NDFkMDk3NDZlNmQ5Y2NhNmU0
YWEwZWEzMTlmYTM1OTUvZ3JvdXBzL2JzbC9ic2xhbGcvYnNsYWxnX2FycmF5ZGVzdHJ1Y3Rpb25w
cmltaXRpdmVzLmgjTDE5MiI+QXJyYXlEZXN0cnVjdGlvblByaW1pdGl2ZXM6OmRlc3Ryb3k8L2E+
PC90ZD48dGQ+PC90ZD48L3RyPg0KPC90YWJsZT4NCjxwPjxjb2RlPmRlc3Ryb3k8L2NvZGU+IGZp
cnN0IGFwcGVhcmVkIGluIFNHSeKAmXMgU3RhbmRhcmQgVGVtcGxhdGUgTGlicmFyeS4gSXQgaXMg
bm90IGtub3duIGJ5IHRoZSBhdXRob3Igd2h5IHRoaXMgYWxnb3JpdGhtIHdhcyBub3QgaW5oZXJp
dGVkIGludG8gdGhlIEMrKyBTdGFuZGFyZCBMaWJyYXJ5IGluIGl0cyBpbml0aWFsIHN0YWdlcy4g
VGhpcyBoaXN0b3JpY2FsIHByZWNlZGVuY2UgbGVkIHVzIHRvIGNob29zZSB0aGUgbmFtZSA8Y29k
ZT5kZXN0cm95PC9jb2RlPiBpbnN0ZWFkIG9mIGVnLiA8Y29kZT5kZXN0cm95X3JhbmdlPC9jb2Rl
Pi48L3A+DQo8cD5BIGRlc2lnbiBkZWNpc2lvbiBtdXN0IGJlIG1hZGUgcmVnYXJkaW5nIHRoZSBv
cmRlciBvZiBkZXN0cnVjdGlvbiBpbiA8Y29kZT5kZXN0cm95PC9jb2RlPi4gU2hvdWxkIGJpZGly
ZWN0aW9uYWwgaXRlcmF0b3JzIGRlc3Ryb3kgb2JqZWN0cyBpbiByZXZlcnNlIG9yZGVyPyBXZSBh
cmd1ZSBubywgZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCjx1bD4NCjxsaT5PcmRlciBvZiBj
b25zdHJ1Y3Rpb24gYW5kIGRlc3RydWN0aW9uIGlzIGEgcHJvcGVydHkgb2YgdGhlIGNvbnRhaW5l
ciwgbm90IGEgcHJvcGVydHkgb2YgdGhlIGl0ZXJhdG9yIGNhdGVnb3J5LiBOb3QgYWxsIGNvbnRh
aW5lcnMgd2l0aCBiaWRpcmVjdGlvbmFsIGl0ZXJhdG9ycyBuZWNlc3NhcmlseSBpbXBseSByZXZl
cnNlLW9yZGVyIGRlc3RydWN0aW9uLjwvbGk+DQo8bGk+SXQgd291bGQgYmUgYSB2ZXJ5IHN0cmFu
Z2UgQVBJIHdoaWNoIHJlcXVpcmVzIHVzZXJzIHRvIHByb3ZpZGUgcmV2ZXJzZSBpdGVyYXRvcnMg
aW4gb3JkZXIgdG8gZGVzdHJveSBpbiBmb3J3YXJkIG9yZGVyPC9saT4NCjxsaT5SZXZlcnNlLW9y
ZGVyIGRlc3RydWN0aW9uIGNhbiBiZSBwcm92aWRlZCBieSBleHBsaWNpdGx5IHByb3ZpZGluZyBh
IHJldmVyc2UgaXRlcmF0b3IgKG9yLCBpZiB0cnVseSBkZXNpcmVkLCBhIDxjb2RlPmRlc3Ryb3lf
cmV2ZXJzZTwvY29kZT4gYWxnb3JpdGhtKS4gRXhwbGljaXRuZXNzIGlzIHRoZSBrZXkgaGVyZS48
L2xpPg0KPGxpPlRoZSBzZW1hbnRpY3Mgb2YgYW4gYWxnb3JpdGhtIHNob3VsZCBub3QgY2hhbmdl
IGJhc2VkIG9uIHRoZSBpdGVyYXRvciBjYXRlZ29yeS4gVGhpcyBjb3VsZCBsZWFkIHRvIHN1cHJp
c2VzIGR1cmluZyBjb2RlIG1haW50ZW5hbmNlLjwvbGk+DQo8bGk+TGVhdmluZyB0aGUgb3JkZXIg
YXMgaW1wbGVtZW50YXRpb24tZGVmaW5lZCB3aWxsIGxpa2VseSBkYW1hZ2UgaXRzIHVzZWZ1bG5l
c3M8L2xpPg0KPC91bD4NCjxwPkl0IGlzIGNvbmNlaXZhYmxlIHRoYXQgYWx3YXlzIGRlc3Ryb3lp
bmcgaW4gZm9yd2FyZCBvcmRlciB3b3VsZCBiZSBzZWVuIGFzIHN1cHJpc2luZyBiZWhhdmlvciB0
byBzb21lLiBIb3dldmVyLCB0aGlzIGlzIGF0IGxlYXN0IGEgY29uc2lzdGVudCBiZWhhdmlvciB3
aGljaCBjYW4gYmUgYWNjb3VudGVkIGZvciBvbmNlIHVuZGVyc3Rvb2QuIElmIHdlIGNob29zZSB0
byBjaGFuZ2UgdGhlIGJlaGF2aW9yIGJhc2VkIG9uIGl0ZXJhdG9yIGNhdGVnb3J5LCB3ZSBjcmVh
dGUgYSBzaXR1YXRpb24gd2hpY2ggaXMgZGlmZmljdWx0IGZvciB1c2VycyB0byBjb250cm9sLjwv
cD4NCjxwPldoZW4gaW1wbGVtZW50aW5nIDxjb2RlPmRlc3Ryb3k8L2NvZGU+LCBhIGdvb2QgaW1w
bGVtZW50YXRpb24gc2hvdWxkIG5vdCBhY2NlcHQgY2FzZXMgd2hlcmUgZXhwcmVzc2lvbiA8Y29k
ZT4qZmlyc3Q8L2NvZGU+IHJlc29sdmVzIHRvIGFuIHJ2YWx1ZS4gRm9yIGV4YW1wbGUsIGFuIGl0
ZXJhdG9yIGNvdWxkIHJldHVybiA8Y29kZT5pbnQ8L2NvZGU+IGluc3RlYWQgb2YgPGNvZGU+aW50
JjwvY29kZT4gYW5kIHRoaXMgd291bGQgY2F1c2UgZG91YmxlLWRlc3RydWN0aW9uLiBXZSBhZGRy
ZXNzIHRoaXMgaXNzdWUgYnkgZGVzY3JpYmluZyA8Y29kZT5kZXN0cm95PC9jb2RlPiBpbiB0ZXJt
cyBvZiA8Y29kZT5kZXN0cm95X2F0PC9jb2RlPi4NCldpdGggYXBwcm9wcmlhdGUgcmVzbG9sdXRp
b24gb2YgPGEgaHJlZj0iaHR0cDovL2NwbHVzcGx1cy5naXRodWIuaW8vTFdHL2x3Zy1hY3RpdmUu
aHRtbCMyNTk4Ij5MV0cgMjU5ODwvYT4sIHRoZSBleHByZXNzaW9uIDxjb2RlPmFkZHJlc3NvZigq
Zmlyc3QpPC9jb2RlPiB3aWxsIHByb2R1Y2UgYW4gZXJyb3IgaWYgPGNvZGU+KmZpcnN0PC9jb2Rl
PiBwcm9kdWNlcyBhbiBydmFsdWUuPC9wPg0KPHA+VGhlIHNwZWNpZmljYXRpb24gb2YgPGNvZGU+
ZGVzdHJveV9hdDwvY29kZT4gbWF5IHNlZW0gb2RkIGFuZCByZXN0cmljdGl2ZSBpbiBob3cgaXQg
cmVxdWlyZXMgYSBub24tbnVsbCBwb2ludGVyIHJhdGhlciB0aGFuIGEgcmVmZXJlbmNlIG9yIGFy
Yml0cmFyeSBpdGVyYXRvciB0eXBlLiBUaGlzIGRlc2lnbiBpcyBjaG9zZW4gZm9yIHRoZSBmb2xs
b3dpbmcgcmVhc29uczo8L3A+DQo8dWw+DQo8bGk+SXQgbWF0Y2hlcyBleGlzdGluZyBwcmFjdGlj
ZSBpbiB2YXJpb3VzIGxpYnJhcmllcyAoc2VlIHRhYmxlKTwvbGk+DQo8bGk+SXQgaXMgY29uY2Vw
dHVhbGx5IGNvbXBhdGlibGUgd2l0aCA8Y29kZT5hbGxvY2F0b3I6OmRlc3Ryb3k8L2NvZGU+IHdo
aWNoIG9wZXJhdGVzIG9uIHRoZSBhbGxvY2F0b3IncyBwb2ludGVyIHR5cGU8L2xpPg0KPGxpPkJ5
IHJlcXVpcmluZyBhIHBvaW50ZXIsIHRoZSBBUEkgbWFrZXMgaXQgZGlmZmljdWx0IHRvIGNhbGwg
b24gYSB0ZW1wb3Jhcnkgb2JqZWN0LiBJZiB0aGUgYWxnb3JpdGhtIG9wZXJhdGVkIG9uIGEgcmVm
ZXJlbmNlIG9yIGl0ZXJhdG9yLCB3ZSB3b3VsZCBuZWVkIHRvIGRvIGV4dHJhIHdvcmsgdG8gZXhj
bHVkZSA8Y29kZT5jb25zdCBUJiY8L2NvZGU+czwvbGk+DQo8bGk+PGNvZGU+ZGVzdHJveTwvY29k
ZT4gaW5oZXJpdHMgdGhlIGJlbmVmaXQgb2YgcnZhbHVlIHNhZmV0eSB3aGVuIGltcGxlbWVudGVk
IGFzIGEgbG9vcCBjYWxsaW5nIDxjb2RlPmRlc3Ryb3lfYXQ8L2NvZGU+PC9saT4NCjxsaT5UaGUg
cmVzdHJpY3RpdmUgQVBJIG1ha2VzIGl0IHNvbWV3aGF0IGxlc3MgbGlrZWx5IHRvIGJlIGNhbGxl
ZCBpbmNvcnJlY3RseS4gSWYgdGhlIEFQSSBhY2NlcHRlZCBhIHJlZmVyZW5jZSwgdXNlcnMgbWln
aHQgcGFzcyBpbiBhIHBvaW50ZXIgYW5kIHRoZSBwb2ludGVyIHdvdWxkIGJlIGRlc3Ryb3llZCBy
YXRoZXIgdGhhbiB0aGUgdmFsdWUgdG8gd2hpY2ggaXQgcG9pbnRzLjwvbGk+DQo8L3VsPiANCjxw
PiBBbGwgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBzdGFuZGFyZCBsaWJyYXJ5IHdoaWNoIHdlcmUg
c3VydmV5ZWQgaGF2ZSBzb21lIGVxdWl2YWxlbnQgb2YgdGhlIGxvZ2ljIGZvciA8Y29kZT5kZXN0
cm95PC9jb2RlPiBpbXBsZW1lbnRlZCBpbiB0aGUgZXhjZXB0aW9uIGhhbmRsaW5nIGJsb2NrIG9m
IHRoZSBleGlzdGluZyA8Y29kZT51bmluaXRpYWxpemVkXyo8L2NvZGU+IGFsZ29yaXRobXMuPC9w
Pg0KPGgzPjxjb2RlPnVuaW5pdGlhbGl6ZWRfbW92ZTwvY29kZT48L2gzPg0KPHRhYmxlIGJvcmRl
cj0iMSI+DQo8dHI+DQo8dHI+PHRkPlAwMDQwPC90ZD4gPHRkPnVuaW5pdGlhbGl6ZWRfbW92ZSA8
L3RkPjx0ZD4rIGFsbG9jYXRvcjwvdGQ+PC90cj4NCjx0cj48dGQ+VkMrKzwvdGQ+PHRkPnNlZSB2
ZWN0b3I6Ol9Bc3NpZ25fcnYgKF9Db25zdHJ1Y3Qgdy8gbW92ZSBpdGVyYXRvcikgIDwvdGQ+PHRk
Pl9VbmluaXRpYWxpemVkX21vdmU8L3RkPjwvdHI+DQo8dHI+PHRkPmxpYnN0ZGN4eDwvdGQ+PHRk
PiA8L3RkPjx0ZD48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZ2NjLW1pcnJvci9nY2MvYmxv
Yi9lZGQ3MTZiNmIxY2FhMWE1Y2IzMjBhOGNkN2Y2MjZmMzAxOThlMDk4L2xpYnN0ZGMlMkIlMkIt
djMvaW5jbHVkZS9iaXRzL3N0bF91bmluaXRpYWxpemVkLmgjTDI4MyI+X191bmluaXRpYWxpemVk
X21vdmVfYTwvYT4gPC90ZD48L3RyPg0KPHRyPjx0ZD5saWJjeHg8L3RkPjx0ZD48L3RkPjx0ZD48
L3RkPjwvdHI+DQo8dHI+PHRkPkVBU1RMPC90ZD48dGQ+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIu
Y29tL2VsZWN0cm9uaWNhcnRzL0VBU1RML2Jsb2IvNWExZjBmZmNkMTBkNTI0MDYyYmM3MjdlNjM2
YTVkZTg2MzBkOTJmNC9pbmNsdWRlL0VBU1RML21lbW9yeS5oI0w3ODQiPnVuaW5pdGlhbGl6ZWRf
bW92ZTwvYT48L3RkPjx0ZD48L3RkPjwvdHI+DQo8dHI+PHRkPmZvbGx5PC90ZD48dGQ+PGEgaHJl
Zj0iaHR0cHM6Ly9naXRodWIuY29tL2ZhY2Vib29rL2ZvbGx5L2Jsb2IvMjZkOWYzZjNjYzM0ZDMw
ZjdlNzNhNmYxMmEzYmFlNTEwMmM3NTEyZS9mb2xseS9zbWFsbF92ZWN0b3IuaCI+bW92ZVRvVW5p
bml0aWFsaXplZDwvYT48L3RkPjx0ZD48L3RkPjwvdHI+DQo8L3RhYmxlPg0KPHA+U29tZSBjb25j
ZXJuIGlzIHJhaXNlZCBhYm91dCBleGNlcHRpb24gaGFuZGxpbmcgd2l0aCByZXNwZWN0IHRvIDxj
b2RlPnVuaW5pdGlhbGl6ZWRfbW92ZTwvY29kZT4uIElmIGEgbW92ZS1jb25zdHJ1Y3RvciB0aHJv
d3MsIG1vdmVkLWZyb20gb2JqZWN0cyBtYXkgYmUgbGVmdCBpbiBhIHBhcnRpYWxseSBtb3ZlZC1m
cm9tIHN0YXRlLiBPdXIgYXBwcm9hY2ggdG8gdGhpcyBwcm9ibGVtIGlzIHRvIGVtdWxhdGUgZXhp
c3RpbmcgYmVoYXZpb3IgdGhyb3VnaG91dCB0aGUgbGFuZ3VhZ2UgYW5kIGxpYnJhcnkuIDxjb2Rl
PnVuaW5pdGlhbGl6ZWRfbW92ZTwvY29kZT4gc2hvdWxkIGJlaGF2ZSBsaWtlIG1vdmUtYXNzaWdu
bWVudCBvZiBhcnJheXMuIE5hbWVseSwgdGhlIGNvbnN0cnVjdGVkIG9iamVjdHMgaW4gdGhlIGRl
c2luYXRpb24gYnVmZmVyIGFyZSBkZXN0cm95ZWQgYW5kIHRoZSBleGNlcHRpb24gaXMgcHJvcGFn
YXRlZC4gVGhpcyBtYXRjaGVzIHRoZSBiZWhhdmlvciBvZiA8Y29kZT51bmluaXRpYWxpemVkX2Nv
cHk8L2NvZGU+IGFuZCB0aGUgYmVoYXZpb3Igb2YgYWxnb3JpdGhtIDxjb2RlPm1vdmU8L2NvZGU+
Ljxicj4NCkFuIGFkZGl0aW9uYWwgYWxnb3JpdGhtLCA8Y29kZT51bmluaXRpYWxpemVkX21vdmVf
aWZfbm9leGNlcHQ8L2NvZGU+LCBjb3VsZCBiZSBjb25zaWRlcmVkIGFzIGEgcmVzb2x1dGlvbiB0
byB0aGlzIGNvbmNlcm4uIFN1Y2ggYW4gYWxnb3JpdGhtIHdhcyBmb3VuZCBhbHJlYWR5IGltcGxl
bWVudGVkIGluIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9nY2MtbWlycm9yL2djYy9ibG9i
L2VkZDcxNmI2YjFjYWExYTVjYjMyMGE4Y2Q3ZjYyNmYzMDE5OGUwOTgvbGlic3RkYyUyQiUyQi12
My9pbmNsdWRlL2JpdHMvc3RsX3VuaW5pdGlhbGl6ZWQuaCNMMjgzIj5saWJzdGRjKys8L2E+IHVz
aW5nIGEgbW92ZV9pZl9ub2V4Y2VwdCBpdGVyYXRvci4gR2l2ZW4gdGhhdCB0aGVyZSBpcyBjdXJy
ZW50bHkgbm8gcmFuZ2UtYmFzZWQgPGNvZGU+bW92ZV9pZl9ub2V4Y2VwdDwvY29kZT4gYWxnb3Jp
dGhtLCBzdWNoIGEgc29sdXRpb24gaXMgbm90IGNvbnNpZGVyZWQgaGVyZS4gSXQgc2VlbXMgY2xl
YXIgdGhhdCBzdWNoIGEgZmVhdHVyZSBpcyByZWFkaWx5IHBvc3NpYmxlLCBob3dldmVyLjwvcD4N
CjxwPjxhIGhyZWY9Imh0dHA6Ly9jcGx1c3BsdXMuZ2l0aHViLmlvL0xXRy9sd2ctYWN0aXZlLmh0
bWwjMjI0MiI+TFdHIDIyNDI8L2E+IHJlcG9ydHMgYSBkZWZlY3QgaW4gPGNvZGU+Y29weV9uPC9j
b2RlPiBhbmQgPGNvZGU+dW5pbml0aWFsaXplZF9jb3B5X248L2NvZGU+LiBXZSBtYWtlIG5vIGF0
dGVtcHQgdG8gcmVzb2x2ZSB0aGUgZXhpc3RpbmcgaXNzdWUgaW4gPGNvZGU+dW5pbml0aWFsaXpl
ZF9jb3B5X248L2NvZGU+LCBhbmQgcmVwbGljYXRlIGl0cyBmbGF3cyBpbiA8Y29kZT51bmluaXRp
YWxpemVkX21vdmVfbjwvY29kZT4uPGJyPg0KRHVyaW5nIGltcGxlbWVudGF0aW9uIHJlc2VhcmNo
LCBpdCB3YXMgZm91bmQgdGhhdCBsaWJzdGRjKysgaW1wbGVtZW50cyBhIHZhcmlhdGlvbiBvZiA8
Y29kZT51bmluaXRpYWxpemVkX21vdmU8L2NvZGU+IGJ5IGNvbWJpbmluZyA8Y29kZT5tb3ZlX2l0
ZXJhdG9yPC9jb2RlPiB3aXRoIDxjb2RlPnVuaW5pdGlhbGl6ZWRfY29weTwvY29kZT4uIEFsdGhv
dWdoIHRoaXMgaW1wbGVtZW50YXRpb24gd291bGQgcHJvdmlkZSB1cyB3aXRoIGEgY2xldmVyIGFu
ZCBzaW1wbGUgd29yZGluZywgaXQgbWFrZXMgcmVzb2x1dGlvbiBvZiA8YSBocmVmPSJodHRwOi8v
Y3BsdXNwbHVzLmdpdGh1Yi5pby9MV0cvbHdnLWFjdGl2ZS5odG1sIzIyNDIiPkxXRyAyMjQyPC9h
PiBtb3JlIGRpZmZpY3VsdCBpbiB0aGUgZnV0dXJlLCBhbmQgc28gaXMgbm90IHVzZWQuDQo8L3A+
DQoNCjxoMz48Y29kZT51bmluaXRpYWxpemVkX3ZhbHVlX2NvbnN0cnVjdDsgdW5pbml0aWFsaXpl
ZF9kZWZhdWx0X2NvbnN0cnVjdDwvY29kZT48L2gzPg0KPHRhYmxlIGJvcmRlcj0iMSI+DQo8dHI+
PHRkPlAwMDQwPC90ZD48dGQ+dW5pbml0aWFsaXplZF92YWx1ZV9jb25zdHJ1Y3Q8L3RkPjx0ZD4r
IGFsbG9jYXRvcjwvdGQ+PC90cj4NCjx0cj48dGQ+VkMrKzwvdGQ+PHRkPl9Db25zdHJ1Y3Q8L3Rk
Pjx0ZD5fVW5pbml0aWFsaXplZF9kZWZhdWx0X2ZpbGxfbiAoZGVxdWUsIHZlY3RvciwgaW50ZXJu
YWxfY29uY3VycmVudF9oYXNoKTwvdGQ+PC90cj4NCjx0cj48dGQ+bGlic3RkY3h4PC90ZD48dGQ+
PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2djYy1taXJyb3IvZ2NjL2Jsb2IvZWRkNzE2YjZi
MWNhYTFhNWNiMzIwYThjZDdmNjI2ZjMwMTk4ZTA5OC9saWJzdGRjJTJCJTJCLXYzL2luY2x1ZGUv
Yml0cy9zdGxfdW5pbml0aWFsaXplZC5oI0w1NDQiPl9fdW5pbml0aWFsaXplZF9kZWZhdWx0PC9h
PjwvdGQ+PHRkPl9fdW5pbml0aWFsaXplZF9kZWZhdWx0X2E8L3RkPjwvdHI+DQo8dHI+PHRkPmxp
YmN4eDwvdGQ+PHRkPjwvdGQ+PHRkPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9sbHZtLW1p
cnJvci9saWJjeHgvYmxvYi9tYXN0ZXIvaW5jbHVkZS92ZWN0b3IjTDk3MCI+dmVjdG9yOjpfX2Nv
bnN0cnVjdF9hdF9lbmQ8L2E+PC90ZD4gPC90cj4NCjx0cj48dGQ+RUFTVEw8L3RkPjx0ZD48YSBo
cmVmPSJodHRwczovL2dpdGh1Yi5jb20vZWxlY3Ryb25pY2FydHMvRUFTVEwvYmxvYi82YTYyYjc1
NDE4MDM3NmY1ZmRhY2IwODQyYzNhYTk0MDliMzU1NjZiL2luY2x1ZGUvRUFTVEwvbWVtb3J5Lmgj
TDg2NCI+dW5pbml0aWFsaXplZF9kZWZhdWx0X2ZpbGw8L2E+PC90ZD48dGQ+PC90ZD48L3RyPg0K
PHRyPjx0ZD5mb2xseTwvdGQ+PHRkPnNlZSA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZmFj
ZWJvb2svZm9sbHkvYmxvYi8yNmQ5ZjNmM2NjMzRkMzBmN2U3M2E2ZjEyYTNiYWU1MTAyYzc1MTJl
L2ZvbGx5L2Z1dHVyZXMvQmFycmllci5jcHAiPkJhcnJpZXI6OmFsbG9jYXRlQ29udHJvbEJsb2Nr
PC9hPjwvdGQ+PHRkPjwvdGQ+PC90cj4NCjx0cj48dGQ+Y29uY3J0PC90ZD48dGQ+X0ludGVybmFs
X2xvb3BfZ3VpZGU6Ol9Jbml0PC90ZD48dGQ+PC90ZD48L3RyPg0KPHRyPjx0ZD5ocHg8L3RkPjx0
ZD48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vU1RFbGxBUi1HUk9VUC9ocHgvYmxvYi85ZGVl
ZWExNmI3ZDViYjQ5MWQ1ZTM1YTEwYjRjNjJmMGI4ZDZkYmZhL2hweC91dGlsL3JlaW5pdGlhbGl6
YWJsZV9zdGF0aWMuaHBwI0w2NCI+cmVpbml0aWFsaXphYmxlX3N0YXRpYzo6ZGVmYXVsdF9jb25z
dHJ1Y3Q8L2E+PC90ZD48dGQ+PC90ZD48L3RyPg0KPC90YWJsZT4NCg0KPHA+VGhlIHRhYmxlIGRl
bW9uc3RyYXRlcyB0aGF0IG1hbnkgbGlicmFyaWVzIHVzZSB0aGUgd29yZCAiZGVmYXVsdCIgdG8g
cmVmZXIgdG8gdmFsdWUtaW5pdGlhbGl6YXRpb24uIFRoaXMgaXMgbGlrZWx5IGJlY2F1c2UgdGhl
IHN0YW5kYXJkIGxpYnJhcnkgcm91dGluZWx5IHByZWZlcnMgdmFsdWUgaW5pdGlhbGl6YXRpb24g
YXMgdGhlIGRlZmF1bHQgZm9yIGNvbnRhaW5lciBlbGVtZW50cy4gV2Ugc2VlayB0byBzdXBwb3J0
IGJvdGggZm9ybXMgb2YgaW5pdGlhbGl6YXRpb24sIHNvIHRoZSBkaXN0aW5jdGlvbiBpcyBpbXBv
cnRhbnQgdG8gbWFrZSBjbGVhcmx5LjwvcD4NCjxwPlRoZSBzb2x1dGlvbiBvZiB1c2luZyA8Y29k
ZT51bmluaXRpYWxpemVkX2ZpbGw8L2NvZGU+IHRvIGZpbGwgYSByYW5nZSB3aXRoIGEgZGVmYXVs
dC1pbml0aWFsaXplZCBvciB2YWx1ZS1pbml0aWFsaXplZCBvYmplY3QgaXMgc3Vib3B0aW1hbCwg
bWFraW5nIHRoaXMgYWxnb3JpdGhtIHVzZWZ1bC4gVXNpbmcgZmlsbCBwcmVzZW50cyB0aGUgZm9s
bG93aW5nIGlzc3VlczoNCjx1bD4NCjxsaT5SZXF1aXJlcyB0aGF0IGFuIGFkZGl0aW9uYWwgb2Jq
ZWN0IGJlIGNyZWF0ZWQgYW5kIGRlc3Ryb3llZCwgd2hpY2ggY291bGQgaW5jdXIgb3ZlcmhlYWQg
b3IgbGVhZCB0byBpbmNvcnJlY3QgYmVoYXZpb3IgaWYgdGhhdCBvYmplY3QgbW9kaWZpZXMgZ2xv
YmFsIHN0YXRlIChlZywgYSBjb3VudGVyKS48L2xpPg0KPGxpPlJlcXVpcmVzIHRoZSBvYmplY3Qg
dHlwZSB0byBzdXBwb3J0IGNvcHkgY29uc3RydWN0aW9uPC9saT4NCjwvdWw+DQo8L3A+DQo8cD5O
byBhbGdvcml0aG1zIGVxdWl2YWxlbnQgdG8gPGNvZGU+dW5pbml0aWFsaXplZF9kZWZhdWx0X2Nv
bnN0cnVjdDwvY29kZT4gd2VyZSBmb3VuZCBpbiBvdXIgKHZlcnkgaW5jb21wbGV0ZSkgc2VhcmNo
LiBUaGUgYXV0aG9yIGJlbGlldmVzIHRoYXQgdGhlIFN0YW5kYXJkIExpYnJhcnkgd291bGQgYmUg
cmVtaXNzIHRvIHN1cHBvcnQgb25lIGZvcm0gYnV0IG5vdCB0aGUgb3RoZXIuPC9wPg0KPGgyPjxh
IGlkPSJJVl9Qcm9wb3NlZF9UZXh0XzMxIj48L2E+SVYuIFByb3Bvc2VkIFRleHQ8L2gyPg0KPHA+
VGhpcyBkb2N1bWVudCBpcyB3cml0dGVuIGFzIGEgc2V0IG9mIGNoYW5nZXMgYWdhaW5zdCBuNDU2
Ny48L3A+DQo8cD5UaGUgZXhpc3Rpbmcgc3RydWN0dXJlIG9mIFtzcGVjaWFsaXplZC5hbGdvcml0
aG1zXSBtYWRlIGFtZW5kbWVudHMgZGlmZmljdWx0LCBlc3BlY2lhbGx5IHdpdGggcmVzcGVjdCB0
byBleGNlcHRpb24gYmVoYXZpb3IuIEFzIHN1Y2gsIHRoZSBwcm9wb3NlZCB3b3JkaW5nIGFwcGxp
ZXMgYSBjb25zZXJ2YXRpdmUgcmVmYWN0b3JpbmcgaW4gb3JkZXIgdG8gbWFrZSB0aGUgc2VjdGlv
biBtb3JlIGZsZXhpYmxlLiBUaGlzIHdvcmRpbmcgaXMgY29waWVkIGFsbW9zdCB2ZXJiYXRpbSBm
cm9tIDI1LjEgW2FsZ29yaXRobXMuZ2VuZXJhbF08L3A+DQo8cD5BIG1pbm9yIGluY29uc2lzdGVu
Y3kgd2FzIG5vdGVkIGluIHRoYXQgPGNvZGU+dW5pbml0aWFsaXplZF9jb3B5PC9jb2RlPiBhbmQg
PGNvZGU+dW5pbml0aWFsaXplZF9jb3B5X248L2NvZGU+IGFyZSBpbiB0aGUgc2FtZSBzZWN0aW9u
LCBidXQgPGNvZGU+dW5pbml0aWFsaXplZF9maWxsPC9jb2RlPiBhbmQgPGNvZGU+dW5pbml0aWFs
aXplZF9maWxsX248L2NvZGU+IGFyZSBpbiBzZXBhcmF0ZSBzZWN0aW9ucy4gVGhlIGZpbGwgYWxn
b3JpdGhtcyBhcmUgY29tYmluZWQgaW50byBvbmUgc2VjdGlvbiBhcyBwYXJ0IG9mIHRoaXMgd29y
ZGluZy4NCjxwPjxiPkFtZW5kIHRoZSA8Y29kZT4mbHQ7bWVtb3J5Jmd0OzwvY29kZT4gaGVhZGVy
IHN5bnBvc2lzIGluIDIwLjcuMiBbbWVtb3J5LnN5bl08L2I+IDwvcD4NCjxwPg0KVGhlIGhlYWRl
ciAmbHQ7bWVtb3J5Jmd0OyBkZWZpbmVzIHNldmVyYWwgdHlwZXMgYW5kIGZ1bmN0aW9uIHRlbXBs
YXRlcyB0aGF0IGRlc2NyaWJlIHByb3BlcnRpZXMgb2YgcG9pbnRlcnMNCmFuZCBwb2ludGVyLWxp
a2UgdHlwZXMsIG1hbmFnZSBtZW1vcnkgZm9yIGNvbnRhaW5lcnMgYW5kIG90aGVyIHRlbXBsYXRl
IHR5cGVzLCA8aW5zPmRlc3Ryb3kgb2JqZWN0czwvaW5zPiwgYW5kIGNvbnN0cnVjdCBtdWx0aXBs
ZQ0Kb2JqZWN0cyBpbiB1bmluaXRpYWxpemVkIG1lbW9yeSBidWZmZXJzICgyMC43LjPigJMyMC43
LjEyKS4NCjxwcmU+DQouLi4NCi8vIDIwLjcuMTIsIHNwZWNpYWxpemVkIGFsZ29yaXRobXM6DQp0
ZW1wbGF0ZSAmbHQ7Y2xhc3MgVCZndDsgVCogYWRkcmVzc29mKFQmYW1wOyByKSBub2V4Y2VwdDsN
CnRlbXBsYXRlICZsdDtjbGFzcyBJbnB1dEl0ZXJhdG9yLCBjbGFzcyBGb3J3YXJkSXRlcmF0b3Im
Z3Q7DQogRm9yd2FyZEl0ZXJhdG9yIHVuaW5pdGlhbGl6ZWRfY29weShJbnB1dEl0ZXJhdG9yIGZp
cnN0LCBJbnB1dEl0ZXJhdG9yIGxhc3QsIEZvcndhcmRJdGVyYXRvciByZXN1bHQpOw0KdGVtcGxh
dGUgJmx0O2NsYXNzIElucHV0SXRlcmF0b3IsIGNsYXNzIFNpemUsIGNsYXNzIEZvcndhcmRJdGVy
YXRvciZndDsNCiBGb3J3YXJkSXRlcmF0b3IgdW5pbml0aWFsaXplZF9jb3B5X24oSW5wdXRJdGVy
YXRvciBmaXJzdCwgU2l6ZSBuLCBGb3J3YXJkSXRlcmF0b3IgcmVzdWx0KTsNCnRlbXBsYXRlICZs
dDtjbGFzcyBGb3J3YXJkSXRlcmF0b3IsIGNsYXNzIFQmZ3Q7DQogdm9pZCB1bmluaXRpYWxpemVk
X2ZpbGwoRm9yd2FyZEl0ZXJhdG9yIGZpcnN0LCBGb3J3YXJkSXRlcmF0b3IgbGFzdCwgY29uc3Qg
VCZhbXA7IHgpOw0KdGVtcGxhdGUgJmx0O2NsYXNzIEZvcndhcmRJdGVyYXRvciwgY2xhc3MgU2l6
ZSwgY2xhc3MgVCZndDsNCiBGb3J3YXJkSXRlcmF0b3IgdW5pbml0aWFsaXplZF9maWxsX24oRm9y
d2FyZEl0ZXJhdG9yIGZpcnN0LCBTaXplIG4sIGNvbnN0IFQmYW1wOyB4KTsNCjxpbnM+DQp0ZW1w
bGF0ZSZsdDtjbGFzcyBJbnB1dEl0ZXJhdG9yJmd0Ow0KIHZvaWQgZGVzdHJveShJbnB1dEl0ZXJh
dG9yIGJlZ2luLCBJbnB1dEl0ZXJhdG9yIGVuZCk7DQp0ZW1wbGF0ZSZsdDtjbGFzcyBJbnB1dEl0
ZXJhdG9yLCBjbGFzcyBTaXplJmd0Ow0KIElucHV0SXRlcmF0b3IgZGVzdHJveV9uKElucHV0SXRl
cmF0b3IgYmVnaW4sIFNpemUgbik7DQp0ZW1wbGF0ZSZsdDtjbGFzcyBUJmd0Ow0KIHZvaWQgZGVz
dHJveV9hdChUKiBsb2NhdGlvbik7IA0KdGVtcGxhdGUgJmx0O2NsYXNzIElucHV0SXRlcmF0b3Is
IGNsYXNzIEZvcndhcmRJdGVyYXRvciZndDsNCiBGb3J3YXJkSXRlcmF0b3IgdW5pbml0aWFsaXpl
ZF9tb3ZlKElucHV0SXRlcmF0b3IgZmlyc3QsIElucHV0SXRlcmF0b3IgbGFzdCwgRm9yd2FyZEl0
ZXJhdG9yIHJlc3VsdCk7DQp0ZW1wbGF0ZSAmbHQ7Y2xhc3MgSW5wdXRJdGVyYXRvciwgY2xhc3Mg
U2l6ZSwgY2xhc3MgRm9yd2FyZEl0ZXJhdG9yJmd0Ow0KIEZvcndhcmRJdGVyYXRvciB1bmluaXRp
YWxpemVkX21vdmVfbihJbnB1dEl0ZXJhdG9yIGZpcnN0LCBTaXplIHMsIEZvcndhcmRJdGVyYXRv
ciByZXN1bHQpOw0KdGVtcGxhdGUmbHQ7Y2xhc3MgRm9yd2FyZEl0ZXJhdG9yJmd0Ow0KIHZvaWQg
dW5pbml0aWFsaXplZF92YWx1ZV9jb25zdHJ1Y3QoRm9yd2FyZEl0ZXJhdG9yIGZpcnN0LCBGb3J3
YXJkSXRlcmF0b3IgbGFzdCk7DQogdGVtcGxhdGUmbHQ7Y2xhc3MgRm9yd2FyZEl0ZXJhdG9yLCBj
bGFzcyBTaXplJmd0Ow0KIEZvcndhcmRJdGVyYXRvciB1bmluaXRpYWxpemVkX3ZhbHVlX2NvbnN0
cnVjdF9uKEZvcndhcmRJdGVyYXRvciBmaXJzdCwgU2l6ZSBuKTsNCnRlbXBsYXRlJmx0O2NsYXNz
IEZvcndhcmRJdGVyYXRvciZndDsNCiB2b2lkIHVuaW5pdGlhbGl6ZWRfZGVmYXVsdF9jb25zdHJ1
Y3QoRm9yd2FyZEl0ZXJhdG9yIGZpcnN0LCBGb3J3YXJkSXRlcmF0b3IgbGFzdCk7DQogdGVtcGxh
dGUmbHQ7Y2xhc3MgRm9yd2FyZEl0ZXJhdG9yLCBjbGFzcyBTaXplJmd0Ow0KIEZvcndhcmRJdGVy
YXRvciB1bmluaXRpYWxpemVkX2RlZmF1bHRfY29uc3RydWN0X24oRm9yd2FyZEl0ZXJhdG9yIGZp
cnN0LCBTaXplIG4pOw0KPC9pbnM+IA0KLi4uDQo8L3ByZT4NCjwvcD4NCg0KPHA+PGI+QW1lbmQg
W3NwZWNpYWxpemVkLmFsZ29yaXRobXNdIGluIDIwLjcuMTI6PC9iPjwvcD4NCg0KPHAgY2xhc3M9
InNlYy1iZWdpbiI+MjAuNy4xMiBTcGVjaWFsaXplZCBhbGdvcml0aG1zIDxzcGFuPltzcGVjaWFs
aXplZC5hbGdvcml0aG1zXTwvc3Bhbj48L3A+DQo8cD4NCjwvcD4NCjxwPg0KPGRlbD5JbiB0aGUg
YWxnb3JpdGhtIHVuaW5pdGlhbGl6ZWRfY29weSwgdGhlIHRlbXBsYXRlIHBhcmFtZXRlciBJbnB1
dEl0ZXJhdG9yIGlzIHJlcXVpcmVkIHRvIHNhdGlzZnkgdGhlDQpyZXF1aXJlbWVudHMgb2YgYW4g
aW5wdXQgaXRlcmF0b3IgKDI0LjIuMykuIEluIGFsbCBvZiB0aGUgZm9sbG93aW5nIGFsZ29yaXRo
bXMsIHRoZSB0ZW1wbGF0ZSBwYXJhbWV0ZXINCkZvcndhcmRJdGVyYXRvciBpcyByZXF1aXJlZCB0
byBzYXRpc2Z5IHRoZSByZXF1aXJlbWVudHMgb2YgYSBmb3J3YXJkIGl0ZXJhdG9yICgyNC4yLjUp
LCBhbmQgaXMgcmVxdWlyZWQNCnRvIGhhdmUgdGhlIHByb3BlcnR5IHRoYXQgbm8gZXhjZXB0aW9u
cyBhcmUgdGhyb3duIGZyb20gaW5jcmVtZW50LCBhc3NpZ25tZW50LCBjb21wYXJpc29uLCBvciBp
bmRpcmVjdGlvbg0KdGhyb3VnaCB2YWxpZCBpdGVyYXRvcnMuPC9kZWw+PGJyPg0KPGlucz5UaHJv
dWdob3V0IHRoaXMgQ2xhdXNlLCB0aGUgbmFtZXMgb2YgdGVtcGxhdGUgcGFyYW1ldGVycyBhcmUg
dXNlZCB0byBleHByZXNzIHR5cGUgcmVxdWlyZW1lbnRzLjwvaW5zPg0KPHVsPg0KIDxsaT4gPGlu
cz5JZiBhbiBhbGdvcml0aG0ncyB0ZW1wbGF0ZSBwYXJhbWV0ZXIgaXMgbmFtZWQgSW5wdXRJdGVy
YXRvciwgdGhlIHRlbXBsYXRlIGFyZ3VtZW50IHNoYWxsIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50
cyBvZiBhbiBpbnB1dCBpdGVyYXRvciAoMjQuMi4zKS48L2lucz48L2xpPg0KIDxsaT4gPGlucz5J
ZiBhbiBhbGdvcml0aG0ncyB0ZW1wbGF0ZSBwYXJhbWV0ZXIgaXMgbmFtZWQgRm9yd2FyZEl0ZXJh
dG9yLCB0aGUgdGVtcGxhdGUgYXJndW1lbnQgc2hhbGwgc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnRz
IG9mIGEgZm9yd2FyZCBpdGVyYXRvciAoMjQuMi41KSwgYW5kIGlzIHJlcXVpcmVkIHRvIGhhdmUg
dGhlIHByb3BlcnR5IHRoYXQgbm8gZXhjZXB0aW9ucyBhcmUgdGhyb3duIGZyb20gaW5jcmVtZW50
LCBhc3NpZ25tZW50LCBjb21wYXJpc29uLCBvciBpbmRpcmVjdGlvbiB0aHJvdWdoIHZhbGlkIGl0
ZXJhdG9ycy48L2lucz48L2xpPg0KPC91bD4NCjxkZWw+SW4gdGhlIGZvbGxvd2luZyBhbGdvcml0
aG1zLCBpZiBhbiBleGNlcHRpb24gaXMgdGhyb3duIHRoZXJlIGFyZSBubyBlZmZlY3RzLjwvZGVs
Pg0KPC9wPg0KPHAgY2xhc3M9InNlYy1iZWdpbiI+MjAuNy4xMi4xIDxjb2RlPmFkZHJlc3NvZjwv
Y29kZT4gPHNwYW4+W3NwZWNpYWxpemVkLmFkZHJlc3NvZl08L3NwYW4+PC9wPg0KPHByZT48Y29k
ZT4NCnRlbXBsYXRlICZsdDtjbGFzcyBUJmd0OyBUKiBhZGRyZXNzb2YoVCZhbXA7IHIpIG5vZXhj
ZXB0OzwvY29kZT4NCjxwPiAgICA8aT5SZXR1cm5zOjwvaT4gVGhlIGFjdHVhbCBhZGRyZXNzIG9m
IHRoZSBvYmplY3Qgb3IgZnVuY3Rpb24gcmVmZXJlbmNlZCBieSA8Y29kZT5yPC9jb2RlPiwgZXZl
biBpbiB0aGUgcHJlc2VuY2Ugb2YgYW4gb3ZlcmxvYWRlZCBvcGVyYXRvciZhbXA7LjwvcD48L3By
ZT4NCjxwIGNsYXNzPSJzZWMtYmVnaW4iPjIwLjcuMTIuMiA8Y29kZT51bmluaXRpYWxpemVkX2Nv
cHk8L2NvZGU+IDxzcGFuPlt1bmluaXRpYWxpemVkLmNvcHldPC9zcGFuPjwvcD4NCjxwcmU+PGNv
ZGU+DQp0ZW1wbGF0ZSAmbHQ7Y2xhc3MgSW5wdXRJdGVyYXRvciwgY2xhc3MgRm9yd2FyZEl0ZXJh
dG9yJmd0Ow0KRm9yd2FyZEl0ZXJhdG9yIHVuaW5pdGlhbGl6ZWRfY29weShJbnB1dEl0ZXJhdG9y
IGZpcnN0LCBJbnB1dEl0ZXJhdG9yIGxhc3QsIEZvcndhcmRJdGVyYXRvciByZXN1bHQpOw0KPC9j
b2RlPg0KICAgIDxpPkVmZmVjdHM6PC9pPg0KPGNvZGU+DQogICAgICAgIGZvciAoOyBmaXJzdCAh
PSBsYXN0OyArK3Jlc3VsdCwgKHZvaWQpICsrZmlyc3QpDQogICAgICAgICAgICA6Om5ldyAoc3Rh
dGljX2Nhc3QmbHQ7dm9pZComZ3Q7KGFkZHJlc3NvZigqcmVzdWx0KSkpDQogICAgICAgICAgICAg
dHlwZW5hbWUgaXRlcmF0b3JfdHJhaXRzJmx0O0ZvcndhcmRJdGVyYXRvciZndDs6OnZhbHVlX3R5
cGUoKmZpcnN0KTsNCjwvY29kZT4NCiAgICA8aT5SZXR1cm5zOjwvaT4gPGNvZGU+cmVzdWx0PC9j
b2RlPg0KICAgIDxpbnM+PGk+UmVtYXJrczo8L2k+IElmIGFuIGV4Y2VwdGlvbiBpcyB0aHJvd24g
dGhlcmUgYXJlIG5vIGVmZmVjdHMuPC9pbnM+DQo8Y29kZT4NCnRlbXBsYXRlICZsdDtjbGFzcyBJ
bnB1dEl0ZXJhdG9yLCBjbGFzcyBTaXplLCBjbGFzcyBGb3J3YXJkSXRlcmF0b3ImZ3Q7DQpGb3J3
YXJkSXRlcmF0b3IgdW5pbml0aWFsaXplZF9jb3B5X24oSW5wdXRJdGVyYXRvciBmaXJzdCwgU2l6
ZSBuLCBGb3J3YXJkSXRlcmF0b3IgcmVzdWx0KTsNCjwvY29kZT4NCiAgICA8aT5FZmZlY3RzOjwv
aT4NCjxjb2RlPg0KICAgICAgICBmb3IgKCA7IG4gPiAwOyArK3Jlc3VsdCwgKHZvaWQpICsrZmly
c3QsIC0tbikgew0KICAgICAgICAgICAgOjpuZXcgKHN0YXRpY19jYXN0Jmx0O3ZvaWQqJmd0Oyhh
ZGRyZXNzb2YoKnJlc3VsdCkpKQ0KICAgICAgICAgICAgdHlwZW5hbWUgaXRlcmF0b3JfdHJhaXRz
Jmx0O0ZvcndhcmRJdGVyYXRvciZndDs6OnZhbHVlX3R5cGUoKmZpcnN0KTsNCiAgICAgICAgfQ0K
PC9jb2RlPg0KICAgIDxpPlJldHVybnM6PC9pPiA8Y29kZT5yZXN1bHQ8L2NvZGU+DQogICAgPGlu
cz48aT5SZW1hcmtzOjwvaT4gSWYgYW4gZXhjZXB0aW9uIGlzIHRocm93biB0aGVyZSBhcmUgbm8g
ZWZmZWN0cy48L2lucz4NCjwvcHJlPg0KPHAgY2xhc3M9InNlYy1iZWdpbiI+MjAuNy4xMi4zIDxj
b2RlPnVuaW5pdGlhbGl6ZWRfZmlsbDwvY29kZT4gPHNwYW4+W3VuaW5pdGlhbGl6ZWQuZmlsbF08
L3NwYW4+PC9wPg0KPHByZT48Y29kZT4NCnRlbXBsYXRlICZsdDtjbGFzcyBGb3J3YXJkSXRlcmF0
b3IsIGNsYXNzIFQmZ3Q7DQp2b2lkIHVuaW5pdGlhbGl6ZWRfZmlsbChGb3J3YXJkSXRlcmF0b3Ig
Zmlyc3QsIEZvcndhcmRJdGVyYXRvciBsYXN0LCBjb25zdCBUJmFtcDsgeCk7DQo8L2NvZGU+DQog
ICAgPGk+RWZmZWN0czo8L2k+DQo8Y29kZT4NCiAgICAgICAgZm9yICg7IGZpcnN0ICE9IGxhc3Q7
ICsrZmlyc3QpDQogICAgICAgICAgICA6Om5ldyAoc3RhdGljX2Nhc3QmbHQ7dm9pZComZ3Q7KGFk
ZHJlc3NvZigqZmlyc3QpKSkgdHlwZW5hbWUgaXRlcmF0b3JfdHJhaXRzJmx0O0ZvcndhcmRJdGVy
YXRvciZndDs6OnZhbHVlX3R5cGUoeCk7DQo8L2NvZGU+DQogICAgPGlucz48aT5SZW1hcmtzOjwv
aT4gSWYgYW4gZXhjZXB0aW9uIGlzIHRocm93biB0aGVyZSBhcmUgbm8gZWZmZWN0cy48L2lucz4N
CjwvcHJlPg0KPGRlbD48cCBjbGFzcz0ic2VjLWJlZ2luIj4yMC43LjEyLjQgPGNvZGU+dW5pbml0
aWFsaXplZF9maWxsX248L2NvZGU+IDxzcGFuPlt1bmluaXRpYWxpemVkLmZpbGxdPC9zcGFuPjwv
cD48L2RlbD4NCjxwcmU+PGNvZGU+DQp0ZW1wbGF0ZSAmbHQ7Y2xhc3MgRm9yd2FyZEl0ZXJhdG9y
LCBjbGFzcyBTaXplLCBjbGFzcyBUJmd0Ow0KRm9yd2FyZEl0ZXJhdG9yIHVuaW5pdGlhbGl6ZWRf
ZmlsbF9uKEZvcndhcmRJdGVyYXRvciBmaXJzdCwgU2l6ZSBuLCBjb25zdCBUJiB4KTsNCjwvY29k
ZT4NCiAgICA8aT5FZmZlY3RzOjwvaT4NCjxjb2RlPg0KICAgICAgICBmb3IgKDsgbi0tOyArK2Zp
cnN0KQ0KICAgICAgICAgICAgOjpuZXcgKHN0YXRpY19jYXN0Jmx0O3ZvaWQqJmd0OyhhZGRyZXNz
b2YoKmZpcnN0KSkpIHR5cGVuYW1lIGl0ZXJhdG9yX3RyYWl0cyZsdDtGb3J3YXJkSXRlcmF0b3Im
Z3Q7Ojp2YWx1ZV90eXBlKHgpOw0KPC9jb2RlPg0KICAgIDxpPlJldHVybnM6PC9pPiA8Y29kZT5y
ZXN1bHQ8L2NvZGU+DQogICAgPGlucz48aT5SZW1hcmtzOjwvaT4gSWYgYW4gZXhjZXB0aW9uIGlz
IHRocm93biB0aGVyZSBhcmUgbm8gZWZmZWN0cy48L2lucz4NCjwvcHJlPg0KPGlucz4NCjxwIGNs
YXNzPSJzZWMtYmVnaW4iPjIwLjcuMTIuNCA8Y29kZT5kZXN0cm95PC9jb2RlPiAgICA8c3Bhbj5b
c3BlY2lhbGl6ZWQuZGVzdHJveV08L3NwYW4+PC9wPg0KPHByZT48Y29kZT4NCnRlbXBsYXRlICZs
dDtjbGFzcyBJbnB1dEl0ZXJhdG9yJmd0Ow0Kdm9pZCBkZXN0cm95KElucHV0SXRlcmF0b3IgZmly
c3QsIElucHV0SXRlcmF0b3IgbGFzdCk7PC9jb2RlPiAgIA0KICAgIDxpPkVmZmVjdHM6PC9pPiA8
Y29kZT4NCiAgICAgICAgICAgIGZvcig7Zmlyc3QhPWxhc3Q7KytmaXJzdCkNCiAgICAgICAgICAg
ICAgICBkZXN0cm95X2F0KGFkZHJlc3NvZigqZmlyc3QpKTsNCiAgICAgPC9jb2RlPg0KDQo8Y29k
ZT50ZW1wbGF0ZSAmbHQ7Y2xhc3MgSW5wdXRJdGVyYXRvciwgY2xhc3MgU2l6ZSZndDsNCklucHV0
SXRlcmF0b3IgZGVzdHJveV9uKElucHV0SXRlcmF0b3IgZmlyc3QsIFNpemUgbik7PC9jb2RlPg0K
ICAgIDxpPkVmZmVjdHM6PC9pPiA8Y29kZT4NCiAgICAgICAgICAgIGZvciAoIDsgbiA+IDA7ICh2
b2lkKSsrZmlyc3QsIC0tbikNCiAgICAgICAgICAgICAgICAgIGRlc3Ryb3lfYXQoYWRkcmVzc29m
KCpmaXJzdCkpOw0KICAgIDwvY29kZT4NCiAgICA8aT5SZXR1cm5zOjwvaT4gPGNvZGU+Zmlyc3Q8
L2NvZGU+DQoJCQkNCjxjb2RlPnRlbXBsYXRlICZsdDtjbGFzcyBUJmd0Ow0Kdm9pZCBkZXN0cm95
X2F0KFQqIGxvY2F0aW9uKTs8L2NvZGU+ICAgIA0KICAgIDxpPkVmZmVjdHM6PC9pPiA8Y29kZT4N
CiAgICAgICAgICAgIGxvY2F0aW9uLT5+VCgpOw0KICAgIDwvY29kZT4NCjwvcHJlPg0KDQo8cCBj
bGFzcz0ic2VjLWJlZ2luIj4yMC43LjEyLjUgICAgPGNvZGU+dW5pbml0aWFsaXplZF9tb3ZlPC9j
b2RlPiAgICAgPHNwYW4+W3VuaW5pdGlhbGl6ZWQubW92ZV08L3NwYW4+PC9wPg0KPHByZT48Y29k
ZT4NCnRlbXBsYXRlICZsdDtjbGFzcyBJbnB1dEl0ZXJhdG9yLCBjbGFzcyBGb3J3YXJkSXRlcmF0
b3ImZ3Q7DQpGb3J3YXJkSXRlcmF0b3IgdW5pbml0aWFsaXplZF9tb3ZlKElucHV0SXRlcmF0b3Ig
Zmlyc3QsIElucHV0SXRlcmF0b3IgbGFzdCwgRm9yd2FyZEl0ZXJhdG9yIHJlc3VsdCk7DQo8L2Nv
ZGU+DQogICAgPGk+RWZmZWN0czo8L2k+DQo8Y29kZT4NCiAgICAgICAgZm9yICg7IGZpcnN0ICE9
IGxhc3Q7ICsrcmVzdWx0LCAodm9pZCkgKytmaXJzdCkNCiAgICAgICAgICAgIDo6bmV3IChzdGF0
aWNfY2FzdCZsdDt2b2lkKiZndDsoYWRkcmVzc29mKCpyZXN1bHQpKSkNCiAgICAgICAgICAgICB0
eXBlbmFtZSBpdGVyYXRvcl90cmFpdHM8Rm9yd2FyZEl0ZXJhdG9yPjo6dmFsdWVfdHlwZShtb3Zl
KCpmaXJzdCkpOw0KPC9jb2RlPg0KICAgIDxpPlJldHVybnM6PC9pPiA8Y29kZT5yZXN1bHQ8L2Nv
ZGU+DQogICAgPGk+UmVtYXJrczo8L2k+IElmIGFuIGV4Y2VwdGlvbiBpcyB0aHJvd24gdGhlcmUg
YXJlIG5vIGVmZmVjdHMgb24gdGhlIHJhbmdlIFtmaXJzdCxsYXN0KS4NCjxjb2RlPgkJDQp0ZW1w
bGF0ZSAmbHQ7Y2xhc3MgSW5wdXRJdGVyYXRvciwgY2xhc3MgU2l6ZSwgY2xhc3MgRm9yd2FyZEl0
ZXJhdG9yJmd0Ow0KRm9yd2FyZEl0ZXJhdG9yIHVuaW5pdGlhbGl6ZWRfbW92ZV9uKElucHV0SXRl
cmF0b3IgZmlyc3QsIFNpemUgY291bnQsIEZvcndhcmRJdGVyYXRvciByZXN1bHQpOyAgICANCjwv
Y29kZT4NCiAgICA8aT5FZmZlY3RzOjwvaT4NCjxjb2RlPg0KICAgICAgICBmb3IgKCA7IG4gPiAw
OyArK3Jlc3VsdCwgKHZvaWQpICsrZmlyc3QsIC0tbikgew0KICAgICAgICAgICAgOjpuZXcgKHN0
YXRpY19jYXN0Jmx0O3ZvaWQqJmd0OyhhZGRyZXNzb2YoKnJlc3VsdCkpKQ0KICAgICAgICAgICAg
dHlwZW5hbWUgaXRlcmF0b3JfdHJhaXRzJmx0O0ZvcndhcmRJdGVyYXRvciZndDs6OnZhbHVlX3R5
cGUobW92ZSgqZmlyc3QpKTsNCiAgICAgICAgfQ0KPC9jb2RlPg0KICAgIDxpPlJldHVybnM6PC9p
PiA8Y29kZT5yZXN1bHQ8L2NvZGU+DQogICAgPGk+UmVtYXJrczo8L2k+IElmIGFuIGV4Y2VwdGlv
biBpcyB0aHJvd24gdGhlcmUgYXJlIG5vIGVmZmVjdHMgb24gdGhlIHJhbmdlIFtmaXJzdCxhZHZh
bmNlKGZpcnN0LGNvdW50KSkuDQo8L3ByZT4JCQ0KPHAgY2xhc3M9InNlYy1iZWdpbiI+IDIwLjcu
MTIuNiAgIDxjb2RlPnVuaW5pdGlhbGl6ZWRfdmFsdWVfY29uc3RydWN0PC9jb2RlPiAgIDxzcGFu
Plt1bmluaXRpYWxpemVkLmNvbnN0cnVjdC52YWx1ZV08L3NwYW4+PC9wPg0KIDxwcmU+PGNvZGU+
DQp0ZW1wbGF0ZSZsdDtjbGFzcyBGb3J3YXJkSXRlcmF0b3ImZ3Q7DQp2b2lkIHVuaW5pdGlhbGl6
ZWRfdmFsdWVfY29uc3RydWN0KEZvcndhcmRJdGVyYXRvciBmaXJzdCwgRm9yd2FyZEl0ZXJhdG9y
IGxhc3QpOw0KPC9jb2RlPiAgICANCiAgICA8aT5FZmZlY3RzOjwvaT4gDQoJPGNvZGU+Zm9yICg7
IGZpcnN0ICE9IGxhc3Q7ICsrZmlyc3QpDQogICAgICAgICAgOjpuZXcgKHN0YXRpY19jYXN0Jmx0
O3ZvaWQqJmd0OyhhZGRyZXNzb2YoKmZpcnN0KSkpDQogICAgICAgICAgICB0eXBlbmFtZSBpdGVy
YXRvcl90cmFpdHMmbHQ7Rm9yd2FyZEl0ZXJhdG9yJmd0Ozo6dmFsdWVfdHlwZXt9Ow0KICAgICAg
ICByZXR1cm4gZmlyc3Q7DQogICAgPC9jb2RlPg0KICAgIDxpPlJlbWFya3M6PC9pPiBJZiBhbiBl
eGNlcHRpb24gaXMgdGhyb3duIHRoZXJlIGFyZSBubyBlZmZlY3RzLg0KPC9wcmU+DQogPHByZT48
Y29kZT4NCnRlbXBsYXRlJmx0O2NsYXNzIEZvcndhcmRJdGVyYXRvciwgY2xhc3MgU2l6ZSZndDsN
CkZvcndhcmRJdGVyYXRvciB1bmluaXRpYWxpemVkX3ZhbHVlX2NvbnN0cnVjdF9uKEZvcndhcmRJ
dGVyYXRvciBmaXJzdCwgU2l6ZSBuKTsNCjwvY29kZT4gICAgDQogICAgPGk+RWZmZWN0czo8L2k+
IA0KCTxjb2RlPmZvciAoOyBuPjA7ICh2b2lkKSsrZmlyc3QsIC0tbikNCiAgICAgICAgICA6Om5l
dyAoc3RhdGljX2Nhc3QmbHQ7dm9pZComZ3Q7KGFkZHJlc3NvZigqZmlyc3QpKSkNCiAgICAgICAg
ICAgIHR5cGVuYW1lIGl0ZXJhdG9yX3RyYWl0cyZsdDtGb3J3YXJkSXRlcmF0b3ImZ3Q7Ojp2YWx1
ZV90eXBle307DQogICAgPC9jb2RlPg0KICAgIDxpPlJldHVybnM6PC9pPiA8Y29kZT5maXJzdDwv
Y29kZT4NCiAgICA8aT5SZW1hcmtzOjwvaT4gSWYgYW4gZXhjZXB0aW9uIGlzIHRocm93biB0aGVy
ZSBhcmUgbm8gZWZmZWN0cy4NCjwvcHJlPg0KIDxwIGNsYXNzPSJzZWMtYmVnaW4iPjIwLjcuMTIu
NyAgPGNvZGU+dW5pbml0aWFsaXplZF9kZWZhdWx0X2NvbnN0cnVjdDwvY29kZT4gICA8c3Bhbj5b
dW5pbml0aWFsaXplZC5jb25zdHJ1Y3QuZGVmYXVsdF08L3NwYW4+PC9wPg0KIDxwcmU+PGNvZGU+
DQp0ZW1wbGF0ZSZsdDtjbGFzcyBGb3J3YXJkSXRlcmF0b3ImZ3Q7DQp2b2lkIHVuaW5pdGlhbGl6
ZWRfZGVmYXVsdF9jb25zdHJ1Y3QoRm9yd2FyZEl0ZXJhdG9yIGZpcnN0LCBGb3J3YXJkSXRlcmF0
b3IgbGFzdCk7DQo8L2NvZGU+ICAgIA0KICAgIDxpPkVmZmVjdHM6PC9pPiANCgk8Y29kZT5mb3Ig
KDsgZmlyc3QgIT0gbGFzdDsgKytmaXJzdCkNCiAgICAgICAgICA6Om5ldyAoc3RhdGljX2Nhc3Qm
bHQ7dm9pZComZ3Q7KGFkZHJlc3NvZigqZmlyc3QpKSkNCiAgICAgICAgICAgIHR5cGVuYW1lIGl0
ZXJhdG9yX3RyYWl0cyZsdDtGb3J3YXJkSXRlcmF0b3ImZ3Q7Ojp2YWx1ZV90eXBlOw0KICAgIDwv
Y29kZT4NCiAgICA8aT5SZW1hcmtzOjwvaT4gSWYgYW4gZXhjZXB0aW9uIGlzIHRocm93biB0aGVy
ZSBhcmUgbm8gZWZmZWN0cy4NCjxjb2RlPg0KdGVtcGxhdGUmbHQ7Y2xhc3MgRm9yd2FyZEl0ZXJh
dG9yLCBjbGFzcyBTaXplJmd0Ow0KRm9yd2FyZEl0ZXJhdG9yIHVuaW5pdGlhbGl6ZWRfZGVmYXVs
dF9jb25zdHJ1Y3RfbihGb3J3YXJkSXRlcmF0b3IgZmlyc3QsIFNpemUgbik7DQo8L2NvZGU+ICAg
IA0KICAgIDxpPkVmZmVjdHM6PC9pPiANCgk8Y29kZT5mb3IgKDsgbj4wOyAodm9pZCkrK2ZpcnN0
LCAtLW4pDQogICAgICAgICAgOjpuZXcgKHN0YXRpY19jYXN0Jmx0O3ZvaWQqJmd0OyhhZGRyZXNz
b2YoKmZpcnN0KSkpDQogICAgICAgICAgICB0eXBlbmFtZSBpdGVyYXRvcl90cmFpdHMmbHQ7Rm9y
d2FyZEl0ZXJhdG9yJmd0Ozo6dmFsdWVfdHlwZTsNCiAgICA8L2NvZGU+DQogICAgPGk+UmV0dXJu
czo8L2k+IDxjb2RlPmZpcnN0PC9jb2RlPg0KICAgIDxpPlJlbWFya3M6PC9pPiBJZiBhbiBleGNl
cHRpb24gaXMgdGhyb3duIHRoZXJlIGFyZSBubyBlZmZlY3RzLg0KPC9wcmU+DQo8L2lucz4NCjxo
Mj4gVi4gUmV2aXNpb24gaGlzdG9yeTwvaDI+DQo8cD4gPGI+UjM8L2I+PC9wPg0KPHVsPg0KPGxp
PiBBZGRlZCA8Y29kZT5kZXN0cm95X248L2NvZGU+LCA8Y29kZT51bmluaXRpYWxpemVkX3ZhbHVl
X2NvbnN0cnVjdF9uPC9jb2RlPiwgPGNvZGU+dW5pbml0aWFsaXplZF9kZWZhdWx0X2NvbnN0cnVj
dF9uPC9jb2RlPiBmb3Igc3ltbWV0cnkgd2l0aCBleGlzdGluZyBhbGdvcml0aG1zLjwvbGk+DQo8
bGk+IFR3ZWFrcyB0byBpdGVyYXRvciBjYXRlZ29yaWVzIGFuZCByZXR1cm4gdmFsdWVzIGZvciBi
ZXR0ZXIgY29ycmVjdG5lc3MgPC9saT4NCjxsaT4gQWRkZWQgPGNvZGU+ZGVzdHJveV9hdDwvY29k
ZT4sIHdoaWNoIG1ha2VzIDxjb2RlPmRlc3Ryb3k8L2NvZGU+IGJvdGggc2ltcGxlciBhbmQgc2Fm
ZXIuPC9saT4NCjxsaT4gUmVmYWN0b3JlZCBbc3BlY2lhbGl6ZWQuYWxnb3JpdGhtXSBmb3Igc2lt
cGxlciB3b3JkaW5nPC9saT4NCjxsaT4gUmVmYWN0b3JlZCBkaXNjdXNzaW9ucyBhbmQgc3VydmV5
cyA8L2xpPg0KPGxpPiBSZWplY3RlZCBhbHRlcm5hdGl2ZSB3b3JkaW5nIGZvciA8Y29kZT51bmlu
aXRpYWxpemVkX21vdmU8L2NvZGU+PC9saT4NCjxsaT4gQWRkZWQgcmVmZXJlbmNlcyB0byBMV0cg
MjQyMiBhbmQgMjU5ODwvbGk+DQo8L3VsPg0KPHA+IDxiPlIyPC9iPjwvcD4NCjx1bD4NCjxsaT4g
SW1wcm92ZWQgZm9ybWF0dGluZzwvbGk+DQo8bGk+IEFkZGVkIGFtZW5kbWVudHMgdG8gPGNvZGU+
bWVtb3J5LnN5bjwvY29kZT4gPC9saT4NCjxsaT4gQWRkZWQgcmV2aXNpb24gaGlzdG9yeSA8L2xp
Pg0KPGxpPiBNYWRlIHdvcmRpbmcgbm9ybWF0aXZlIGFnYWluc3QgbjQ1NjcgPC9saT4NCjxsaT4g
UmVtb3ZlZCBhIHN0cmF5IGFzdGVyaXNrIDwvbGk+DQo8bGk+IFJlYWxpemVkIHRoYXQsIGZvciBw
dXJwb3NlcyBvZiB3b3JkaW5nLCA8Y29kZT51bmluaXRpYWxpemVkX2NvcHk8L2NvZGU+IGFuZCA8
Y29kZT51bmluaXRpYWxpemVkX2NvcHlfbjwvY29kZT4gYXJlIHRyZWF0ZWQgYXMgdGhlIHNhbWUg
YWxnb3JpdGhtLiBBcyBzdWNoLCB3b3JkaW5nIHdoaWNoIHJlZmVycmVkIHRvIGJvdGggPGNvZGU+
dW5pbml0aWFsaXplZF9tb3ZlPC9jb2RlPiBhbmQgPGNvZGU+dW5pbml0aWFsaXplZF9tb3ZlX248
L2NvZGU+IGhhdmUgYmVlbiBzaW1wbGlmaWVkIGRvd24gdG8ganVzdCA8Y29kZT4gdW5pbml0aWFs
aXplZF9tb3ZlPC9jb2RlPjwvbGk+DQo8bGk+IDxjb2RlPmRlc3Ryb3k8L2NvZGU+IHN1cHBvcnRz
IGlucHV0IGl0ZXJhdG9ycyBhbmQgcmV0dXJucyA8Y29kZT5iZWdpbjwvY29kZT48L2xpPg0KPGxp
PiA8Y29kZT5kZXN0cm95PC9jb2RlPiByZXF1aXJlcyB0aGUgdmFsdWUgdHlwZSB0byBiZSBhbiBs
dmFsdWUgcmVmZXJlbmNlIGZvciBpbmNyZWFzZWQgc2FmZXR5LjwvbGk+DQo8L3VsPiANCjxwPiA8
Yj5SMTwvYj48L3A+DQo8dWw+DQo8bGk+IEFkZGVkIHN1cnZleXMgb2YgZXhpc3RpbmcgY29kZTwv
bGk+DQo8bGk+IEFkZGVkIGRpc2N1c3Npb24gYWJvdXQgb3JkZXIgb2YgZGVzdHJ1Y3Rpb24gaW4g
PGNvZGU+ZGVzdHJveTwvY29kZT48L2xpPg0KPGxpPiBBZGRlZCBhbHRlcm5hdGl2ZSB3b3JkaW5n
IGZvciA8Y29kZT51bmluaXRpYWxpemVkX21vdmU8L2NvZGU+PC9saT4NCjxsaT4gRXhlbXB0ZWQg
PGNvZGU+ZGVzdHJveTwvY29kZT4gYW5kIDxjb2RlPnVuaW5pdGlhbGl6ZWRfbW92ZTwvY29kZT4g
ZnJvbSBuby1lZmZlY3RzIHBvbGljeTwvbGk+DQo8L3VsPg0KPHA+IDxiPlIwPC9iPjwvcD4NCjx1
bD4gPGxpPiBJbml0aWFsIHJldmlzaW9uIDwvbGk+PC91bD4NCjxoMj5WSS4gQ3JlZGl0czwvaDI+
DQo8cD5TcGVjaWFsIHRoYW5rcyBpcyBnaXZlbiB0byBCaWxseSBCYWtlciBhbmQgUGF0cmljZSBS
b3kgZm9yIGZlZWRiYWNrIGFuZCBjaGFtcGlvbnNoaXAuIFRoYW5rcyB0byBNaWNoYWVsIFdvbmcg
Zm9yIGhlbHBpbmcgdG8gb3JnYW5pemUgdGhpcyBlZmZvcnQuIFRoYW5rcyB0byBIb3dhcmQgSGlu
bmFudCBmb3IgZmVlZGJhY2sgcmVnYXJkaW5nIDxjb2RlPnVuaW5pdGlhbGl6ZWRfbW92ZTwvY29k
ZT4uPC9wPg0KPC9ib2R5PjwvaHRtbD4=
--089e01183f10f06da605321a6b7c--

.

--001a11447598f573ae05323eb9f4
Content-Type: text/plain; charset=UTF-8

Hi Brent!

Will you be in Oulu? Otherwise, I can re-present it for you. If so, we'll
talk a bit before to ensure I carry your ideas properly.

Cheers!

2016-05-05 11:59 GMT-04:00 Brent Friedman <fourthgeek@gmail.com>:

> Hello all,
>
> The following paper has been in development under SG14 for quite some time
> but has never been brought here to std-proposals. I wanted to get some more
> eyes on it.
>
> The paper proposes the following new algorithms:
>
> uninitialized_value_construct, uninitialized_value_construct_n
> uninitialized_default_construct, uninitialized_default_construct_n
> uninitialized_move, uninitialized_move_n
> destroy, destroy_n, destroy_at
>
> It also makes some wording changes to [specialized.algorithms].
>
> Any thoughts are appreciated.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTtav6T2Gp_dFEba2WLW7Ap5ziZ7KWUDWK46WaEGiyFmg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTtav6T2Gp_dFEba2WLW7Ap5ziZ7KWUDWK46WaEGiyFmg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2awmSeUWUW4yizHf0izOi86jOen_%2BGCBzLUGUhqO1k2g%40mail.gmail.com.

--001a11447598f573ae05323eb9f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi Brent!<br><br></div>Will you be in Oulu? Othe=
rwise, I can re-present it for you. If so, we&#39;ll talk a bit before to e=
nsure I carry your ideas properly.<br><br></div>Cheers!<br></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-05-05 11:59 GMT-04:00 =
Brent Friedman <span dir=3D"ltr">&lt;<a href=3D"mailto:fourthgeek@gmail.com=
" target=3D"_blank">fourthgeek@gmail.com</a>&gt;</span>:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Hello all,<div><br></div><div>The followin=
g paper has been in development under SG14 for quite some time but has neve=
r been brought here to std-proposals. I wanted to get some more eyes on it.=
</div><div><br></div><div>The paper proposes the following new algorithms:<=
/div><div><br></div><div>uninitialized_value_construct, uninitialized_value=
_construct_n</div><div>uninitialized_default_construct, uninitialized_defau=
lt_construct_n</div><div>uninitialized_move, uninitialized_move_n</div><div=
>destroy, destroy_n, destroy_at</div><div><br></div><div>It also makes some=
 wording changes to [specialized.algorithms].</div><div><br></div><div>Any =
thoughts are appreciated.</div></div><span class=3D"HOEnZb"><font color=3D"=
#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTtav6T2Gp_dFEba2WLW7Ap5ziZ7K=
WUDWK46WaEGiyFmg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CADbh%2BeTtav6T2Gp_dFEba2WLW7Ap5ziZ7KWUDWK46WaEGiyFmg%40mail.gmail.c=
om</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2awmSeUWUW4yizHf0izOi86jOen_%2=
BGCBzLUGUhqO1k2g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2awmSeUW=
UW4yizHf0izOi86jOen_%2BGCBzLUGUhqO1k2g%40mail.gmail.com</a>.<br />

--001a11447598f573ae05323eb9f4--

.

On 2016/05/06 0:59 +0900, Brent Friedman wrote:
> The paper proposes the following new algorithms:
>
> uninitialized_value_construct, uninitialized_value_construct_n
> uninitialized_default_construct, uninitialized_default_construct_n
> uninitialized_move, uninitialized_move_n
> destroy, destroy_n, destroy_at

From "III. Discussion" about uninitialized_move():
> Our approach to this problem is to emulate existing behavior throughout
> the language and library. uninitialized_move should behave like
> move-assignment of arrays. Namely, the constructed objects in the
> desination buffer are destroyed and the exception is propagated. This
> matches the behavior of uninitialized_copy and the behavior of algorithm
> move.
("desination" here looks a typo of "destination")

I don't see what "move-assignment of arrays" mean: builtin arrays can't
be assigned. Does it mean the behavior of a default move constructor of
a class with non static data member of array type?

The algorithm move() doesn't destroy the destination on an exception. So
the mention here looks inappropriate.

The proposed wording says:
>   Remarks: If an exception is thrown there are no effects on the range
>     [first,last).
I couldn't see what "on the range [first,last)" is meant for. It looks
saying nothing about the destination, meaning it doesn't match the above
quoted discussion. Also, "no effects on the range [first,last)" sounds
requiring to move back to the original range before destroying the
destination. But it is impossible in general. To match the above quoted
discussion, I think the Remarks should be like this:
  Remarks: If an exception is thrown there are no effects except
    possibly leaving some objects in the range [first,last) moved from.
Same issue applies to uninitialized_move_n().


The following are some editorial issues:

The names of Size argument of uninitialized_move_n() are inconsistent:
  - "Size s" at synopsis
  - "Size count" at declaration in [uninitialized.move]
  - "n" in Effects

In Remarks on uninitialized_move_n(),
>   Remarks: If an exception is thrown there are no effects on the range
>     [first,advance(first,count)).
"[first, first + count)" is more consistent with other descriptions.
See fill_n() for example.

--
k_satoda

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3d1f34cb-5376-f565-7b31-be27c5e2da0f%40f2.dion.ne.jp.

.

--001a1141ab60471fc20532898621
Content-Type: text/plain; charset=UTF-8

>
> Will you be in Oulu?
>

Hi Patrice! Yes, I'm booked to be in Oulu for the whole week.


Katsutoshi Satoda, thanks for the detailed feedback! See below:


>  I don't see what "move-assignment of arrays" mean: builtin arrays can't

 be assigned. Does it mean the behavior of a default move constructor of

 a class with non static data member of array type?


That's unfortunate. I forgot that assignment of arrays isn't a thing. Maybe
I'll change this to refer to std::array or something else. Hm.


The proposed wording says:
> >   Remarks: If an exception is thrown there are no effects on the range
> >     [first,last).


You're right, this was intended to be "... no effects on the range [result,
advance(result, distance(first,last))) ". IE, no effects on the destination
rather than no effects on the source.


 "[first, first + count)" is more consistent with other descriptions.

See fill_n() for example.


As I understand, this + syntax is enabled by specific wording. n4582
25.1.12 devotes an entire paragraph to describing what + means in this
context. I went with advance to avoid copy-pasting that. Would it be better
to copy-paste this paragraph from [algorithms.general]?

On Sat, May 7, 2016 at 9:29 AM, Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
wrote:

> On 2016/05/06 0:59 +0900, Brent Friedman wrote:
> > The paper proposes the following new algorithms:
> >
> > uninitialized_value_construct, uninitialized_value_construct_n
> > uninitialized_default_construct, uninitialized_default_construct_n
> > uninitialized_move, uninitialized_move_n
> > destroy, destroy_n, destroy_at
>
> From "III. Discussion" about uninitialized_move():
> > Our approach to this problem is to emulate existing behavior throughout
> > the language and library. uninitialized_move should behave like
> > move-assignment of arrays. Namely, the constructed objects in the
> > desination buffer are destroyed and the exception is propagated. This
> > matches the behavior of uninitialized_copy and the behavior of algorithm
> > move.
> ("desination" here looks a typo of "destination")
>
> I don't see what "move-assignment of arrays" mean: builtin arrays can't
> be assigned. Does it mean the behavior of a default move constructor of
> a class with non static data member of array type?
>
> The algorithm move() doesn't destroy the destination on an exception. So
> the mention here looks inappropriate.
>
> The proposed wording says:
> >   Remarks: If an exception is thrown there are no effects on the range
> >     [first,last).
> I couldn't see what "on the range [first,last)" is meant for. It looks
> saying nothing about the destination, meaning it doesn't match the above
> quoted discussion. Also, "no effects on the range [first,last)" sounds
> requiring to move back to the original range before destroying the
> destination. But it is impossible in general. To match the above quoted
> discussion, I think the Remarks should be like this:
>   Remarks: If an exception is thrown there are no effects except
>     possibly leaving some objects in the range [first,last) moved from.
> Same issue applies to uninitialized_move_n().
>
>
> The following are some editorial issues:
>
> The names of Size argument of uninitialized_move_n() are inconsistent:
>   - "Size s" at synopsis
>   - "Size count" at declaration in [uninitialized.move]
>   - "n" in Effects
>
> In Remarks on uninitialized_move_n(),
> >   Remarks: If an exception is thrown there are no effects on the range
> >     [first,advance(first,count)).
> "[first, first + count)" is more consistent with other descriptions.
> See fill_n() for example.
>
> --
> k_satoda
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3d1f34cb-5376-f565-7b31-be27c5e2da0f%40f2.dion.ne.jp
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRNz%2Bn9rFbXS%3DSKLZ-z2GM7J_tymWgti5P66hEOF_Ungg%40mail.gmail.com.

--001a1141ab60471fc20532898621
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex">Will you be in Oulu?<br></blockquote><div=
><br></div><div>Hi Patrice! Yes, I&#39;m booked to be in Oulu for the whole=
 week.</div><div><br></div><div><br></div><div>Katsutoshi Satoda, thanks fo=
r the detailed feedback! See below:</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
=C2=A0<span style=3D"font-size:12.8px">I don&#39;t see what &quot;move-assi=
gnment of arrays&quot; mean: builtin arrays can&#39;t</span>=C2=A0</blockqu=
ote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,20=
4);padding-left:1ex">=C2=A0<span style=3D"font-size:12.8px">be assigned. Do=
es it mean the behavior of a default move constructor of</span>=C2=A0</bloc=
kquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204=
,204);padding-left:1ex">=C2=A0<span style=3D"font-size:12.8px">a class with=
 non static data member of array type?</span></blockquote><div><span style=
=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px=
">That&#39;s unfortunate. I forgot that assignment of arrays isn&#39;t a th=
ing. Maybe I&#39;ll change this to refer to std::array or something else. H=
m.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span st=
yle=3D"font-size:12.8px">The proposed wording says:</span><br style=3D"font=
-size:12.8px"><span style=3D"font-size:12.8px">&gt;=C2=A0 =C2=A0Remarks: If=
 an exception is thrown there are no effects on the range</span><br style=
=3D"font-size:12.8px"><span style=3D"font-size:12.8px">&gt;=C2=A0 =C2=A0 =
=C2=A0[first,last).</span></blockquote><div><br></div><div>You&#39;re right=
, this was intended to be &quot;... no effects on the range [result, advanc=
e(result, distance(first,last))) &quot;. IE, no effects on the destination =
rather than no effects on the source.</div><div>=C2=A0</div><div><span styl=
e=3D"font-size:12.8px"><br></span><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex">=C2=A0<span style=3D"f=
ont-size:12.8px">&quot;[first, first + count)&quot; is more consistent with=
 other descriptions.</span>=C2=A0</blockquote><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-st=
yle:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style=
=3D"font-size:12.8px">See fill_n() for example.</span></blockquote></div><d=
iv><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fo=
nt-size:12.8px">As I understand, this + syntax is enabled by specific wordi=
ng. n4582 25.1.12 devotes an entire paragraph to describing what + means in=
 this context. I went with advance to avoid copy-pasting that. Would it be =
better to copy-paste this paragraph from [algorithms.general]?</span></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, May=
 7, 2016 at 9:29 AM, Kazutoshi Satoda <span dir=3D"ltr">&lt;<a href=3D"mail=
to:k_satoda@f2.dion.ne.jp" target=3D"_blank">k_satoda@f2.dion.ne.jp</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2016/0=
5/06 0:59 +0900, Brent Friedman wrote:<br>
&gt; The paper proposes the following new algorithms:<br>
&gt;<br>
&gt; uninitialized_value_construct, uninitialized_value_construct_n<br>
&gt; uninitialized_default_construct, uninitialized_default_construct_n<br>
&gt; uninitialized_move, uninitialized_move_n<br>
&gt; destroy, destroy_n, destroy_at<br>
<br>
</span>From &quot;III. Discussion&quot; about uninitialized_move():<br>
&gt; Our approach to this problem is to emulate existing behavior throughou=
t<br>
&gt; the language and library. uninitialized_move should behave like<br>
&gt; move-assignment of arrays. Namely, the constructed objects in the<br>
&gt; desination buffer are destroyed and the exception is propagated. This<=
br>
&gt; matches the behavior of uninitialized_copy and the behavior of algorit=
hm<br>
&gt; move.<br>
(&quot;desination&quot; here looks a typo of &quot;destination&quot;)<br>
<br>
I don&#39;t see what &quot;move-assignment of arrays&quot; mean: builtin ar=
rays can&#39;t<br>
be assigned. Does it mean the behavior of a default move constructor of<br>
a class with non static data member of array type?<br>
<br>
The algorithm move() doesn&#39;t destroy the destination on an exception. S=
o<br>
the mention here looks inappropriate.<br>
<br>
The proposed wording says:<br>
&gt;=C2=A0 =C2=A0Remarks: If an exception is thrown there are no effects on=
 the range<br>
&gt;=C2=A0 =C2=A0 =C2=A0[first,last).<br>
I couldn&#39;t see what &quot;on the range [first,last)&quot; is meant for.=
 It looks<br>
saying nothing about the destination, meaning it doesn&#39;t match the abov=
e<br>
quoted discussion. Also, &quot;no effects on the range [first,last)&quot; s=
ounds<br>
requiring to move back to the original range before destroying the<br>
destination. But it is impossible in general. To match the above quoted<br>
discussion, I think the Remarks should be like this:<br>
=C2=A0 Remarks: If an exception is thrown there are no effects except<br>
=C2=A0 =C2=A0 possibly leaving some objects in the range [first,last) moved=
 from.<br>
Same issue applies to uninitialized_move_n().<br>
<br>
<br>
The following are some editorial issues:<br>
<br>
The names of Size argument of uninitialized_move_n() are inconsistent:<br>
=C2=A0 - &quot;Size s&quot; at synopsis<br>
=C2=A0 - &quot;Size count&quot; at declaration in [uninitialized.move]<br>
=C2=A0 - &quot;n&quot; in Effects<br>
<br>
In Remarks on uninitialized_move_n(),<br>
&gt;=C2=A0 =C2=A0Remarks: If an exception is thrown there are no effects on=
 the range<br>
&gt;=C2=A0 =C2=A0 =C2=A0[first,advance(first,count)).<br>
&quot;[first, first + count)&quot; is more consistent with other descriptio=
ns.<br>
See fill_n() for example.<br>
<br>
--<br>
k_satoda<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/3d1f34cb-5376-f565-7b31-be27c5=
e2da0f%40f2.dion.ne.jp" rel=3D"noreferrer" target=3D"_blank">https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/3d1f34cb-5376-f565-7b31-be27=
c5e2da0f%40f2.dion.ne.jp</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRNz%2Bn9rFbXS%3DSKLZ-z2GM7J_=
tymWgti5P66hEOF_Ungg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRN=
z%2Bn9rFbXS%3DSKLZ-z2GM7J_tymWgti5P66hEOF_Ungg%40mail.gmail.com</a>.<br />

--001a1141ab60471fc20532898621--

.

------=_Part_3511_926363793.1462942844701
Content-Type: multipart/alternative;
 boundary="----=_Part_3512_1112273276.1462942844701"

------=_Part_3512_1112273276.1462942844701
Content-Type: text/plain; charset=UTF-8



On Wednesday, May 11, 2016 at 12:32:10 AM UTC-4, Brent Friedman wrote:
>
>
>>  "[first, first + count)" is more consistent with other descriptions.
>
> See fill_n() for example.
>
>
> As I understand, this + syntax is enabled by specific wording. n4582
> 25.1.12 devotes an entire paragraph to describing what + means in this
> context. I went with advance to avoid copy-pasting that. Would it be better
> to copy-paste this paragraph from [algorithms.general]?
>

Adding a cross-reference should be sufficient. In any event, you want next,
not advance.

uninitialized_fill_n should not return 'result'. It should return 'first'.

A couple questions:

Why does value_construct use {} and not ()?

What's the use case for destroy() with input-only iterators?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%40isocpp.org.

------=_Part_3512_1112273276.1462942844701
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, May 11, 2016 at 12:32:10 AM UTC-4, B=
rent Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><br></blockquote><div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=C2=A0<spa=
n style=3D"font-size:12.8px">&quot;[first, first + count)&quot; is more con=
sistent with other descriptions.</span>=C2=A0</blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<span style=3D"font-size:12.8px">See fill_n() for example.</span></blockquo=
te></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span =
style=3D"font-size:12.8px">As I understand, this + syntax is enabled by spe=
cific wording. n4582 25.1.12 devotes an entire paragraph to describing what=
 + means in this context. I went with advance to avoid copy-pasting that. W=
ould it be better to copy-paste this paragraph from [algorithms.general]?</=
span></div></div></blockquote><div><br></div><div>Adding a cross-reference =
should be sufficient. In any event, you want next, not advance.=C2=A0</div>=
<div><br></div><div>uninitialized_fill_n should not return &#39;result&#39;=
.. It should return &#39;first&#39;.</div><div><br></div><div>A couple quest=
ions:</div><div><br></div><div>Why does value_construct use {} and not ()?<=
br></div><div><br></div><div>What&#39;s the use case for destroy() with inp=
ut-only iterators?</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594=
%40isocpp.org</a>.<br />

------=_Part_3512_1112273276.1462942844701--
------=_Part_3511_926363793.1462942844701--

.

--001a1134ebe46caabe05328a8872
Content-Type: text/plain; charset=UTF-8

Hi TC,


> Why does value_construct use {} and not ()?
>
This is a fair point to debate. The main benefit I could see of using {}
over () would be to support aggregate initialization of PODs. However,
since the algorithm is called uninitialized_value_construct, and the
standard (in many places) refers to "()" as value initialization,
parentheses are probably more appropriate.



> What's the use case for destroy() with input-only iterators?
>

That is the concept necessary for the algorithm (it's a single pass
algorithm). I don't think there's a reason to restrict it any more than
necessary, especially since the other algorithms use input iterators.
Regardless, I think that destroy provides a very good use case for input
iterators. It seems quite reasonable that some iterator would want to be
considered invalid once the objects that it refers to are destroyed.

On Wed, May 11, 2016 at 12:00 AM, T. C. <rs2740@gmail.com> wrote:

>
>
> On Wednesday, May 11, 2016 at 12:32:10 AM UTC-4, Brent Friedman wrote:
>>
>>
>>>  "[first, first + count)" is more consistent with other descriptions.
>>
>> See fill_n() for example.
>>
>>
>> As I understand, this + syntax is enabled by specific wording. n4582
>> 25.1.12 devotes an entire paragraph to describing what + means in this
>> context. I went with advance to avoid copy-pasting that. Would it be better
>> to copy-paste this paragraph from [algorithms.general]?
>>
>
> Adding a cross-reference should be sufficient. In any event, you want
> next, not advance.
>
> uninitialized_fill_n should not return 'result'. It should return 'first'.
>
> A couple questions:
>
> Why does value_construct use {} and not ()?
>
> What's the use case for destroy() with input-only iterators?
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSqCCt-E6hjZS10Lw77qNCc1J4C6TKBWp6woo1MV%3DN80A%40mail.gmail.com.

--001a1134ebe46caabe05328a8872
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi TC,</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span s=
tyle=3D"font-size:12.8px">Why does value_construct use {} and not ()?</span=
><br></blockquote><div>This is a fair point to debate. The main benefit I c=
ould see of using {} over () would be to support aggregate initialization o=
f PODs. However, since the algorithm is called uninitialized_value_construc=
t, and the standard (in many places) refers to &quot;()&quot; as value init=
ialization, parentheses are probably more appropriate.</div><div><br></div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex">What&#39;s the use case for destroy() wit=
h input-only iterators?<br></blockquote><div><br></div><div>That is the con=
cept necessary for the algorithm (it&#39;s a single pass algorithm). I don&=
#39;t think there&#39;s a reason to restrict it any more than necessary, es=
pecially since the other algorithms use input iterators. Regardless, I thin=
k that destroy provides a very good use case for input iterators. It seems =
quite reasonable that some iterator would want to be considered invalid onc=
e the objects that it refers to are destroyed.</div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Wed, May 11, 2016 at 12:00 AM, =
T. C. <span dir=3D"ltr">&lt;<a href=3D"mailto:rs2740@gmail.com" target=3D"_=
blank">rs2740@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><span class=3D""><br><br>On Wednesday, May 11, 2016 a=
t 12:32:10 AM UTC-4, Brent Friedman wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><br></blockquote><div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:=
1ex">=C2=A0<span style=3D"font-size:12.8px">&quot;[first, first + count)&qu=
ot; is more consistent with other descriptions.</span>=C2=A0</blockquote><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><span style=3D"font-size:12.8px">See fill_n() for example.</=
span></blockquote></div><div><span style=3D"font-size:12.8px"><br></span></=
div><div><span style=3D"font-size:12.8px">As I understand, this + syntax is=
 enabled by specific wording. n4582 25.1.12 devotes an entire paragraph to =
describing what + means in this context. I went with advance to avoid copy-=
pasting that. Would it be better to copy-paste this paragraph from [algorit=
hms.general]?</span></div></div></blockquote><div><br></div></span><div>Add=
ing a cross-reference should be sufficient. In any event, you want next, no=
t advance.=C2=A0</div><div><br></div><div>uninitialized_fill_n should not r=
eturn &#39;result&#39;. It should return &#39;first&#39;.</div><div><br></d=
iv><div>A couple questions:</div><div><br></div><div>Why does value_constru=
ct use {} and not ()?<br></div><div><br></div><div>What&#39;s the use case =
for destroy() with input-only iterators?</div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-=
4e0e-a4e6-bd7474155594%40isocpp.org</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSqCCt-E6hjZS10Lw77qNCc1J4C6T=
KBWp6woo1MV%3DN80A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSqCC=
t-E6hjZS10Lw77qNCc1J4C6TKBWp6woo1MV%3DN80A%40mail.gmail.com</a>.<br />

--001a1134ebe46caabe05328a8872--

.

------=_Part_5291_1200762492.1462946794942
Content-Type: multipart/alternative;
 boundary="----=_Part_5292_1760382622.1462946794943"

------=_Part_5292_1760382622.1462946794943
Content-Type: text/plain; charset=UTF-8



On Wednesday, May 11, 2016 at 1:44:21 AM UTC-4, Brent Friedman wrote:
>
> Hi TC,
>
>
>> Why does value_construct use {} and not ()?
>>
> This is a fair point to debate. The main benefit I could see of using {}
> over () would be to support aggregate initialization of PODs. However,
> since the algorithm is called uninitialized_value_construct, and the
> standard (in many places) refers to "()" as value initialization,
> parentheses are probably more appropriate.
>
>
>
>> What's the use case for destroy() with input-only iterators?
>>
>
> That is the concept necessary for the algorithm (it's a single pass
> algorithm). I don't think there's a reason to restrict it any more than
> necessary, especially since the other algorithms use input iterators.
>

Not for the parameter corresponding to raw memory.


> Regardless, I think that destroy provides a very good use case for input
> iterators. It seems quite reasonable that some iterator would want to be
> considered invalid once the objects that it refers to are destroyed.
>
> I'm not sure I understand the argument. Can you show one input-only
iterator that can be sensibly used with destroy()?

Also, if an input iterator operation throws - which is allowed by your
current specification - you are left with no way to recover.


> On Wed, May 11, 2016 at 12:00 AM, T. C. <rs2...@gmail.com <javascript:>>
> wrote:
>
>>
>>
>> On Wednesday, May 11, 2016 at 12:32:10 AM UTC-4, Brent Friedman wrote:
>>>
>>>
>>>>  "[first, first + count)" is more consistent with other descriptions.
>>>
>>> See fill_n() for example.
>>>
>>>
>>> As I understand, this + syntax is enabled by specific wording. n4582
>>> 25.1.12 devotes an entire paragraph to describing what + means in this
>>> context. I went with advance to avoid copy-pasting that. Would it be better
>>> to copy-paste this paragraph from [algorithms.general]?
>>>
>>
>> Adding a cross-reference should be sufficient. In any event, you want
>> next, not advance.
>>
>> uninitialized_fill_n should not return 'result'. It should return 'first'.
>>
>> A couple questions:
>>
>> Why does value_construct use {} and not ()?
>>
>> What's the use case for destroy() with input-only iterators?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ee07068c-5988-4ac5-81c1-beffc626701e%40isocpp.org.

------=_Part_5292_1760382622.1462946794943
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, May 11, 2016 at 1:44:21 AM UTC-4, Br=
ent Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>Hi TC,</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style=3D"fon=
t-size:12.8px">Why does value_construct use {} and not ()?</span><br></bloc=
kquote><div>This is a fair point to debate. The main benefit I could see of=
 using {} over () would be to support aggregate initialization of PODs. How=
ever, since the algorithm is called uninitialized_value_construct, and the =
standard (in many places) refers to &quot;()&quot; as value initialization,=
 parentheses are probably more appropriate.</div><div><br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,=
204);padding-left:1ex">What&#39;s the use case for destroy() with input-onl=
y iterators?<br></blockquote><div><br></div><div>That is the concept necess=
ary for the algorithm (it&#39;s a single pass algorithm). I don&#39;t think=
 there&#39;s a reason to restrict it any more than necessary, especially si=
nce the other algorithms use input iterators.</div></div></blockquote><div>=
<br></div><div>Not for the parameter corresponding to raw memory.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div> Regardless, I think that destroy provides a very good use case for in=
put iterators. It seems quite reasonable that some iterator would want to b=
e considered invalid once the objects that it refers to are destroyed.</div=
></div><div><br></div></blockquote><div>I&#39;m not sure I understand the a=
rgument. Can you show one input-only iterator that can be sensibly used wit=
h destroy()?=C2=A0</div><div><br></div><div>Also, if an input iterator oper=
ation throws - which is allowed by your current specification - you are lef=
t with no way to recover.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div><div class=3D"gmail_quote">On Wed, May 11, 2016 at 1=
2:00 AM, T. C. <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"_nvxLS4rCAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">rs2...@gmail.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><br><br>On Wednesday, =
May 11, 2016 at 12:32:10 AM UTC-4, Brent Friedman wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex"><br></blockquote><=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,20=
4);padding-left:1ex">=C2=A0<span style=3D"font-size:12.8px">&quot;[first, f=
irst + count)&quot; is more consistent with other descriptions.</span>=C2=
=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><span style=3D"font-size:12.8px">See fill_=
n() for example.</span></blockquote></div><div><span style=3D"font-size:12.=
8px"><br></span></div><div><span style=3D"font-size:12.8px">As I understand=
, this + syntax is enabled by specific wording. n4582 25.1.12 devotes an en=
tire paragraph to describing what + means in this context. I went with adva=
nce to avoid copy-pasting that. Would it be better to copy-paste this parag=
raph from [algorithms.general]?</span></div></div></blockquote><div><br></d=
iv></span><div>Adding a cross-reference should be sufficient. In any event,=
 you want next, not advance.=C2=A0</div><div><br></div><div>uninitialized_f=
ill_n should not return &#39;result&#39;. It should return &#39;first&#39;.=
</div><div><br></div><div>A couple questions:</div><div><br></div><div>Why =
does value_construct use {} and not ()?<br></div><div><br></div><div>What&#=
39;s the use case for destroy() with input-only iterators?</div></div><span=
>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
_nvxLS4rCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"_nvxLS4rCAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/969bd69e-f332-4e0e-<wbr>a4e6-=
bd7474155594%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ee07068c-5988-4ac5-81c1-beffc626701e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ee07068c-5988-4ac5-81c1-beffc626701e=
%40isocpp.org</a>.<br />

------=_Part_5292_1760382622.1462946794943--
------=_Part_5291_1200762492.1462946794942--

.

--Apple-Mail=_5FE084FC-18E4-4429-A42F-0EC5367365CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

For =E2=80=98destroy=E2=80=99 you need =E2=80=98addressof(*iterator)=E2=80=
=99 to be a true pointer to be element
to be destroyed.  That rules out proxy-iterators, which are allowed for
input iterators, but not for forward iterators or better.  That is why the =
other
uninitialized memory algorithms use forward iterators for their =E2=80=98re=
sult=E2=80=99, rather
than simply an output iterator.

AlisdairM

> On May 10, 2016, at 11:44 PM, Brent Friedman <fourthgeek@gmail.com> wrote=
:
>=20
> Hi TC,
> =20
> Why does value_construct use {} and not ()?
> This is a fair point to debate. The main benefit I could see of using {} =
over () would be to support aggregate initialization of PODs. However, sinc=
e the algorithm is called uninitialized_value_construct, and the standard (=
in many places) refers to "()" as value initialization, parentheses are pro=
bably more appropriate.
>=20
> =20
> What's the use case for destroy() with input-only iterators?
>=20
> That is the concept necessary for the algorithm (it's a single pass algor=
ithm). I don't think there's a reason to restrict it any more than necessar=
y, especially since the other algorithms use input iterators. Regardless, I=
 think that destroy provides a very good use case for input iterators. It s=
eems quite reasonable that some iterator would want to be considered invali=
d once the objects that it refers to are destroyed.
>=20
> On Wed, May 11, 2016 at 12:00 AM, T. C. <rs2740@gmail.com <mailto:rs2740@=
gmail.com>> wrote:
>=20
>=20
> On Wednesday, May 11, 2016 at 12:32:10 AM UTC-4, Brent Friedman wrote:
>=20
>  "[first, first + count)" is more consistent with other descriptions.=20
> See fill_n() for example.
>=20
> As I understand, this + syntax is enabled by specific wording. n4582 25.1=
..12 devotes an entire paragraph to describing what + means in this context.=
 I went with advance to avoid copy-pasting that. Would it be better to copy=
-paste this paragraph from [algorithms.general]?
>=20
> Adding a cross-reference should be sufficient. In any event, you want nex=
t, not advance.=20
>=20
> uninitialized_fill_n should not return 'result'. It should return 'first'=
..
>=20
> A couple questions:
>=20
> Why does value_construct use {} and not ()?
>=20
> What's the use case for destroy() with input-only iterators?
>=20
> --=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%40isocpp.=
org <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/969bd69e-=
f332-4e0e-a4e6-bd7474155594%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>.
>=20
>=20
> --=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CADbh%2BeSqCCt-E6hjZS10Lw77qNCc1J4C6TKBWp6woo1=
MV%3DN80A%40mail.gmail.com <https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/CADbh%2BeSqCCt-E6hjZS10Lw77qNCc1J4C6TKBWp6woo1MV%3DN80A%40mai=
l.gmail.com?utm_medium=3Demail&utm_source=3Dfooter>.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/D6EC62AF-5EBA-4A77-8938-2EB382034355%40me.com.

--Apple-Mail=_5FE084FC-18E4-4429-A42F-0EC5367365CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">For =E2=80=98destr=
oy=E2=80=99 you need =E2=80=98addressof(*iterator)=E2=80=99 to be a true po=
inter to be element<div class=3D"">to be destroyed. &nbsp;That rules out pr=
oxy-iterators, which are allowed for</div><div class=3D"">input iterators, =
but not for forward iterators or better. &nbsp;That is why the other</div><=
div class=3D"">uninitialized memory algorithms use forward iterators for th=
eir =E2=80=98result=E2=80=99, rather</div><div class=3D"">than simply an ou=
tput iterator.</div><div class=3D""><br class=3D""></div><div class=3D"">Al=
isdairM</div><div class=3D""><br class=3D""></div><div class=3D""><div><blo=
ckquote type=3D"cite" class=3D""><div class=3D"">On May 10, 2016, at 11:44 =
PM, Brent Friedman &lt;<a href=3D"mailto:fourthgeek@gmail.com" class=3D"">f=
ourthgeek@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-newl=
ine"><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">Hi TC,</di=
v><div class=3D"">&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border=
-left-color:rgb(204,204,204);padding-left:1ex"><span style=3D"font-size:12.=
8px" class=3D"">Why does value_construct use {} and not ()?</span><br class=
=3D""></blockquote><div class=3D"">This is a fair point to debate. The main=
 benefit I could see of using {} over () would be to support aggregate init=
ialization of PODs. However, since the algorithm is called uninitialized_va=
lue_construct, and the standard (in many places) refers to "()" as value in=
itialization, parentheses are probably more appropriate.</div><div class=3D=
""><br class=3D""></div><div class=3D"">&nbsp;</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">What's=
 the use case for destroy() with input-only iterators?<br class=3D""></bloc=
kquote><div class=3D""><br class=3D""></div><div class=3D"">That is the con=
cept necessary for the algorithm (it's a single pass algorithm). I don't th=
ink there's a reason to restrict it any more than necessary, especially sin=
ce the other algorithms use input iterators. Regardless, I think that destr=
oy provides a very good use case for input iterators. It seems quite reason=
able that some iterator would want to be considered invalid once the object=
s that it refers to are destroyed.</div></div><div class=3D"gmail_extra"><b=
r class=3D""><div class=3D"gmail_quote">On Wed, May 11, 2016 at 12:00 AM, T=
.. C. <span dir=3D"ltr" class=3D"">&lt;<a href=3D"mailto:rs2740@gmail.com" t=
arget=3D"_blank" class=3D"">rs2740@gmail.com</a>&gt;</span> wrote:<br class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" class=3D""><span clas=
s=3D""><br class=3D""><br class=3D"">On Wednesday, May 11, 2016 at 12:32:10=
 AM UTC-4, Brent Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr" class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left=
-color:rgb(204,204,204);padding-left:1ex"><br class=3D""></blockquote><div =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204=
,204,204);padding-left:1ex">&nbsp;<span style=3D"font-size:12.8px" class=3D=
"">"[first, first + count)" is more consistent with other descriptions.</sp=
an>&nbsp;</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-co=
lor:rgb(204,204,204);padding-left:1ex"><span style=3D"font-size:12.8px" cla=
ss=3D"">See fill_n() for example.</span></blockquote></div><div class=3D"">=
<span style=3D"font-size:12.8px" class=3D""><br class=3D""></span></div><di=
v class=3D""><span style=3D"font-size:12.8px" class=3D"">As I understand, t=
his + syntax is enabled by specific wording. n4582 25.1.12 devotes an entir=
e paragraph to describing what + means in this context. I went with advance=
 to avoid copy-pasting that. Would it be better to copy-paste this paragrap=
h from [algorithms.general]?</span></div></div></blockquote><div class=3D""=
><br class=3D""></div></span><div class=3D"">Adding a cross-reference shoul=
d be sufficient. In any event, you want next, not advance.&nbsp;</div><div =
class=3D""><br class=3D""></div><div class=3D"">uninitialized_fill_n should=
 not return 'result'. It should return 'first'.</div><div class=3D""><br cl=
ass=3D""></div><div class=3D"">A couple questions:</div><div class=3D""><br=
 class=3D""></div><div class=3D"">Why does value_construct use {} and not (=
)?<br class=3D""></div><div class=3D""><br class=3D""></div><div class=3D""=
>What's the use case for destroy() with input-only iterators?</div></div><s=
pan class=3D""><div class=3D""><br class=3D"webkit-block-placeholder"></div=
>

-- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" class=3D"">std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" class=3D"">std-proposals@isocpp.org</a>.<br class=
=3D""></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
class=3D"">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/969=
bd69e-f332-4e0e-a4e6-bd7474155594%40isocpp.org</a>.<br class=3D"">
</blockquote></div><br class=3D""></div><div class=3D""><br class=3D"webkit=
-block-placeholder"></div>

-- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSqCCt-E6hjZS10Lw77qNCc1J4C6T=
KBWp6woo1MV%3DN80A%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" class=3D"">https://groups.google.com/a/isocpp.org/d/msgid/std-proposal=
s/CADbh%2BeSqCCt-E6hjZS10Lw77qNCc1J4C6TKBWp6woo1MV%3DN80A%40mail.gmail.com<=
/a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/D6EC62AF-5EBA-4A77-8938-2EB382034355%=
40me.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/D6EC62AF-5EBA-4A77-8938-2EB382034355%40m=
e.com</a>.<br />

--Apple-Mail=_5FE084FC-18E4-4429-A42F-0EC5367365CC--

.

--001a1134ebe49efad005332c652e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello all,
Sorry for the delay. It has taken some time to convince myself of your
arguments. :)

I'm not sure I understand the argument. Can you show one input-only
> iterator that can be sensibly used with destroy()?


The use case I had in mind was an iterator for write-combined memory /
non-temporal writes. In those architectures, it's quite important to touch
memory only in strictly linear order, because the writes you make may not
be visible until later. I had envisioned InputIterator as being a good way
to model this concept. After investigating more, it seems like this idea of
a write-combined iterator may not really fit well into any existing
iterator category. InputIterator does still feel like the closest match due
to its single-pass nature.


> Also, if an input iterator operation throws - which is allowed by your
> current specification - you are left with no way to recover.


This algorithm doesn't attempt to catch any exceptions so I'm not sure it's
a problem. If you throw an exception during operator++ then the exception
will propagate out of the function. The other algorithms have to be very
careful to handle exceptions so they can implement the "no effects" policy.
Destroy has no such policy however (and cannot).

For =E2=80=98destroy=E2=80=99 you need =E2=80=98addressof(*iterator)=E2=80=
=99 to be a true pointer to be
> element
> to be destroyed.


This makes sense; a vector<bool>::iterator certainly wouldn't work in this
template. Strictly speaking, this template can work with some
InputIterators which do not qualify as ForwardIterators. Because
ForwardIterators have to be default constructible for example.

Nevertheless, after this feedback and checking with Stepanov (who
originally wrote destroy for STL) I'll be changing it to ForwardIterator.

Thanks all!


On Wed, May 11, 2016 at 4:34 AM, Alisdair Meredith <alisdairm@me.com> wrote=
:

> For =E2=80=98destroy=E2=80=99 you need =E2=80=98addressof(*iterator)=E2=
=80=99 to be a true pointer to be
> element
> to be destroyed.  That rules out proxy-iterators, which are allowed for
> input iterators, but not for forward iterators or better.  That is why th=
e
> other
> uninitialized memory algorithms use forward iterators for their =E2=80=98=
result=E2=80=99,
> rather
> than simply an output iterator.
>
> AlisdairM
>
> On May 10, 2016, at 11:44 PM, Brent Friedman <fourthgeek@gmail.com> wrote=
:
>
> Hi TC,
>
>
>> Why does value_construct use {} and not ()?
>>
> This is a fair point to debate. The main benefit I could see of using {}
> over () would be to support aggregate initialization of PODs. However,
> since the algorithm is called uninitialized_value_construct, and the
> standard (in many places) refers to "()" as value initialization,
> parentheses are probably more appropriate.
>
>
>
>> What's the use case for destroy() with input-only iterators?
>>
>
> That is the concept necessary for the algorithm (it's a single pass
> algorithm). I don't think there's a reason to restrict it any more than
> necessary, especially since the other algorithms use input iterators.
> Regardless, I think that destroy provides a very good use case for input
> iterators. It seems quite reasonable that some iterator would want to be
> considered invalid once the objects that it refers to are destroyed.
>
> On Wed, May 11, 2016 at 12:00 AM, T. C. <rs2740@gmail.com> wrote:
>
>>
>>
>> On Wednesday, May 11, 2016 at 12:32:10 AM UTC-4, Brent Friedman wrote:
>>>
>>>
>>>>  "[first, first + count)" is more consistent with other descriptions.
>>>
>>> See fill_n() for example.
>>>
>>>
>>> As I understand, this + syntax is enabled by specific wording. n4582
>>> 25.1.12 devotes an entire paragraph to describing what + means in this
>>> context. I went with advance to avoid copy-pasting that. Would it be be=
tter
>>> to copy-paste this paragraph from [algorithms.general]?
>>>
>>
>> Adding a cross-reference should be sufficient. In any event, you want
>> next, not advance.
>>
>> uninitialized_fill_n should not return 'result'. It should return 'first=
'.
>>
>> A couple questions:
>>
>> Why does value_construct use {} and not ()?
>>
>> What's the use case for destroy() with input-only iterators?
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/969bd69e-f3=
32-4e0e-a4e6-bd7474155594%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/969bd69e-f=
332-4e0e-a4e6-bd7474155594%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSqC=
Ct-E6hjZS10Lw77qNCc1J4C6TKBWp6woo1MV%3DN80A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSq=
CCt-E6hjZS10Lw77qNCc1J4C6TKBWp6woo1MV%3DN80A%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/D6EC62AF-5EB=
A-4A77-8938-2EB382034355%40me.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/D6EC62AF-5E=
BA-4A77-8938-2EB382034355%40me.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADbh%2BeTY%3Do14nt2YdX9vJxEr7RMQfa-LBFtiAV-YHom=
7By_rLQ%40mail.gmail.com.

--001a1134ebe49efad005332c652e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello all,<div>Sorry for the delay. It has taken some time=
 to convince myself of your arguments. :)</div><div><br></div><blockquote s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex" class=3D"gmail_quo=
te">I&#39;m not sure I understand the argument. Can you show one input-only=
 iterator that can be sensibly used with destroy()?=C2=A0</blockquote><div>=
<div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">T=
he use case I had in mind was an iterator for write-combined memory / non-t=
emporal writes. In those architectures, it&#39;s quite important to touch m=
emory only in strictly linear order, because the writes you make may not be=
 visible until later. I had envisioned InputIterator as being a good way to=
 model this concept. After investigating more, it seems like this idea of a=
 write-combined iterator may not really fit well into any existing iterator=
 category. InputIterator does still feel like the closest match due to its =
single-pass nature.</div><div>=C2=A0</div><blockquote style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">Also, if an inpu=
t iterator operation throws - which is allowed by your current specificatio=
n - you are left with no way to recover.</blockquote><div><br></div><div>Th=
is algorithm doesn&#39;t attempt to catch any exceptions so I&#39;m not sur=
e it&#39;s a problem. If you throw an exception during operator++ then the =
exception will propagate out of the function. The other algorithms have to =
be very careful to handle exceptions so they can implement the &quot;no eff=
ects&quot; policy. Destroy has no such policy however (and cannot).</div></=
div><div><br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padd=
ing-left:1ex" class=3D"gmail_quote"><span style=3D"font-size:12.8px">For =
=E2=80=98destroy=E2=80=99 you need =E2=80=98addressof(*iterator)=E2=80=99 t=
o be a true pointer to be element<br></span>to be destroyed.</blockquote><d=
iv><br></div><div>This makes sense; a vector&lt;bool&gt;::iterator certainl=
y wouldn&#39;t work in this template. Strictly speaking, this template can =
work with some InputIterators which do not qualify as ForwardIterators. Bec=
ause ForwardIterators have to be default constructible for example.</div><d=
iv><br></div><div>Nevertheless, after this feedback and checking with Stepa=
nov (who originally wrote destroy for STL) I&#39;ll be changing it to Forwa=
rdIterator.=C2=A0</div><div><br></div><div>Thanks all!</div><div><br></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, May=
 11, 2016 at 4:34 AM, Alisdair Meredith <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:alisdairm@me.com" target=3D"_blank">alisdairm@me.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word">=
For =E2=80=98destroy=E2=80=99 you need =E2=80=98addressof(*iterator)=E2=80=
=99 to be a true pointer to be element<div>to be destroyed.=C2=A0 That rule=
s out proxy-iterators, which are allowed for</div><div>input iterators, but=
 not for forward iterators or better.=C2=A0 That is why the other</div><div=
>uninitialized memory algorithms use forward iterators for their =E2=80=98r=
esult=E2=80=99, rather</div><div>than simply an output iterator.</div><div>=
<br></div><div>AlisdairM</div><div><br></div><div><div><blockquote type=3D"=
cite"><div><div class=3D"h5"><div>On May 10, 2016, at 11:44 PM, Brent Fried=
man &lt;<a href=3D"mailto:fourthgeek@gmail.com" target=3D"_blank">fourthgee=
k@gmail.com</a>&gt; wrote:</div><br></div></div><div><div><div class=3D"h5"=
><div dir=3D"ltr"><div>Hi TC,</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span =
style=3D"font-size:12.8px">Why does value_construct use {} and not ()?</spa=
n><br></blockquote><div>This is a fair point to debate. The main benefit I =
could see of using {} over () would be to support aggregate initialization =
of PODs. However, since the algorithm is called uninitialized_value_constru=
ct, and the standard (in many places) refers to &quot;()&quot; as value ini=
tialization, parentheses are probably more appropriate.</div><div><br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex">What&#39;s the use case for destroy() wi=
th input-only iterators?<br></blockquote><div><br></div><div>That is the co=
ncept necessary for the algorithm (it&#39;s a single pass algorithm). I don=
&#39;t think there&#39;s a reason to restrict it any more than necessary, e=
specially since the other algorithms use input iterators. Regardless, I thi=
nk that destroy provides a very good use case for input iterators. It seems=
 quite reasonable that some iterator would want to be considered invalid on=
ce the objects that it refers to are destroyed.</div></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Wed, May 11, 2016 at 12:00 AM,=
 T. C. <span dir=3D"ltr">&lt;<a href=3D"mailto:rs2740@gmail.com" target=3D"=
_blank">rs2740@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><span><br><br>On Wednesday, May 11, 2016 at 12:32:10=
 AM UTC-4, Brent Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex"><br></blockquote><div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=C2=
=A0<span style=3D"font-size:12.8px">&quot;[first, first + count)&quot; is m=
ore consistent with other descriptions.</span>=C2=A0</blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-lef=
t:1ex"><span style=3D"font-size:12.8px">See fill_n() for example.</span></b=
lockquote></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">As I understand, this + syntax is enabled=
 by specific wording. n4582 25.1.12 devotes an entire paragraph to describi=
ng what + means in this context. I went with advance to avoid copy-pasting =
that. Would it be better to copy-paste this paragraph from [algorithms.gene=
ral]?</span></div></div></blockquote><div><br></div></span><div>Adding a cr=
oss-reference should be sufficient. In any event, you want next, not advanc=
e.=C2=A0</div><div><br></div><div>uninitialized_fill_n should not return &#=
39;result&#39;. It should return &#39;first&#39;.</div><div><br></div><div>=
A couple questions:</div><div><br></div><div>Why does value_construct use {=
} and not ()?<br></div><div><br></div><div>What&#39;s the use case for dest=
roy() with input-only iterators?</div></div><span><div><br></div>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-4e0e-a4e6-bd7474155594%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/969bd69e-f332-=
4e0e-a4e6-bd7474155594%40isocpp.org</a>.<br>
</blockquote></div><br></div><div><br></div>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSqCCt-E6hjZS10Lw77qNCc1J4C6T=
KBWp6woo1MV%3DN80A%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CADbh%2BeSqCCt-E6hjZS10Lw77qNCc1J4C6TKBWp6woo1MV%3DN80A%40mail.gma=
il.com</a>.<br>
</div></blockquote></div><br></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/D6EC62AF-5EBA-4A77-8938-2EB382034355%=
40me.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">http=
s://groups.google.com/a/isocpp.org/d/msgid/std-proposals/D6EC62AF-5EBA-4A77=
-8938-2EB382034355%40me.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTY%3Do14nt2YdX9vJxEr7RMQfa-L=
BFtiAV-YHom7By_rLQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTY%3=
Do14nt2YdX9vJxEr7RMQfa-LBFtiAV-YHom7By_rLQ%40mail.gmail.com</a>.<br />

--001a1134ebe49efad005332c652e--

.

------=_Part_159_505942828.1463943058721
Content-Type: multipart/alternative;
 boundary="----=_Part_160_1227002953.1463943058721"

------=_Part_160_1227002953.1463943058721
Content-Type: text/plain; charset=UTF-8



On Thursday, May 19, 2016 at 2:51:01 AM UTC-4, Brent Friedman wrote:
>
> Hello all,
> Sorry for the delay. It has taken some time to convince myself of your
> arguments. :)
>
> I'm not sure I understand the argument. Can you show one input-only
>> iterator that can be sensibly used with destroy()?
>
>
> The use case I had in mind was an iterator for write-combined memory /
> non-temporal writes. In those architectures, it's quite important to touch
> memory only in strictly linear order, because the writes you make may not
> be visible until later. I had envisioned InputIterator as being a good way
> to model this concept. After investigating more, it seems like this idea of
> a write-combined iterator may not really fit well into any existing
> iterator category. InputIterator does still feel like the closest match due
> to its single-pass nature.
>
>
>> Also, if an input iterator operation throws - which is allowed by your
>> current specification - you are left with no way to recover.
>
>
> This algorithm doesn't attempt to catch any exceptions so I'm not sure
> it's a problem. If you throw an exception during operator++ then the
> exception will propagate out of the function. The other algorithms have to
> be very careful to handle exceptions so they can implement the "no effects"
> policy. Destroy has no such policy however (and cannot).
>
>
My concern is that the *caller* also has no way to tell which part of the
range has been destroyed and which part hasn't. Of course, this is moot now.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c8c4b6d4-948d-4485-a732-0c6522faf16e%40isocpp.org.

------=_Part_160_1227002953.1463943058721
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, May 19, 2016 at 2:51:01 AM UTC-4, Bre=
nt Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Hello all,<div>Sorry for the delay. It has taken some time to convince=
 myself of your arguments. :)</div><div><br></div><blockquote style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-l=
eft-color:rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">I&#39;m =
not sure I understand the argument. Can you show one input-only iterator th=
at can be sensibly used with destroy()?=C2=A0</blockquote><div><div style=
=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">The use cas=
e I had in mind was an iterator for write-combined memory / non-temporal wr=
ites. In those architectures, it&#39;s quite important to touch memory only=
 in strictly linear order, because the writes you make may not be visible u=
ntil later. I had envisioned InputIterator as being a good way to model thi=
s concept. After investigating more, it seems like this idea of a write-com=
bined iterator may not really fit well into any existing iterator category.=
 InputIterator does still feel like the closest match due to its single-pas=
s nature.</div><div>=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,=
204,204);padding-left:1ex" class=3D"gmail_quote">Also, if an input iterator=
 operation throws - which is allowed by your current specification - you ar=
e left with no way to recover.</blockquote><div><br></div><div>This algorit=
hm doesn&#39;t attempt to catch any exceptions so I&#39;m not sure it&#39;s=
 a problem. If you throw an exception during operator++ then the exception =
will propagate out of the function. The other algorithms have to be very ca=
reful to handle exceptions so they can implement the &quot;no effects&quot;=
 policy. Destroy has no such policy however (and cannot).</div></div><div><=
br></div></div></blockquote><div><br></div><div>My concern is that the *cal=
ler* also has no way to tell which part of the range has been destroyed and=
 which part hasn&#39;t. Of course, this is moot now.</div><div><br></div><d=
iv><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c8c4b6d4-948d-4485-a732-0c6522faf16e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c8c4b6d4-948d-4485-a732-0c6522faf16e=
%40isocpp.org</a>.<br />

------=_Part_160_1227002953.1463943058721--

------=_Part_159_505942828.1463943058721--

.

--001a1147ce7a02a2dc0533b54bb6
Content-Type: text/plain; charset=UTF-8

Hi all,

A question for the ancient ones --

My trolling around on the internet seems to indicate that std::destroy (and
std::construct for default construction) may have existed in a draft of C++
for a very short time.
http://comp.lang.cpp.moderated.narkive.com/LpdLqT2Q/construct-and-destroy-no-longer-in-standard

Any ideas as to how I could go about corroborating this rumor and finding
the reasoning for not including them? Should I ask the LWG mailing list, or
std-discussion?

Thanks!

On Sun, May 22, 2016 at 1:50 PM, T. C. <rs2740@gmail.com> wrote:

>
>
> On Thursday, May 19, 2016 at 2:51:01 AM UTC-4, Brent Friedman wrote:
>>
>> Hello all,
>> Sorry for the delay. It has taken some time to convince myself of your
>> arguments. :)
>>
>> I'm not sure I understand the argument. Can you show one input-only
>>> iterator that can be sensibly used with destroy()?
>>
>>
>> The use case I had in mind was an iterator for write-combined memory /
>> non-temporal writes. In those architectures, it's quite important to touch
>> memory only in strictly linear order, because the writes you make may not
>> be visible until later. I had envisioned InputIterator as being a good way
>> to model this concept. After investigating more, it seems like this idea of
>> a write-combined iterator may not really fit well into any existing
>> iterator category. InputIterator does still feel like the closest match due
>> to its single-pass nature.
>>
>>
>>> Also, if an input iterator operation throws - which is allowed by your
>>> current specification - you are left with no way to recover.
>>
>>
>> This algorithm doesn't attempt to catch any exceptions so I'm not sure
>> it's a problem. If you throw an exception during operator++ then the
>> exception will propagate out of the function. The other algorithms have to
>> be very careful to handle exceptions so they can implement the "no effects"
>> policy. Destroy has no such policy however (and cannot).
>>
>>
> My concern is that the *caller* also has no way to tell which part of the
> range has been destroyed and which part hasn't. Of course, this is moot now.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c8c4b6d4-948d-4485-a732-0c6522faf16e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c8c4b6d4-948d-4485-a732-0c6522faf16e%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRTdX62LJBf16mKqU1w4Y--Or4enBOi0OXwFymN9THnMg%40mail.gmail.com.

--001a1147ce7a02a2dc0533b54bb6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br><div>A question for the ancient ones --</d=
iv></div><div><br></div><div>My trolling around on the internet seems to in=
dicate that std::destroy (and std::construct for default construction) may =
have existed in a draft of C++ for a very short time.</div><div><a href=3D"=
http://comp.lang.cpp.moderated.narkive.com/LpdLqT2Q/construct-and-destroy-n=
o-longer-in-standard">http://comp.lang.cpp.moderated.narkive.com/LpdLqT2Q/c=
onstruct-and-destroy-no-longer-in-standard</a><br></div><div><br></div><div=
>Any ideas as to how I could go about corroborating this rumor and finding =
the reasoning for not including them? Should I ask the LWG mailing list, or=
 std-discussion?</div><div><br></div><div>Thanks!</div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Sun, May 22, 2016 at 1:50 PM=
, T. C. <span dir=3D"ltr">&lt;<a href=3D"mailto:rs2740@gmail.com" target=3D=
"_blank">rs2740@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><span class=3D""><br><br>On Thursday, May 19, 2016 =
at 2:51:01 AM UTC-4, Brent Friedman wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">Hello all,<div>Sorry for the delay. It has taken so=
me time to convince myself of your arguments. :)</div><div><br></div><block=
quote style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-s=
tyle:solid;border-left-color:rgb(204,204,204);padding-left:1ex" class=3D"gm=
ail_quote">I&#39;m not sure I understand the argument. Can you show one inp=
ut-only iterator that can be sensibly used with destroy()?=C2=A0</blockquot=
e><div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12=
..8px">The use case I had in mind was an iterator for write-combined memory =
/ non-temporal writes. In those architectures, it&#39;s quite important to =
touch memory only in strictly linear order, because the writes you make may=
 not be visible until later. I had envisioned InputIterator as being a good=
 way to model this concept. After investigating more, it seems like this id=
ea of a write-combined iterator may not really fit well into any existing i=
terator category. InputIterator does still feel like the closest match due =
to its single-pass nature.</div><div>=C2=A0</div><blockquote style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-le=
ft-color:rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">Also, if =
an input iterator operation throws - which is allowed by your current speci=
fication - you are left with no way to recover.</blockquote><div><br></div>=
<div>This algorithm doesn&#39;t attempt to catch any exceptions so I&#39;m =
not sure it&#39;s a problem. If you throw an exception during operator++ th=
en the exception will propagate out of the function. The other algorithms h=
ave to be very careful to handle exceptions so they can implement the &quot=
;no effects&quot; policy. Destroy has no such policy however (and cannot).<=
/div></div><div><br></div></div></blockquote><div><br></div></span><div>My =
concern is that the *caller* also has no way to tell which part of the rang=
e has been destroyed and which part hasn&#39;t. Of course, this is moot now=
..</div><div><br></div><div><br></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c8c4b6d4-948d-4485-a732-0c6522faf16e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c8c4b6d4-948d-=
4485-a732-0c6522faf16e%40isocpp.org</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRTdX62LJBf16mKqU1w4Y--Or4enB=
Oi0OXwFymN9THnMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRTdX62=
LJBf16mKqU1w4Y--Or4enBOi0OXwFymN9THnMg%40mail.gmail.com</a>.<br />

--001a1147ce7a02a2dc0533b54bb6--

.

On 2016/05/26 11:10 +0900, Brent Friedman wrote:
> A question for the ancient ones --
>
> My trolling around on the internet seems to indicate that std::destroy (and
> std::construct for default construction) may have existed in a draft of C++
> for a very short time.
> http://comp.lang.cpp.moderated.narkive.com/LpdLqT2Q/construct-and-destroy-no-longer-in-standard
>
> Any ideas as to how I could go about corroborating this rumor and finding
> the reasoning for not including them? Should I ask the LWG mailing list, or
> std-discussion?

I'm not an ancient, but found the history about them:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0639.asc
>   Removing Globals construct() and destroy()
>   ------------------------------------------                 26-Jan-95
http://webcache.googleusercontent.com/search?q=cache:Y8oJEsCPx38J:www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0699.ps
(the above is a HTML version of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0699.ps )
> Date: 22 May 1995
....
> Work Group: Library: Utilities Clause 20
> Issue Number: 20-008
> Title: construct() and destroy() functions should be members
http://webcache.googleusercontent.com/search?q=cache:LyG6zR-GumwJ:www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0843.pdf
(the above is a HTML version of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0843.pdf )
> Date: 30 Jan 1996
....
> ** Issue Number: 20-008
> ** Title: construct() and destroy() functions should be members
> ** Resolution: passed


FYI, I found these by searching in the WG21 site reverse chronologically
starting from docs/papers/1998 which means papers before C++98.
https://www.google.com/search?q=site%3Awww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1998+%22destroy%22+%22construct%22
https://www.google.com/search?q=site%3Awww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1997+%22destroy%22+%22construct%22
https://www.google.com/search?q=site%3Awww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1996+%22destroy%22+%22construct%22
https://www.google.com/search?q=site%3Awww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1995+%22destroy%22+%22construct%22

--
k_satoda

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/27b0e9ac-6688-3ae1-54e8-08bd506ea3e8%40f2.dion.ne.jp.

.

--001a113ecd22c41ca00533c2a2d7
Content-Type: text/plain; charset=UTF-8

>
> I'm not an ancient, but found the history about them:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0639.asc


Perfect, thank you!

On Thu, May 26, 2016 at 11:38 AM, Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
wrote:

> On 2016/05/26 11:10 +0900, Brent Friedman wrote:
> > A question for the ancient ones --
> >
> > My trolling around on the internet seems to indicate that std::destroy
> (and
> > std::construct for default construction) may have existed in a draft of
> C++
> > for a very short time.
> >
> http://comp.lang.cpp.moderated.narkive.com/LpdLqT2Q/construct-and-destroy-no-longer-in-standard
> >
> > Any ideas as to how I could go about corroborating this rumor and finding
> > the reasoning for not including them? Should I ask the LWG mailing list,
> or
> > std-discussion?
>
> I'm not an ancient, but found the history about them:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0639.asc
> >   Removing Globals construct() and destroy()
> >   ------------------------------------------                 26-Jan-95
>
> http://webcache.googleusercontent.com/search?q=cache:Y8oJEsCPx38J:www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0699.ps
> (the above is a HTML version of
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0699.ps )
> > Date: 22 May 1995
> ...
> > Work Group: Library: Utilities Clause 20
> > Issue Number: 20-008
> > Title: construct() and destroy() functions should be members
>
> http://webcache.googleusercontent.com/search?q=cache:LyG6zR-GumwJ:www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0843.pdf
> (the above is a HTML version of
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0843.pdf )
> > Date: 30 Jan 1996
> ...
> > ** Issue Number: 20-008
> > ** Title: construct() and destroy() functions should be members
> > ** Resolution: passed
>
>
> FYI, I found these by searching in the WG21 site reverse chronologically
> starting from docs/papers/1998 which means papers before C++98.
>
> https://www.google.com/search?q=site%3Awww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1998+%22destroy%22+%22construct%22
>
> https://www.google.com/search?q=site%3Awww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1997+%22destroy%22+%22construct%22
>
> https://www.google.com/search?q=site%3Awww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1996+%22destroy%22+%22construct%22
>
> https://www.google.com/search?q=site%3Awww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1995+%22destroy%22+%22construct%22
>
> --
> k_satoda
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/27b0e9ac-6688-3ae1-54e8-08bd506ea3e8%40f2.dion.ne.jp
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTGnwyiY4DqOCKpVdaqDvDYtUQS7vdeaT1zH5_7yCEj%2Bg%40mail.gmail.com.

--001a113ecd22c41ca00533c2a2d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><span style=3D"font-size:12.8px">I&#39;m =
not an ancient, but found the history about them:</span><br style=3D"font-s=
ize:12.8px"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1=
995/N0639.asc" rel=3D"noreferrer" target=3D"_blank" style=3D"font-size:12.8=
px">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0639.asc</a></=
blockquote><div>=C2=A0</div>Perfect, thank you!</div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Thu, May 26, 2016 at 11:38 AM, Kazut=
oshi Satoda <span dir=3D"ltr">&lt;<a href=3D"mailto:k_satoda@f2.dion.ne.jp"=
 target=3D"_blank">k_satoda@f2.dion.ne.jp</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><span class=3D"">On 2016/05/26 11:10 +0900, Brent Fr=
iedman wrote:<br>
&gt; A question for the ancient ones --<br>
&gt;<br>
&gt; My trolling around on the internet seems to indicate that std::destroy=
 (and<br>
&gt; std::construct for default construction) may have existed in a draft o=
f C++<br>
&gt; for a very short time.<br>
&gt; <a href=3D"http://comp.lang.cpp.moderated.narkive.com/LpdLqT2Q/constru=
ct-and-destroy-no-longer-in-standard" rel=3D"noreferrer" target=3D"_blank">=
http://comp.lang.cpp.moderated.narkive.com/LpdLqT2Q/construct-and-destroy-n=
o-longer-in-standard</a><br>
&gt;<br>
&gt; Any ideas as to how I could go about corroborating this rumor and find=
ing<br>
&gt; the reasoning for not including them? Should I ask the LWG mailing lis=
t, or<br>
&gt; std-discussion?<br>
<br>
</span>I&#39;m not an ancient, but found the history about them:<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0639.as=
c" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/1995/N0639.asc</a><br>
&gt;=C2=A0 =C2=A0Removing Globals construct() and destroy()<br>
&gt;=C2=A0 =C2=A0------------------------------------------=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A026-Jan-95<br>
<a href=3D"http://webcache.googleusercontent.com/search?q=3Dcache:Y8oJEsCPx=
38J:www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0699.ps" rel=3D"noref=
errer" target=3D"_blank">http://webcache.googleusercontent.com/search?q=3Dc=
ache:Y8oJEsCPx38J:www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0699.ps=
</a><br>
(the above is a HTML version of <a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/1995/N0699.ps" rel=3D"noreferrer" target=3D"_blank">http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0699.ps</a> )<br>
&gt; Date: 22 May 1995<br>
....<br>
&gt; Work Group: Library: Utilities Clause 20<br>
&gt; Issue Number: 20-008<br>
&gt; Title: construct() and destroy() functions should be members<br>
<a href=3D"http://webcache.googleusercontent.com/search?q=3Dcache:LyG6zR-Gu=
mwJ:www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0843.pdf" rel=3D"nore=
ferrer" target=3D"_blank">http://webcache.googleusercontent.com/search?q=3D=
cache:LyG6zR-GumwJ:www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0843.p=
df</a><br>
(the above is a HTML version of <a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/1996/N0843.pdf" rel=3D"noreferrer" target=3D"_blank">htt=
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0843.pdf</a> )<br>
&gt; Date: 30 Jan 1996<br>
....<br>
&gt; ** Issue Number: 20-008<br>
&gt; ** Title: construct() and destroy() functions should be members<br>
&gt; ** Resolution: passed<br>
<br>
<br>
FYI, I found these by searching in the WG21 site reverse chronologically<br=
>
starting from docs/papers/1998 which means papers before C++98.<br>
<a href=3D"https://www.google.com/search?q=3Dsite%3Awww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1998+%22destroy%22+%22construct%22" rel=3D=
"noreferrer" target=3D"_blank">https://www.google.com/search?q=3Dsite%3Awww=
..open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1998+%22destroy%22+%22=
construct%22</a><br>
<a href=3D"https://www.google.com/search?q=3Dsite%3Awww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1997+%22destroy%22+%22construct%22" rel=3D=
"noreferrer" target=3D"_blank">https://www.google.com/search?q=3Dsite%3Awww=
..open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1997+%22destroy%22+%22=
construct%22</a><br>
<a href=3D"https://www.google.com/search?q=3Dsite%3Awww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1996+%22destroy%22+%22construct%22" rel=3D=
"noreferrer" target=3D"_blank">https://www.google.com/search?q=3Dsite%3Awww=
..open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1996+%22destroy%22+%22=
construct%22</a><br>
<a href=3D"https://www.google.com/search?q=3Dsite%3Awww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1995+%22destroy%22+%22construct%22" rel=3D=
"noreferrer" target=3D"_blank">https://www.google.com/search?q=3Dsite%3Awww=
..open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1995+%22destroy%22+%22=
construct%22</a><br>
<br>
--<br>
k_satoda<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/27b0e9ac-6688-3ae1-54e8-08bd50=
6ea3e8%40f2.dion.ne.jp" rel=3D"noreferrer" target=3D"_blank">https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/27b0e9ac-6688-3ae1-54e8-08bd=
506ea3e8%40f2.dion.ne.jp</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTGnwyiY4DqOCKpVdaqDvDYtUQS7v=
deaT1zH5_7yCEj%2Bg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTGnw=
yiY4DqOCKpVdaqDvDYtUQS7vdeaT1zH5_7yCEj%2Bg%40mail.gmail.com</a>.<br />

--001a113ecd22c41ca00533c2a2d7--

.