--e89a8fb1f846aae6ea04d1ca048c
Content-Type: text/plain; charset=ISO-8859-1

Hi folks,

I finally have an update for the string_ref proposal, converting it to
a set of changes against the C++14 draft. The most recent version
lives at https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
and I've attached a snapshot.

The LWG is still deciding whether this should aim for a TS or C++14
(or both?), and feedback from here will help inform that decision.
This paper currently assumes C++14.

Let me know what you think,
Jeffrey Yasskin

--




--e89a8fb1f846aae6ea04d1ca048c
Content-Type: text/html; name="string_ref.html"
Content-Disposition: attachment; filename="string_ref.html"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hb73v5t70

PCFET0NUWVBFIGh0bWw+CjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1s
Ij4KICA8aGVhZD4KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDtjaGFyc2V0PVVURi04IiBo
dHRwLWVxdWl2PSJDb250ZW50LVR5cGUiLz4KICAgIDxtZXRhIGNoYXJzZXQ9IlVURi04Ii8+CiAg
ICA8dGl0bGU+c3RyaW5nX3JlZjogYSBub24tb3duaW5nIHJlZmVyZW5jZSB0byBhIHN0cmluZywg
cmV2aXNpb24gMS41PC90aXRsZT4KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KYm9keSB7Y29sb3I6
ICMwMDAwMDA7IGJhY2tncm91bmQtY29sb3I6ICNGRkZGRkY7fQoKZGVsIHt0ZXh0LWRlY29yYXRp
b246IGxpbmUtdGhyb3VnaDsgY29sb3I6ICM4QjAwNDA7fQppbnMge3RleHQtZGVjb3JhdGlvbjog
dW5kZXJsaW5lOyBjb2xvcjogIzAwNTEwMDt9CgpwcmUgPiBjb2RlOm9ubHktY2hpbGQge2Rpc3Bs
YXk6IGlubGluZS1ibG9jazsgd2hpdGUtc3BhY2U6IGluaGVyaXR9CmNvZGUge3doaXRlLXNwYWNl
OiBub3dyYXB9CmNvZGUgd2JyIHt3aGl0ZS1zcGFjZTogbm9ybWFsfQoKLyoKLndvcmRpbmcgeyBt
YXgtd2lkdGg6IDkwZXg7IH0KLndvcmRpbmcgLnNlY3RudW0geyBtYXJnaW4tcmlnaHQ6IDFlbTsg
fQoud29yZGluZyAuc2VjdG5hbWUgeyBkaXNwbGF5OiBibG9jazsgZmxvYXQ6IHJpZ2h0OyAgfQoK
c2VjdGlvbi5udW1iZXJlZCB7IGNvdW50ZXItcmVzZXQ6IHBhci1udW07IH0KLndvcmRpbmcgcDpi
ZWZvcmUsIC53b3JkaW5nIGR0OmJlZm9yZSB7CiAgICBjb250ZW50OiBjb3VudGVyKHBhci1udW0p
ICIgIjsgY291bnRlci1pbmNyZW1lbnQ6IHBhci1udW07CiAgICBmb250LXNpemU6IDgwJTsgcG9z
aXRpb246IGFic29sdXRlOyBsZWZ0OiAyZW19CiovCi53b3JkaW5nIHRkIHsgYm9yZGVyLXRvcDog
dGhpbiBzb2xpZCBibGFjazsgYm9yZGVyLWJvdHRvbTogdGhpbiBzb2xpZCBibGFjazsgfQoKc2Vj
dGlvbi5mdW5jdGlvbiB7IGNsZWFyOiBib3RoOyB9Ci5hdHRyaWJ1dGVzLCAuYXR0cmlidXRlIHtt
YXJnaW4tbGVmdDogMmVtfQoKLmRvY2luZm8ge2Zsb2F0OiByaWdodH0KLmRvY2luZm8gcCB7bWFy
Z2luOiAwOyB0ZXh0LWFsaWduOnJpZ2h0OyBmb250LXN0eWxlOiBpdGFsaWN9CgpzZWN0aW9uIHtw
YWRkaW5nLWxlZnQ6IDFlbX0Kc2VjdGlvbiBoZWFkZXIge21hcmdpbi1sZWZ0OiAtMWVtfQoKaDIs
IGgzLCBoNCwgaDUsIGg2IHsgbWFyZ2luLWJvdHRvbTogLjc1ZW0gfQpoNSwgaDYgeyBmb250LXNp
emU6IDFlbTsgfQpwIHttYXJnaW4tdG9wOiAuNWVtOyBtYXJnaW4tYm90dG9tOiAuNWVtfQpwOmZp
cnN0LWNoaWxkLCB1bCwgb2wge21hcmdpbi10b3A6IDB9Ci50b2RvIGR0Om5vdCg6Zmlyc3QtY2hp
bGQpIHttYXJnaW4tdG9wOiAuNWVtfQpwLCBsaSwgZGQsIHRhYmxlIHttYXgtd2lkdGg6IDgwZXh9
Cgp0YWJsZSB7IGJvcmRlcjogZG91YmxlOyBtYXJnaW46IDFlbTsgYm9yZGVyLWNvbGxhcHNlOiBj
b2xsYXBzZTsgfQpjYXB0aW9uIHsgd2hpdGUtc3BhY2U6IHByZTsgfQp0ZCB7IHRleHQtYWxpZ246
IGxlZnQ7IH0KCgouZXhhbXBsZSB7ZGlzcGxheTogaW5saW5lLWJsb2NrOyBjbGVhcjogYm90aDsg
bWFyZ2luLWxlZnQ6IDFleDsKICAgICAgICAgIGJvcmRlcjogdGhpbiBzb2xpZCAjMGUwOyBiYWNr
Z3JvdW5kLWNvbG9yOiAjZjhmOGY4OyBwYWRkaW5nOiAxZXh9CgouZWRub3RlIHtkaXNwbGF5OiBp
bmxpbmUtYmxvY2s7IGNsZWFyOiBib3RoOyBtYXJnaW4tbGVmdDogMWV4OwogICAgICAgICBib3Jk
ZXI6IHRoaW4gc29saWQgIzBlMDsgYmFja2dyb3VuZC1jb2xvcjogI2Y4ZjhmODsgcGFkZGluZzog
MWV4fQoKZGl2LmVkbm90ZSA+ICo6Zmlyc3QtY2hpbGQ6OmJlZm9yZSB7Y29udGVudDogIk5vdGU6
ICI7IGRpc3BsYXk6IGlubGluZTsgZm9udC13ZWlnaHQ6IGJvbGR9CmRpdi5lZG5vdGUge2Rpc3Bs
YXk6IGlubGluZS1ibG9jazsgbWFyZ2luLWxlZnQ6IDFleDsgYm9yZGVyOiB0aGluIHNvbGlkICNm
YjY7CiAgICAgICAgICAgIHBhZGRpbmc6IDFleDsgYmFja2dyb3VuZC1jb2xvcjogI2ZmZjRkZH0K
Cjp0YXJnZXQge2JhY2tncm91bmQtY29sb3I6ICNmZWR9Cjwvc3R5bGU+CjxzY3JpcHQgc3JjPSJo
dHRwczovL2FqYXguZ29vZ2xlYXBpcy5jb20vYWpheC9saWJzL2pxdWVyeS8xLjcuMS9qcXVlcnku
bWluLmpzIiB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPjwvc2NyaXB0Pgo8c2NyaXB0IHR5cGU9InRl
eHQvamF2YXNjcmlwdCI+Ly88IVtDREFUQVsKJChmdW5jdGlvbigpIHsKICAgIHZhciBuZXh0X2lk
ID0gMAogICAgZnVuY3Rpb24gZmluZF9pZChub2RlKSB7CiAgICAgICAgLy8gTG9vayBkb3duIHRo
ZSBmaXJzdCBjaGlsZHJlbiBvZiAnbm9kZScgdW50aWwgd2UgZmluZCBvbmUKICAgICAgICAvLyB3
aXRoIGFuIGlkLiBJZiB3ZSBkb24ndCBmaW5kIG9uZSwgZ2l2ZSAnbm9kZScgYW4gaWQgYW5kCiAg
ICAgICAgLy8gcmV0dXJuIHRoYXQuCiAgICAgICAgdmFyIGN1ciA9IG5vZGVbMF07CiAgICAgICAg
d2hpbGUgKGN1cikgewogICAgICAgICAgICBpZiAoY3VyLmlkKSByZXR1cm4gY3VyLmlkOwogICAg
ICAgICAgICBpZiAoY3VyLnRhZ05hbWUgPT0gJ0EnICYmIGN1ci5uYW1lKQogICAgICAgICAgICAg
ICAgcmV0dXJuIGN1ci5uYW1lOwogICAgICAgICAgICBjdXIgPSBjdXIuZmlyc3RDaGlsZDsKICAg
ICAgICB9OwogICAgICAgIC8vIE5vIGlkLgogICAgICAgIG5vZGUuYXR0cignaWQnLCAnZ2Vuc2Vj
dGlvbi0nICsgbmV4dF9pZCsrKTsKICAgICAgICByZXR1cm4gbm9kZS5hdHRyKCdpZCcpOwogICAg
fTsKCiAgICAvLyBQdXQgYSB0YWJsZSBvZiBjb250ZW50cyBpbiB0aGUgI3RvYyBuYXYuCgogICAg
Ly8gVGhpcyBpcyBhIGxpc3Qgb2YgPG9sPiBlbGVtZW50cywgd2hlcmUgdG9jW05dIGlzIHRoZSBs
aXN0IGZvcgogICAgLy8gdGhlIGN1cnJlbnQgc2VxdWVuY2Ugb2YgPGgoTisyKT4gdGFncy4gV2hl
biBhIGhlYWRlciBvZiBhbgogICAgLy8gZXhpc3RpbmcgbGV2ZWwgaXMgZW5jb3VudGVyZWQsIGFs
bCBoaWdoZXIgbGV2ZWxzIGFyZSBwb3BwZWQsCiAgICAvLyBhbmQgYW4gPGxpPiBpcyBhcHBlbmRl
ZCB0byB0aGUgbGV2ZWwKICAgIHZhciB0b2MgPSBbJCgiPG9sLz4iKV07CiAgICAkKCc6aGVhZGVy
Jykubm90KCdoMScpLmVhY2goZnVuY3Rpb24oKSB7CiAgICAgICAgdmFyIGhlYWRlciA9ICQodGhp
cyk7CiAgICAgICAgLy8gRm9yIGVhY2ggPGhOPiB0YWcsIGFkZCBhIGxpbmsgdG8gdGhlIHRvYyBh
dCB0aGUgYXBwcm9wcmlhdGUKICAgICAgICAvLyBsZXZlbC4gIFdoZW4gdG9jIGlzIG9uZSBlbGVt
ZW50IHRvbyBzaG9ydCwgc3RhcnQgYSBuZXcgbGlzdAogICAgICAgIHZhciBsZXZlbHMgPSB7SDI6
IDAsIEgzOiAxLCBINDogMiwgSDU6IDMsIEg2OiA0fTsKICAgICAgICB2YXIgbGV2ZWwgPSBsZXZl
bHNbdGhpcy50YWdOYW1lXTsKICAgICAgICBpZiAodHlwZW9mIGxldmVsID09ICd1bmRlZmluZWQn
KSB7CiAgICAgICAgICAgIHRocm93ICdVbmV4cGVjdGVkIHRhZzogJyArIHRoaXMudGFnTmFtZTsK
ICAgICAgICB9CiAgICAgICAgLy8gVHJ1bmNhdGUgdG8gdGhlIG5ldyBsZXZlbC4KICAgICAgICB0
b2Muc3BsaWNlKGxldmVsICsgMSwgdG9jLmxlbmd0aCk7CiAgICAgICAgaWYgKHRvYy5sZW5ndGgg
PCBsZXZlbCkgewogICAgICAgICAgICAvLyBPbWl0IFRPQyBlbnRyaWVzIGZvciBza2lwcGVkIGhl
YWRlciBsZXZlbHMuCiAgICAgICAgICAgIHJldHVybjsKICAgICAgICB9CiAgICAgICAgaWYgKHRv
Yy5sZW5ndGggPT0gbGV2ZWwpIHsKICAgICAgICAgICAgLy8gQWRkIGEgPG9sPiB0byB0aGUgcHJl
dmlvdXMgbGV2ZWwncyBsYXN0IDxsaT4gYW5kIHB1c2gKICAgICAgICAgICAgLy8gaXQgaW50byB0
aGUgYXJyYXkuCiAgICAgICAgICAgIHZhciBvbCA9ICQoJzxvbC8+JykKICAgICAgICAgICAgdG9j
W3RvYy5sZW5ndGggLSAxXS5jaGlsZHJlbigpLmxhc3QoKS5hcHBlbmQob2wpOwogICAgICAgICAg
ICB0b2MucHVzaChvbCk7CiAgICAgICAgfQogICAgICAgIHZhciBoZWFkZXJfdGV4dCA9IGhlYWRl
ci50ZXh0KCk7CiAgICAgICAgdG9jW3RvYy5sZW5ndGggLSAxXS5hcHBlbmQoCiAgICAgICAgICAg
ICQoJzxsaS8+JykuYXBwZW5kKCQoJzxhIGhyZWY9IiMnICsgZmluZF9pZChoZWFkZXIpICsgJyIv
PicpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC50ZXh0KGhlYWRlcl90ZXh0KSkpOwog
ICAgfSk7CiAgICAkKCcjdG9jJykuYXBwZW5kKHRvY1swXSk7Cn0pCi8vXV0+PC9zY3JpcHQ+Cjwv
aGVhZD4KPGJvZHk+CiAgPGhlYWRlcj4KICAgIDxkaXYgY2xhc3M9ImRvY2luZm8iPgogICAgICA8
cD5JU08vSUVDIEpUQzEgU0MyMiBXRzIxIE4/Pz8/PC9wPgogICAgICA8cD5EYXRlOiA8dGltZSBw
dWJkYXRlPSIiPjIwMTItMTItMjU8L3RpbWU+PC9wPgogICAgICA8YWRkcmVzcz4KICAgICAgICA8
cD5KZWZmcmV5IFlhc3NraW4gJmx0OzxhIGhyZWY9Im1haWx0bzpqeWFzc2tpbkBnb29nbGUuY29t
Ij5qeWFzc2tpbkBnb29nbGUuY29tPC9hPiZndDs8L3A+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwv
ZGl2PgogICAgPGgxPjxjb2RlPnN0cmluZ19yZWY8L2NvZGU+OiBhIG5vbi1vd25pbmcgcmVmZXJl
bmNlIHRvIGEgc3RyaW5nLCByZXZpc2lvbiAxLjU8L2gxPgogIDwvaGVhZGVyPgogIDxwPjxzbWFs
bD48YSBocmVmPSIjbWFpbmNvbnRlbnQiPlNraXAgdGFibGUgb2YgY29udGVudHM8L2E+PC9zbWFs
bD48L3A+CiAgPG5hdiBpZD0idG9jIj48L25hdj4KICA8YSBpZD0ibWFpbmNvbnRlbnQiPjwvYT4K
ICA8c2VjdGlvbj4KICAgIDxoZWFkZXI+PGgyIGlkPSJvdmVydmlldyI+T3ZlcnZpZXc8L2gyPjwv
aGVhZGVyPgogICAgPHA+VGhpcyBwYXBlciB1cGRhdGVzIDxhCiAgICBocmVmPSJodHRwOi8vd3d3
Lm9wZW4tc3RkLm9yZy9qdGMxL3NjMjIvd2cyMS9kb2NzL3BhcGVycy8yMDEyL24zMzM0Lmh0bWwi
Pk4zMzM0PC9hPgogICAgKDxjb2RlPnN0cmluZ19yZWY8L2NvZGU+ICsgPGNvZGU+YXJyYXlfcmVm
PC9jb2RlPikgYW5kIDxhCiAgICBocmVmPSJodHRwOi8vd3d3Lm9wZW4tc3RkLm9yZy9qdGMxL3Nj
MjIvd2cyMS9kb2NzL3BhcGVycy8yMDEyL24zNDQyLmh0bWwiPk4zNDQyPC9hPgogICAgKDxjb2Rl
PnN0cmluZ19yZWY8L2NvZGU+IGZvciBhIFRTKSB3aXRoIHdvcmRpbmcgZm9yIHRoZSA8YQogICAg
aHJlZj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIyL3dnMjEvZG9jcy9wYXBlcnMv
MjAxMi9uMzQ4NS5wZGYiPmRyYWZ0CiAgICBDKysxNCBzdGFuZGFyZDwvYT4uICBUaGUgPGEKICAg
IGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9nb29nbGUvY3h4LXN0ZC1kcmFmdC9ibG9iL3N0cmlu
Zy1yZWYtcGFwZXIvc3RyaW5nX3JlZi5odG1sIj5tb3N0CiAgICByZWNlbnQgdmVyc2lvbiBvZiB0
aGlzIHBhcGVyPC9hPiBpcyBtYWludGFpbmVkIG9uIEdpdEh1Yi48L3A+CgogICAgPHA+UmVmZXJl
bmNlcyB0byBzdHJpbmdzIGFyZSB2ZXJ5IGNvbW1vbiBpbiBDKysgcHJvZ3JhbXMsIGJ1dAogICAg
b2Z0ZW4gdGhlIGNhbGxlZSBkb2Vzbid0IGNhcmUgYWJvdXQgdGhlIGV4YWN0IHR5cGUgb2YgdGhl
IG9iamVjdAogICAgdGhhdCBvd25zIHRoZSBkYXRhLiAzIHRoaW5ncyBnZW5lcmFsbHkgaGFwcGVu
IGluIHRoaXMgY2FzZTo8L3A+CiAgICA8b2w+CiAgICAgIDxsaT5UaGUgY2FsbGVlIHRha2VzIDxj
b2RlPmNvbnN0IHN0ZDo6c3RyaW5nJjwvY29kZT4gYW5kIGluc2lzdHMKICAgICAgdGhhdCBjYWxs
ZXJzIGNvcHkgdGhlIGRhdGEgaWYgaXQgd2FzIG9yaWdpbmFsbHkgb3duZWQgYnkgYW5vdGhlcgog
ICAgICB0eXBlLjwvbGk+CgogICAgICA8bGk+VGhlIGNhbGxlZSB0YWtlcyB0d28gcGFyYW1ldGVy
cyYjODIxMjthIDxjb2RlPmNoYXIqPC9jb2RlPiBhbmQKICAgICAgYSBsZW5ndGggKG9yIGp1c3Qg
PGNvZGU+Y2hhcio8L2NvZGU+IGFuZCBhc3N1bWVzCiAgICAgIDAtdGVybWluYXRpb24pJiM4MjEy
O2FuZCByZWR1Y2VzIHRoZSByZWFkYWJpbGl0eSBhbmQgc2FmZXR5IG9mCiAgICAgIGNhbGxzIGFu
ZCBsb3NlcyBhbnkgaGVscGVyIGZ1bmN0aW9ucyB0aGUgb3JpZ2luYWwgdHlwZQogICAgICBwcm92
aWRlZC48L2xpPgoKICAgICAgPGxpPlRoZSBjYWxsZWUgaXMgcmV3cml0dGVuIGFzIGEgdGVtcGxh
dGUgYW5kIGl0cyBpbXBsZW1lbnRhdGlvbgogICAgICBpcyBtb3ZlZCB0byBhIGhlYWRlciBmaWxl
LiBUaGlzIGNhbiBpbmNyZWFzZSBmbGV4aWJpbGl0eSBpZiB0aGUKICAgICAgYXV0aG9yIHRha2Vz
IHRoZSB0aW1lIHRvIGNvZGUgdG8gYSB3ZWFrZXIgaXRlcmF0b3IgY29uY2VwdCwgYnV0IGl0CiAg
ICAgIGNhbiBhbHNvIGluY3JlYXNlIGNvbXBpbGUgdGltZSBhbmQgY29kZSBzaXplLCBhbmQgY2Fu
IGV2ZW4KICAgICAgaW50cm9kdWNlIGJ1Z3MgaWYgdGhlIGF1dGhvciBtaXNzZXMgYW4gYXNzdW1w
dGlvbiB0aGF0IHRoZQogICAgICBhcmd1bWVudCdzIGNvbnRlbnRzIGFyZSBjb250aWd1b3VzLjwv
bGk+CiAgICA8L29sPgoKICAgIDxwPkdvb2dsZSwgTExWTSwgYW5kIEJsb29tYmVyZyBoYXZlIGlu
ZGVwZW5kZW50bHkgaW1wbGVtZW50ZWQgYQogICAgc3RyaW5nLXJlZmVyZW5jZSB0eXBlIHRvIGVu
Y2Fwc3VsYXRlIHRoaXMga2luZCBvZiBhcmd1bWVudC4gPGEKICAgIGhyZWY9IiNiYXNpYy5zdHJp
bmcucmVmIj48Y29kZT5zdHJpbmdfcmVmPC9jb2RlPjwvYT4gaXMgaW1wbGljaXRseQogICAgY29u
c3RydWN0aWJsZSBmcm9tIDxjb2RlPmNvbnN0IGNoYXIqPC9jb2RlPiBhbmQgPGNvZGU+c3RkOjpz
dHJpbmc8L2NvZGU+LiBJdAogICAgcHJvdmlkZXMgbW9zdCBvZiB0aGUgPGNvZGU+Y29uc3Q8L2Nv
ZGU+IG1lbWJlciBvcGVyYXRpb25zIGZyb20KICAgIDxjb2RlPnN0ZDo6c3RyaW5nPC9jb2RlPiB0
byBlYXNlIGNvbnZlcnNpb24uIFRoaXMgcGFwZXIgZm9sbG93cyA8YQogICAgaHJlZj0iaHR0cDov
L3NyYy5jaHJvbWl1bS5vcmcvdmlld3ZjL2Nocm9tZS90cnVuay9zcmMvYmFzZS9zdHJpbmdfcGll
Y2UuaD92aWV3PW1hcmt1cCI+Q2hyb21pdW08L2E+CiAgICBhbmQgPGEKICAgIGhyZWY9Imh0dHBz
Oi8vZ2l0aHViLmNvbS9ibG9vbWJlcmcvYnNsL2Jsb2IvbWFzdGVyL2dyb3Vwcy9ic2wvYnNsc3Rs
L2JzbHN0bF9zdHJpbmdyZWYuaCI+Qmxvb21iZXJnPC9hPgogICAgaW4gZXh0ZW5kaW5nIDxjb2Rl
PnN0cmluZ19yZWY8L2NvZGU+IHRvIDxjb2RlPjxhCiAgICBocmVmPSIjYmFzaWMuc3RyaW5nLnJl
ZiI+YmFzaWNfc3RyaW5nX3JlZjwvYT4mbHQ7Y2hhclQsIHRyYWl0cyZndDs8L2NvZGU+CiAgICAo
Ym90aCBvbWl0IDxjb2RlPnRyYWl0czwvY29kZT4pLiBXZSBwcm92aWRlIHR5cGVkZWZzIHRvIHBh
cmFsbGVsIHRoZSA0CiAgICA8Y29kZT5iYXNpY19zdHJpbmc8L2NvZGU+IHR5cGVkZWZzLjwvcD4K
CiAgICA8cD5Cb3RoIEdvb2dsZSdzIGFuZCBMTFZNJ3MgPGNvZGU+c3RyaW5nX3JlZjwvY29kZT4g
dHlwZXMgKGJ1dCBub3QKICAgIEJsb29tYmVyZydzKSBleHRlbmQgdGhlIGludGVyZmFjZSBmcm9t
IDxjb2RlPnN0ZDo6c3RyaW5nPC9jb2RlPiB0byBwcm92aWRlCiAgICBzb21lIGhlbHBmdWwgdXRp
bGl0eSBmdW5jdGlvbnM6PC9wPgogICAgPHVsPgogICAgICA8bGk+PGEgaHJlZj0iI3N0cmluZy5y
ZWYub3BzIj5zdGFydHNfd2l0aDwvYT48L2xpPgogICAgICA8bGk+PGEgaHJlZj0iI3N0cmluZy5y
ZWYub3BzIj5lbmRzX3dpdGg8L2E+PC9saT4KICAgICAgPGxpPjxhIGhyZWY9IiNzdHJpbmcucmVm
Lm1vZGlmaWVycyI+cmVtb3ZlX3ByZWZpeDwvYT48L2xpPgogICAgICA8bGk+PGEgaHJlZj0iI3N0
cmluZy5yZWYubW9kaWZpZXJzIj5yZW1vdmVfc3VmZml4PC9hPjwvbGk+CiAgICAgIDxsaT5zcGxp
dDwvbGk+CiAgICAgIDxsaT50cmltPC9saT4KICAgICAgPGxpPmNvbnN1bWVfcHJlZml4PC9saT4K
ICAgICAgPGxpPmNvdW50PC9saT4KICAgIDwvdWw+CgogICAgPHA+VmVyc2lvbnMgb2YgPGNvZGU+
c3RkOjpzdHJpbmc8L2NvZGU+IG9wZXJhdGlvbnMgdGhhdCB0YWtlCiAgICA8Y29kZT5zdHJpbmdf
cmVmPC9jb2RlPiBpbnN0ZWFkIGFsc28gZ2l2ZSB0aGUgc3RhbmRhcmQgYSB3YXkgdG8gcHJvdmlk
ZQogICAgaW4tcGxhY2Ugb3BlcmF0aW9ucyBvbiBub24tbnVsbC10ZXJtaW5hdGVkIGJ5dGUvY2hh
cmFjdGVyIHNlcXVlbmNlczo8L3A+CiAgICA8dWw+CiAgICAgIDxsaT48YSBocmVmPSIjYmFzaWMu
c3RyaW5nLmhhc2giPmhhc2g8L2E+LCBhcyByZXF1ZXN0ZWQgYnkgYysrc3RkLWxpYi0zMTkzNTwv
bGk+CiAgICAgIDxsaT48YSBocmVmPSIjc3RyaW5nLmNvbnZlcnNpb25zIj5udW1lcmljIGNvbnZl
cnNpb25zPC9hPjwvbGk+CiAgICA8L3VsPgogIDwvc2VjdGlvbj4KCiAgPHNlY3Rpb24+CiAgICA8
aGVhZGVyPjxoMiBpZD0iaW52ZW50aW9ucyI+SW52ZW50aW9ucyBpbiB0aGlzIHBhcGVyPC9oMj48
L2hlYWRlcj4KCiAgICA8cD5Hb29nbGUncyA8Y29kZT5TdHJpbmdQaWVjZTwvY29kZT4gcHJvdmlk
ZXMgPGNvZGU+YXNfc3RyaW5nPC9jb2RlPiBhbmQKICAgIDxjb2RlPlRvU3RyaW5nPC9jb2RlPiBt
ZXRob2RzIHRvIGNvbnZlcnQgdG8gPGNvZGU+c3RkOjpzdHJpbmc8L2NvZGU+LiBMTFZNJ3MKICAg
IDxjb2RlPlN0cmluZ1JlZjwvY29kZT4gcHJvdmlkZXMgYm90aCBhIDxjb2RlPnN0cigpPC9jb2Rl
PiBleHBsaWNpdAogICAgY29udmVyc2lvbiBhbmQgYW4gaW1wbGljaXQgPGNvZGU+b3BlcmF0b3Ig
c3RkOjpzdHJpbmcoKTwvY29kZT4uIFNpbmNlIHRoaXMKICAgIHBhcGVyIGJ1aWxkcyBvbiB0b3Ag
b2YgQysrMTEsIHdlIHByb3ZpZGUgYW4gPGEKICAgIGhyZWY9IiNzdHJpbmcuY29ucyI+PGVtPjxj
b2RlPmV4cGxpY2l0PC9jb2RlPjwvZW0+IGNvbnZlcnNpb24KICAgIGNvbnN0cnVjdG9yPC9hPiBh
cyB3ZWxsIGFzIGEgbGVzcyB2ZXJib3NlIDxhCiAgICBocmVmPSIjc3RyaW5nLnJlZi5ub25tZW0i
Pjxjb2RlPnRvX3N0cmluZzwvY29kZT4gZnVuY3Rpb248L2E+LjwvcD4KCiAgICA8cD5Hb29nbGUn
cyBhbmQgTExWTSdzIDxjb2RlPnN0cmluZ19yZWY8L2NvZGU+IHR5cGVzIHByb3ZpZGUgYSBzdWJz
ZXQgb2YKICAgIDxjb2RlPnN0ZDo6c3RyaW5nPC9jb2RlPidzIHNlYXJjaGluZyBvcGVyYXRpb25z
LCBidXQgdGhleSBkbyBwcm92aWRlCiAgICA8Y29kZT5wb3M8L2NvZGU+IGFyZ3VtZW50cyB0byBz
cGVjaWZ5IHdoZXJlIHRvIHN0YXJ0IHRoZSBzZWFyY2guIEJlY2F1c2UgPGEKICAgIGhyZWY9IiNz
dHJpbmcucmVmLm9wcyI+PGNvZGU+c3RyaW5nX3JlZjo6c3Vic3RyPC9jb2RlPjwvYT4gaXMKICAg
IG11Y2ggY2hlYXBlciB0aGFuIDxjb2RlPnN0cmluZzo6c3Vic3RyPC9jb2RlPiwgdGhpcyBwYXBl
ciByZW1vdmVzIHRoZQogICAgPGNvZGU+cG9zPC9jb2RlPiBhcmd1bWVudCBlbnRpcmVseS48L3A+
CgogICAgPHA+Tm9uZSBvZiB0aGUgZXhpc3RpbmcgY2xhc3NlcyBoYXZlIDxjb2RlPmNvbnN0ZXhw
cjwvY29kZT4gbWV0aG9kcy48L3A+CiAgPC9zZWN0aW9uPgoKICA8c2VjdGlvbj4KICAgIDxoZWFk
ZXI+PGgyIGlkPSJiaWtlc2hlZCI+QmlrZXNoZWQhPC9oMj48L2hlYWRlcj4KICAgIDxwPlBlb3Bs
ZSBzZWVtIGdlbmVyYWxseSBoYXBweSBjYWxsaW5nIHRoaXMgY2xhc3MgInN0cmluZ19yZWYiLCBi
dXQgaWYgYQogICAgY29uc2Vuc3VzIGRldmVsb3BzIGZvciBhbm90aGVyIG9wdGlvbiwgd2UgY2Fu
IGVhc2lseSByZW5hbWUgaXQuICBPdGhlcgogICAgb3B0aW9ucyBpbmNsdWRlOjwvcD4KCiAgICA8
dWw+CiAgICAgIDxsaT5iYXNpY19zdHJpbmdfcmFuZ2UgKG1lYW5pbmcgYSB0ZW1wbGF0ZWQgaXRl
cmF0b3IgcmFuZ2UpPC9saT4KICAgICAgPGxpPmNoYXJfcmFuZ2U8L2xpPgogICAgICA8bGk+Y29u
c3Rfc3RyaW5nX2ZhY2FkZTwvbGk+CiAgICAgIDxsaT5leHRfc3RyaW5nPC9saT4KICAgICAgPGxp
PmV4dGVybmFsX3N0cmluZzwvbGk+CiAgICAgIDxsaT5zdHJfcmVmPC9saT4KICAgICAgPGxpPnN0
cmluZ19jcmVmIChhbmQgc3RyaW5nX3JlZiBmb3Igbm9uLWNvbnN0KTwvbGk+CiAgICAgIDxsaT5z
dHJpbmdfcGllY2U8L2xpPgogICAgICA8bGk+c3RyaW5nX3JhbmdlPC9saT4KICAgICAgPGxpPnN0
cmluZ192aWV3PC9saT4KICAgICAgPGxpPnN1Yl9zdHJpbmc8L2xpPgogICAgPC91bD4KICA8L3Nl
Y3Rpb24+CgogIDxzZWN0aW9uPgogICAgPGhlYWRlcj48aDIgaWQ9Im1vZGlmaWNhdGlvbnMiPk1v
ZGlmaWNhdGlvbnMgdnMgc3RkOjpzdHJpbmc8L2gyPjwvaGVhZGVyPgoKICAgIDxwPlRoZSBpbnRl
cmZhY2Ugb2YgPGNvZGU+c3RyaW5nX3JlZjwvY29kZT4gaXMgc2ltaWxhciB0bywgYnV0IG5vdCBl
eGFjdGx5CiAgICB0aGUgc2FtZSBhcyB0aGUgaW50ZXJmYWNlIG9mIDxjb2RlPnN0ZDo6c3RyaW5n
PC9jb2RlPi4gIEluIGdlbmVyYWwsIHdlIHdhbnQKICAgIHRvIG1pbmltaXplIGRpZmZlcmVuY2Vz
IGJldHdlZW4gPGNvZGU+c3RkOjpzdHJpbmc8L2NvZGU+IGFuZAogICAgPGNvZGU+c3RyaW5nX3Jl
ZjwvY29kZT4gc28gdGhhdCB1c2VycyBjYW4gZ28gYmFjayBhbmQgZm9ydGggYmV0d2VlbiB0aGUg
dHdvCiAgICBvZnRlbi4gIFRoaXMgc2VjdGlvbiBqdXN0aWZpZXMgdGhlIGRpZmZlcmVuY2VzIHdo
b3NlIHV0aWxpdHkgd2UgdGhpbmsKICAgIG92ZXJjb21lcyB0aGF0IGdlbmVyYWwgcnVsZS48L3A+
CgogICAgPGgzIGlkPSJhZGRpdGlvbnMiPkFkZGl0aW9uczwvaDM+CiAgICA8dWw+CiAgICAgIDxs
aT48Y29kZT48YQogICAgICBocmVmPSIjc3RyaW5nLnJlZi5tb2RpZmllcnMiPnJlbW92ZV9wcmVm
aXgoKTwvYT48L2NvZGU+IGFuZAogICAgICA8Y29kZT48YQogICAgICBocmVmPSIjc3RyaW5nLnJl
Zi5tb2RpZmllcnMiPnJlbW92ZV9zdWZmaXgoKTwvYT48L2NvZGU+IG1ha2UKICAgICAgaXQgZWFz
eSB0byBwYXJzZSBzdHJpbmdzIHVzaW5nIDxjb2RlPnN0cmluZ19yZWY8L2NvZGU+LiAgVGhleSBj
b3VsZCBib3RoCiAgICAgIGJlIGltcGxlbWVudGVkIGFzIG5vbi1tZW1iZXIgZnVuY3Rpb25zIChl
LmcuIDxjb2RlPnN0ci5yZW1vdmVfcHJlZml4KG4pCiAgICAgIDx3YnIvPj09PTx3YnIvPiBzdHIg
PSBzdHIuc3Vic3RyKG4pPC9jb2RlPiksIGJ1dCBpdCBzZWVtcyB1c2VmdWwgdG8KICAgICAgcHJv
dmlkZSB0aGUgc2ltcGxlc3QgbXV0YXRvcnMgYXMgbWVtYmVyIGZ1bmN0aW9ucy4gIE5vdGUgdGhh
dCBvdGhlcgogICAgICB0cmF2ZXJzYWwgcHJpbWl0aXZlcyBuZWVkIHRvIGJlIG5vbi1tZW1iZXJz
IHNvIHRoYXQgdGhleSdyZQogICAgICBleHRlbnNpYmxlLCB3aGljaCBtYXkgYXJndWUgZm9yIHB1
bGxpbmcgdGhlc2Ugb3V0IHRvby48L2xpPgoKICAgICAgPGxpPjxhIGhyZWY9IiNzdHJpbmcucmVm
Lm9wcyI+c3RhcnRzX3dpdGg8L2E+IGFuZCA8YQogICAgICBocmVmPSIjc3RyaW5nLnJlZi5vcHMi
PmVuZHNfd2l0aDwvYT4gYXJlIGNvbW1vbiBxdWVyaWVzIG9uCiAgICAgIHN0cmluZ3MuICBUaGUg
bm9uLW1lbWJlciBlcXVpdmFsZW50cyBwcm9kdWNlIGNhbGxzIHRoYXQgYXJlIHNvbWV3aGF0CiAg
ICAgIGFtYmlndW91cyBiZXR3ZWVuIDxjb2RlPnN0YXJ0c193aXRoKGhheXN0YWNrLCBuZWVkbGUp
PC9jb2RlPiB2cwogICAgICA8Y29kZT5zdGFydHNfd2l0aChuZWVkbGUsIGhheXN0YWNrKTwvY29k
ZT4sIHdoaWxlCiAgICAgIDxjb2RlPmhheXN0YWNrLnN0YXJ0c193aXRoKG5lZWRsZSk8L2NvZGU+
IGlzIHRoZSBvbmx5IEVuZ2xpc2ggcmVhZGluZyBvZgogICAgICB0aGUgbWVtYmVyIHZlcnNpb24u
ICBUaGVzZSBxdWVyaWVzIGFwcGx5IGVxdWFsbHkgd2VsbCB0bwogICAgICA8Y29kZT5iYXNpY19z
dHJpbmc8L2NvZGU+LCBzbyBJJ3ZlIDxhCiAgICAgIGhyZWY9IiNzdHJpbmcuc3RhcnRzLmVuZHMu
d2l0aCI+YWRkZWQgdGhlbSB0aGVyZSB0b288L2E+LjwvbGk+CiAgICA8L3VsPgoKICAgIDxoMyBp
ZD0icmVtb3ZhbHMiPlJlbW92YWxzPC9oMz4KICAgIDx1bD4KICAgICAgPGxpPlRoZSA8Y29kZT5j
b3B5PC9jb2RlPiBtZXRob2QgaGFzIGJlZW4gcmVtb3ZlZCBmcm9tCiAgICAgIDxjb2RlPnN0cmlu
Z19yZWY8L2NvZGU+LiAgPGNvZGU+c3RkOjpzdHJpbmc6OmNvcHk8L2NvZGU+IGlzIGNvcHkKICAg
ICAgPGVtPm91dDwvZW0+LCBub3QgaW4uICBJdCdzIG5vdCB3ZWxsIG5hbWVkLiAgVXNlcnMgY2Fu
IGVhc2lseSB1c2UKICAgICAgPGNvZGU+c3RkOjpjb3B5PC9jb2RlPiBpbnN0ZWFkLjwvbGk+Cgog
ICAgICA8bGk+PGNvZGU+cG9zPC9jb2RlPiBhbmQgPGNvZGU+bjwvY29kZT4gcGFyYW1ldGVycyB0
byBtZXRob2RzIGhhdmUgYmVlbgogICAgICByZW1vdmVkIGZyb20gPGNvZGU+c3RyaW5nX3JlZjwv
Y29kZT4uICA8Y29kZT5zdGQ6OnN0cmluZzwvY29kZT4gbmVlZHMKICAgICAgdGhlc2UgcGFyYW1l
dGVycyBiZWNhdXNlIDxjb2RlPnN0ZDo6c3RyaW5nOjpzdWJzdHJpbmc8L2NvZGU+IGlzIGFuCiAg
ICAgIGV4cGVuc2l2ZSAoY29weWluZyBhbmQgc29tZXRpbWVzIGFsbG9jYXRpbmcpIG9wZXJhdGlv
bi4gIEhvd2V2ZXIsIHRoZXNlCiAgICAgIGFyZSBhbHdheXMgaW50ZWdyYWwgcGFyYW1ldGVycywg
c28gdGhlIGNvbXBpbGVyIGNhbid0IGNoZWNrIHRoYXQgdGhlaXIKICAgICAgb3JkZXIgaXMgY29y
cmVjdCwgYW5kIHJlYWRlcnMgb2Z0ZW4gaGF2ZSBhIGhhcmQgdGltZS4gIEJlY2F1c2UgPGNvZGU+
PGEKICAgICAgaHJlZj0iI3N0cmluZy5yZWYub3BzIj5zdHJpbmdfcmVmOjpzdWJzdHI8L2E+PC9j
b2RlPiBpcyBjaGVhcCwKICAgICAgd2UgaW5zaXN0IHVzZXJzIGNhbGwgaXQgaW5zdGVhZCBvZiBw
YXNzaW5nIGl0cyBhcmd1bWVudHMgdG8gb3RoZXIKICAgICAgZnVuY3Rpb25zLjwvbGk+CiAgICA8
L3VsPgoKICA8L3NlY3Rpb24+CgogIDxzZWN0aW9uPgogICAgPGhlYWRlcj48aDIgaWQ9ImxpYi1t
b2RpZmljYXRpb25zIj5Nb2RpZmljYXRpb25zIHRvIHRoZSByZXN0IG9mIHRoZSBzdGFuZGFyZCBs
aWJyYXJ5PC9oMj48L2hlYWRlcj4KICAgIDxwPlRoaXMgcGFwZXIgbWFrZXMKICAgIDxjb2RlPmNo
YXJfdHJhaXRzOjo8L2NvZGU+ezxjb2RlPmxlbmd0aDwvY29kZT4sPGNvZGU+ZmluZDwvY29kZT4s
PGNvZGU+Y29tcGFyZTwvY29kZT59CiAgICA8Y29kZT5jb25zdGV4cHI8L2NvZGU+IHNvIHRoYXQg
PGNvZGU+YmFzaWNfc3RyaW5nX3JlZjwvY29kZT4gY2FuIGJlCiAgICBjb25zdHJ1Y3RlZCBmcm9t
IHN0cmluZyBsaXRlcmFscyBhdCBjb21waWxlIHRpbWUgYW5kIHNvIHRoYXQKICAgIDxjb2RlPmJh
c2ljX3N0cmluZ19yZWY6OjwvY29kZT57PGNvZGU+ZmluZDwvY29kZT4sPGNvZGU+Y29tcGFyZTwv
Y29kZT4sPGNvZGU+b3BlcmF0b3I9PTwvY29kZT4sCiAgICBldGMufSAgY2FuIGJlIDxjb2RlPmNv
bnN0ZXhwcjwvY29kZT4uICA8IS0tVE9ETyB3aGVuIHRoZSBpc3N1ZSBmb3IgdGhpcyBnZXRzCiAg
ICBpbnRvIHRoZSBhY3RpdmUgaXNzdWVzIGxpc3Q6IFRoaXMgaW1wbGVtZW50cyA8YQogICAgaHJl
Zj0iaHR0cDovL2NwbHVzcGx1cy5naXRodWIuY29tL0xXRy9sd2ctYWN0aXZlLmh0bWwjPz8/PyI+
TFdHIElzc3VlCiAgICAjIyM8L2E+Li0tPiBBbiBhbHRlcm5hdGUgd2F5IHRvIGdldCBjb21waWxl
LXRpbWUgPGNvZGU+c3RyaW5nX3JlZjwvY29kZT5zCiAgICB3b3VsZCBiZSB0byBkZWZpbmUgYSB1
c2VyLWRlZmluZWQgbGl0ZXJhbCBvcGVyYXRvciBhJ2xhIDxhCiAgICBocmVmPSJodHRwOi8vd3d3
Lm9wZW4tc3RkLm9yZy9qdGMxL3NjMjIvd2cyMS9kb2NzL3BhcGVycy8yMDEyL24zNDY4LnBkZiI+
TjM0Njg8L2E+LiBBcmd1YWJseSwKICAgIDxjb2RlPmJhc2ljX3N0cmluZ19yZWY8L2NvZGU+IGlz
IGEgYmV0dGVyIGNhbmRpZGF0ZSBmb3IgdGhlIDxjb2RlPiIiczwvY29kZT4KICAgIHN1ZmZpeCB0
aGFuIDxjb2RlPmJhc2ljX3N0cmluZzwvY29kZT4gc2luY2UgPGNvZGU+YmFzaWNfc3RyaW5nPC9j
b2RlPiBpc24ndAogICAgYSBsaXRlcmFsIHR5cGUuPC9wPgoKICAgIDxwPldoZW4gZGVjaWRpbmcg
d2hpY2ggZnVuY3Rpb25zIHRvIGFkZCA8Y29kZT5iYXNpY19zdHJpbmdfcmVmPC9jb2RlPgogICAg
b3ZlcmxvYWRzIHRvLCBJIGZvbGxvd2VkIHRoZSBmb2xsb3dpbmcgcnVsZXM6PC9wPgogICAgPHVs
PgogICAgICA8bGk+SWYgdGhlIGZ1bmN0aW9uIGFscmVhZHkgaGFkIG92ZXJsb2FkcyBmb3IgPGNv
ZGU+Y29uc3QgY2hhcio8L2NvZGU+IGFuZAogICAgICA8Y29kZT5iYXNpY19zdHJpbmc8L2NvZGU+
LCBJIGFkZGVkIGEgPGNvZGU+YmFzaWNfc3RyaW5nX3JlZjwvY29kZT4KICAgICAgb3ZlcmxvYWQu
PC9saT4KCiAgICAgIDxsaT5JZiB0aGUgZnVuY3Rpb24gaGFkIGEgPGNvZGU+YmFzaWNfc3RyaW5n
PC9jb2RlPiBvdmVybG9hZCBidXQgbm90IGEKICAgICAgPGNvZGU+Y29uc3QgY2hhcio8L2NvZGU+
IG92ZXJsb2FkLCBhbmQgPGNvZGU+Y29uc3QgY2hhcio8L2NvZGU+IGFyZ3VtZW50cwogICAgICBj
b3VsZCBub3QgYmUgcGFzc2VkIHdpdGggYW4gaW1wbGljaXQgY29udmVyc2lvbiAoZ2VuZXJhbGx5
IGJlY2F1c2UKICAgICAgdGVtcGxhdGUgYXJndW1lbnQgZGVkdWN0aW9uIHdvdWxkIGZhaWwpLCBJ
IGFkZGVkIGEKICAgICAgPGNvZGU+YmFzaWNfc3RyaW5nX3JlZjwvY29kZT4gb3ZlcmxvYWQuPC9s
aT4KCiAgICAgIDxsaT5JZiB0aGUgZnVuY3Rpb24gaGFkIGEgPGNvZGU+YmFzaWNfc3RyaW5nPC9j
b2RlPiBvdmVybG9hZCBidXQgbm90IGEKICAgICAgPGNvZGU+Y29uc3QgY2hhcio8L2NvZGU+IG92
ZXJsb2FkLCBhbmQgPGNvZGU+Y29uc3QgY2hhcio8L2NvZGU+IGFyZ3VtZW50cwogICAgICA8ZW0+
Y291bGQ8L2VtPiBiZSBwYXNzZWQgd2l0aCBhbiBpbXBsaWNpdCBjb252ZXJzaW9uLCB0aGVuIEkg
ZGlkIG5vdCBhZGQgYQogICAgICA8Y29kZT5iYXNpY19zdHJpbmdfcmVmPC9jb2RlPiBvdmVybG9h
ZCwgb24gdGhlIHRoZW9yeSB0aGF0IGNvcGllcyBhcmUKICAgICAgYWxyZWFkeSBleHBlY3RlZCBh
bmQgY2hlYXAgZW5vdWdoLCBhbmQgYmVjYXVzZSBhZGRpbmcgYQogICAgICA8Y29kZT5iYXNpY19z
dHJpbmdfcmVmPC9jb2RlPiBvdmVybG9hZCB3b3VsZCByZXF1aXJlIGFsc28gYWRkaW5nIGEKICAg
ICAgPGNvZGU+Y29uc3QgY2hhcio8L2NvZGU+IG92ZXJsb2FkIHRvIGF2b2lkIGJyZWFraW5nIHVz
ZXIgY29kZS48L2xpPgogICAgPC91bD4KCiAgICA8cD5JIGRpZG4ndCBhZGQgPGNvZGU+YmFzaWNf
c3RyaW5nX3JlZjwvY29kZT4gb3ZlcmxvYWRzIHRvIGEgZmV3IGZ1bmN0aW9ucwogICAgd2hlcmUg
dGhpcyB3b3VsZCBiZSBoYXJkIHRvIGltcGxlbWVudDo8L3A+CgogICAgPHVsPgogICAgICA8bGk+
VGhlIGxvY2FsZSA8Y29kZT5fYnluYW1lPC9jb2RlPiBmYWNldHMgYXJlIGltcGxlbWVudGVkIG9u
IFVuaXggYnkgZm9yd2FyZGluZwogICAgICB0byBhIEMgbGlicmFyeSBmdW5jdGlvbiB0aGF0IHRh
a2VzIGEgPGNvZGU+J1wwJzwvY29kZT4tdGVybWluYXRlZCBzdHJpbmcsCiAgICAgIHdpdGggbm8g
b3B0aW9uIHRvIHBhc3MgYSBsZW5ndGguICBTaW5jZSBhY2NlcHRpbmcgYQogICAgICA8Y29kZT5z
dHJpbmdfcmVmPC9jb2RlPiB3b3VsZCByZXF1aXJlIGEgY29weSByZWdhcmRsZXNzLCB1c2VycyBt
YXkgYXMgd2VsbAogICAgICBwYXNzIGEgPGNvZGU+c3RyaW5nPC9jb2RlPi48L2xpPgoKICAgICAg
PGxpPlNldmVyYWwgbG9jYWxlIGZhY2V0IG1ldGhvZHMgdGFrZSA8Y29kZT5iYXNpY19zdHJpbmc8
L2NvZGU+LCBhbmQKICAgICAgZm9yd2FyZCB0aGUgYXJndW1lbnQgb24gdG8gYSB2aXJ0dWFsIG1l
dGhvZC4gRGVmaW5pbmcgYSB2ZXJzaW9uIHRha2luZwogICAgICA8Y29kZT5iYXNpY19zdHJpbmdf
cmVmPC9jb2RlPiwgZXZlbiB3aXRoIGEgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbgogICAgICBmb3J3
YXJkaW5nIHRvIHRoZSA8Y29kZT5zdHJpbmc8L2NvZGU+IHZlcnNpb24sIHdvdWxkIGJyZWFrIHVz
ZXIgc3ViY2xhc3NlcwogICAgICBiZWNhdXNlIG9mIGEgY29tbW9uIGNvbXBpbGVyIHdhcm5pbmcg
dGhhdCBmaXJlcyB3aGVuIGEgdmlydHVhbCBtZXRob2QgaXMKICAgICAgaGlkZGVuLiAgVGhpcyBw
cm9wYWdhdGVzIHRvIHRoZSA8Y29kZT5wdXRfbW9uZXk8L2NvZGU+IEkvTyBtYW5pcHVsYXRvci48
L2xpPgogICAgPC91bD4KCiAgICA8cD5JIGFsc28gb21pdHRlZCA8Y29kZT5vcGVyYXRvcisoYmFz
aWNfc3RyaW5nLCBiYXNpY19zdHJpbmdfcmVmKTwvY29kZT4KICAgIGJlY2F1c2UgTExWTSByZXR1
cm5zIGEgbGlnaHR3ZWlnaHQgb2JqZWN0IGZyb20gdGhpcyBvdmVybG9hZCBhbmQgb25seQogICAg
cGVyZm9ybXMgdGhlIGNvbmNhdGVuYXRpb24gbGF6aWx5LiAgSWYgd2UgZGVmaW5lIHRoaXMgb3Zl
cmxvYWQsIHdlJ2xsIGhhdmUgYQogICAgaGFyZCB0aW1lIGludHJvZHVjaW5nIHRoYXQgbGlnaHR3
ZWlnaHQgY29uY2F0ZW5hdGlvbiBsYXRlci48L3A+CgogICAgPHAgaWQ9Im5vLWZpeC0yMjE2Ij5G
b2xsb3dpbmcgdGhlIDxjb2RlPmJhc2ljX3N0cmluZzwvY29kZT4gYW5kIDxjb2RlPmNvbnN0CiAg
ICBjaGFyKjwvY29kZT4gb3ZlcmxvYWRzIG9mIDxjb2RlPnJlZ2V4X3JlcGxhY2UoKTwvY29kZT4s
IHRoZQogICAgPGNvZGU+c3RyaW5nX3JlZjwvY29kZT4gb3ZlcmxvYWRzIGRvbid0IGxldCB0aGUg
dXNlciBzcGVjaWZ5IGFuIGV4cGxpY2l0CiAgICBhbGxvY2F0b3IuICBUaGlzIHNob3VsZCBiZSBm
aXhlZCB3aXRoIHRoZSByZXNvbHV0aW9uIHRvIDxhCiAgICBocmVmPSJodHRwOi8vY3BsdXNwbHVz
LmdpdGh1Yi5jb20vTFdHL2x3Zy1hY3RpdmUuaHRtbCMyMjE2Ij5pc3N1ZSAyMjE2PC9hPi4KICAg
IEkgYmVsaWV2ZSB5b3UgaGF2ZSBlbm91Z2ggdG8gcmVhZCBpbiB0aGlzIHBhcGVyIGFzIGl0IGlz
IGFuZCB0aGF0IGl0IHdvdWxkCiAgICBiZSB1bndpc2UgdG8gamFtIGEgZml4IGludG8gaGVyZS48
L3A+CiAgPC9zZWN0aW9uPgoKICA8c2VjdGlvbj4KICAgIDxoZWFkZXI+PGgyIGlkPSJ3aHktbm90
Ij5XaHkgbm90IGNoYW5nZSAmbHQ7bXktcGV0LWZlYXR1cmU+PzwvaDI+PC9oZWFkZXI+CiAgICA8
cD5JIGhhdmVuJ3QgdGFrZW4gZXZlcnkgc3VnZ2VzdGlvbiB0byBjaGFuZ2UgPGNvZGU+c3RyaW5n
X3JlZjwvY29kZT4uICBUaGlzCiAgICBzZWN0aW9uIGV4cGxhaW5zIHRoZSByYXRpb25hbGVzLjwv
cD4KCiAgICA8c2VjdGlvbj4KICAgICAgPGhlYWRlcj48aDMgaWQ9InJlbW92ZS1maW5kIj5SZW1v
dmUgdGhlIGZpbmQqKCkgbWV0aG9kczwvaDM+PC9oZWFkZXI+CgogICAgICA8cD5NYW55IHBlb3Bs
ZSBoYXZlIGFza2VkIHdoeSB3ZSBhcmVuJ3QgcmVtb3ZpbmcgYWxsIG9mIHRoZQogICAgICA8Y29k
ZT5maW5kPHZhcj4qPC92YXI+PC9jb2RlPiBtZXRob2RzLCBzaW5jZSB0aGV5J3JlIHdpZGVseSBj
b25zaWRlcmVkIGEKICAgICAgd2FydCBvbiA8Y29kZT5zdGQ6OnN0cmluZzwvY29kZT4uICBGaXJz
dCwgd2UnZCBsaWtlIHRvIG1ha2UgaXQgYXMgZWFzeSBhcwogICAgICBwb3NzaWJsZSB0byBjb252
ZXJ0IGNvZGUgdG8gdXNlIDxjb2RlPnN0cmluZ19yZWY8L2NvZGU+LCBzbyBpdCdzIHVzZWZ1bCB0
bwogICAgICBrZWVwIHRoZSBpbnRlcmZhY2UgYXMgc2ltaWxhciBhcyByZWFzb25hYmxlIHRvIDxj
b2RlPnN0ZDo6c3RyaW5nPC9jb2RlPi4KICAgICAgU2Vjb25kLCByZXBsYWNpbmcgdGhlc2UgdGhl
c2UgbWV0aG9kcyB3aXRoIHVzZXMgb2YgdGhlIHN0YW5kYXJkIGFsZ29yaXRobXMKICAgICAgbGli
cmFyeSByZXF1aXJlcyBzd2l0Y2hpbmcgZnJvbSBpbmRpY2VzIHRvIGl0ZXJhdG9ycywgd3JpdGlu
ZwogICAgICBzb21ld2hhdC1jb21wbGljYXRlZCBjb252ZXJzaW9uIGNvZGUsIGFuZC9vciBwYXNz
aW5nIGN1c3RvbSBsYW1iZGFzIHRvCiAgICAgIDxjb2RlPmZpbmRfaWY8L2NvZGU+LiAgTGV0J3Mg
bG9vayBhdCB0aGUgcmVwbGFjZW1lbnQgY29kZSBmb3IgZWFjaCBvZiB0aGUKICAgICAgcmVtYWlu
aW5nIG1ldGhvZHM6PC9wPgoKICAgICAgPGRsPgogICAgICAgIDxkdD48Y29kZT5oYXlzdGFjay5m
aW5kKG5lZWRsZSk8L2NvZGU+PC9kdD4KICAgICAgICA8ZGQ+UmVwbGFjZWQgYnk6CiAgICAgICAg
PHByZSBjbGFzcz0iZXhhbXBsZSI+PGNvZGU+YXV0byBpdGVyID0gc3RkOjpzZWFyY2goaGF5c3Rh
Y2suYmVnaW4oKSwgaGF5c3RhY2suZW5kKCksCiAgICAgICAgICAgICAgICAgICAgICAgIG5lZWRs
ZS5iZWdpbigpLCBuZWVkbGUuZW5kKCkpOwpyZXR1cm4gaXRlciA9PSBoYXlzdGFjay5lbmQoKSA/
IHN0ZDo6c3RyaW5nOjpucG9zIDogaXRlciAtIGhheXN0YWNrLmJlZ2luKCk7PC9jb2RlPjwvcHJl
PjwvZGQ+CgogICAgICAgIDxkdD48Y29kZT5oYXlzdGFjay5yZmluZChuZWVkbGUpPC9jb2RlPjwv
ZHQ+CiAgICAgICAgPGRkPlJlcGxhY2VkIGJ5OgogICAgICAgIDxwcmUgY2xhc3M9ImV4YW1wbGUi
Pjxjb2RlPmF1dG8gaXRlciA9IHN0ZDo6ZmluZF9lbmQoaGF5c3RhY2suYmVnaW4oKSwgaGF5c3Rh
Y2suZW5kKCksCiAgICAgICAgICAgICAgICAgICAgICAgICAgbmVlZGxlLmJlZ2luKCksIG5lZWRs
ZS5lbmQoKSk7CnJldHVybiBpdGVyID09IGhheXN0YWNrLmVuZCgpID8gc3RkOjpzdHJpbmc6Om5w
b3MgOiBpdGVyIC0gaGF5c3RhY2suYmVnaW4oKTs8L2NvZGU+PC9wcmU+PC9kZD4KCiAgICAgICAg
PGR0Pjxjb2RlPmhheXN0YWNrLmZpbmRfZmlyc3Rfb2YobmVlZGxlcyk8L2NvZGU+PC9kdD4KICAg
ICAgICA8ZGQ+UmVwbGFjZWQgYnk6CiAgICAgICAgPHByZSBjbGFzcz0iZXhhbXBsZSI+PGNvZGU+
YXV0byBpdGVyID0gc3RkOjpmaW5kX2ZpcnN0X29mKGhheXN0YWNrLmJlZ2luKCksIGhheXN0YWNr
LmVuZCgpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmVlZGxlcy5iZWdpbigpLCBu
ZWVkbGVzLmVuZCgpKTsKcmV0dXJuIGl0ZXIgPT0gaGF5c3RhY2suZW5kKCkgPyBzdGQ6OnN0cmlu
Zzo6bnBvcyA6IGl0ZXIgLSBoYXlzdGFjay5iZWdpbigpOzwvY29kZT48L3ByZT48L2RkPgoKICAg
ICAgICA8ZHQ+PGNvZGU+aGF5c3RhY2suZmluZF9sYXN0X29mKG5lZWRsZXMpPC9jb2RlPjwvZHQ+
CiAgICAgICAgPGRkPlJlcGxhY2VkIGJ5OgogICAgICAgIDxwcmUgY2xhc3M9ImV4YW1wbGUiPjxj
b2RlPmF1dG8gaXRlciA9IHN0ZDo6ZmluZF9maXJzdF9vZihoYXlzdGFjay48c3Ryb25nPnI8L3N0
cm9uZz5iZWdpbigpLCBoYXlzdGFjay48c3Ryb25nPnI8L3N0cm9uZz5lbmQoKSwKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIG5lZWRsZXMuYmVnaW4oKSwgbmVlZGxlcy5lbmQoKSk7CnJl
dHVybiBpdGVyID09IGhheXN0YWNrLjxzdHJvbmc+cjwvc3Ryb25nPmVuZCgpID8gc3RkOjpzdHJp
bmc6Om5wb3MgOiBpdGVyPHN0cm9uZz4uYmFzZSgpIC0gMTwvc3Ryb25nPiAtIGhheXN0YWNrLmJl
Z2luKCk7PC9jb2RlPjwvcHJlPjwvZGQ+CgogICAgICAgIDxkdD48Y29kZT5oYXlzdGFjay5maW5k
X2ZpcnN0X25vdF9vZihzdHJhdyk8L2NvZGU+PC9kdD4KICAgICAgICA8ZGQ+UmVwbGFjZWQgYnk6
CiAgICAgICAgPHByZSBjbGFzcz0iZXhhbXBsZSI+PGNvZGU+YXV0byBpdGVyID0gc3RkOjpmaW5k
X2lmKGhheXN0YWNrLmJlZ2luKCksIGhheXN0YWNrLmVuZCgpLCBbJmFtcDtdKGNoYXIgYykgewog
IHJldHVybiBzdGQ6OmZpbmQoc3RyYXcuYmVnaW4oKSwgc3RyYXcuZW5kKCksIGMpID09IHN0cmF3
LmVuZCgpOwp9KTsKcmV0dXJuIGl0ZXIgPT0gaGF5c3RhY2suZW5kKCkgPyBzdGQ6OnN0cmluZzo6
bnBvcyA6IGl0ZXIgLSBoYXlzdGFjay5iZWdpbigpOzwvY29kZT48L3ByZT48L2RkPgoKICAgICAg
ICA8ZHQ+PGNvZGU+aGF5c3RhY2suZmluZF9sYXN0X25vdF9vZihzdHJhdyk8L2NvZGU+PC9kdD4K
ICAgICAgICA8ZGQ+UmVwbGFjZWQgYnk6CiAgICAgICAgPHByZSBjbGFzcz0iZXhhbXBsZSI+PGNv
ZGU+YXV0byBpdGVyID0gc3RkOjpmaW5kX2lmKGhheXN0YWNrLjxzdHJvbmc+cjwvc3Ryb25nPmJl
Z2luKCksIGhheXN0YWNrLjxzdHJvbmc+cjwvc3Ryb25nPmVuZCgpLCBbJmFtcDtdKGNoYXIgYykg
ewogIHJldHVybiBzdGQ6OmZpbmQoc3RyYXcuYmVnaW4oKSwgc3RyYXcuZW5kKCksIGMpID09IHN0
cmF3LmVuZCgpOwp9KTsKcmV0dXJuIGl0ZXIgPT0gaGF5c3RhY2suPHN0cm9uZz5yPC9zdHJvbmc+
ZW5kKCkgPyBzdGQ6OnN0cmluZzo6bnBvcyA6IGl0ZXI8c3Ryb25nPi5iYXNlKCkgLSAxPC9zdHJv
bmc+IC0gaGF5c3RhY2suYmVnaW4oKTs8L2NvZGU+PC9wcmU+PC9kZD4KICAgICAgPC9kbD4KCiAg
ICAgIDxwPjxjb2RlPmZpbmQ8L2NvZGU+LCA8Y29kZT5yZmluZDwvY29kZT4sIGFuZCA8Y29kZT5m
aW5kX2ZpcnN0X29mPC9jb2RlPgogICAgICBhcmUgc3RyYWlnaHRmb3J3YXJkLCBhbHRob3VnaCB0
aGUgY29udmVyc2lvbiBmcm9tIGluZGljZXMgdG8gaXRlcmF0b3JzCiAgICAgIHdvdWxkIHByZXZl
bnQgbWFueSB1c2VycyBmcm9tIHN3aXRjaGluZyBldmVuIHRvIHRoZW0uCiAgICAgIDxjb2RlPmZp
bmRfbGFzdF9vZjwvY29kZT4sIDxjb2RlPmZpbmRfZmlyc3Rfbm90X29mPC9jb2RlPiwgYW5kCiAg
ICAgIDxjb2RlPmZpbmRfbGFzdF9ub3Rfb2Y8L2NvZGU+IGdldCBwcm9ncmVzc2l2ZWx5IHdvcnNl
IHRvIGhhbmRsZSBldmVuIGluIGFuCiAgICAgIGl0ZXJhdG9yLWJhc2VkIGZ1bmN0aW9uLjwvcD4K
ICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbj4KICAgICAgPGhlYWRlcj48aDMgaWQ9Im11dGFi
bGUiPk1ha2UgPGNvZGU+YmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyPjwvY29kZT4gbXV0YWJsZTwv
aDM+PC9oZWFkZXI+CgogICAgICA8cD7igKYgYW5kIHVzZSA8Y29kZT5iYXNpY19zdHJpbmdfcmVm
Jmx0O2NvbnN0IGNoYXI+PC9jb2RlPiBmb3IgdGhlIGNvbnN0YW50CiAgICAgIGNhc2UuICBUaGUg
Y29uc3RhbnQgY2FzZSBpcyBlbm91Z2ggbW9yZSBjb21tb24gdGhhbiB0aGUgbXV0YWJsZSBjYXNl
IHRoYXQKICAgICAgaXQgbmVlZHMgdG8gYmUgdGhlIGRlZmF1bHQuICBNYWtpbmcgdGhlIG11dGFi
bGUgY2FzZSB0aGUgZGVmYXVsdCB3b3VsZAogICAgICBwcmV2ZW50IHBhc3Npbmcgc3RyaW5nIGxp
dGVyYWxzIGludG8gPGNvZGU+c3RyaW5nX3JlZjwvY29kZT4gcGFyYW1ldGVycywKICAgICAgd2hp
Y2ggd291bGQgZGVmZWF0IGEgc2lnbmlmaWNhbnQgdXNlIGNhc2UgZm9yIDxjb2RlPnN0cmluZ19y
ZWY8L2NvZGU+LiAgSW4KICAgICAgYSBzb21ld2hhdCBhbmFsb2dvdXMgc2l0YXRpb24sIExMVk0g
ZGVmaW5lZCBhbiA8YQogICAgICBocmVmPSJodHRwOi8vbGx2bS5vcmcvdmlld3ZjL2xsdm0tcHJv
amVjdC9sbHZtL3RydW5rL2luY2x1ZGUvbGx2bS9BRFQvQXJyYXlSZWYuaD92aWV3PWxvZyI+PGNv
ZGU+QXJyYXlSZWY8L2NvZGU+CiAgICAgIGNsYXNzPC9hPiBpbiBGZWIgMjAxMSwgYW5kIGRpZG4n
dCBmaW5kIGEgbmVlZCBmb3IgdGhlIG1hdGNoaW5nCiAgICAgIDxjb2RlPk11dGFibGVBcnJheVJl
ZjwvY29kZT4gdW50aWwgSmFuIDIwMTIuICBUaGV5IHN0aWxsIGhhdmVuJ3QgbmVlZGVkIGEKICAg
ICAgbXV0YWJsZSB2ZXJzaW9uIG9mIDxhCiAgICAgIGhyZWY9Imh0dHA6Ly9sbHZtLm9yZy92aWV3
dmMvbGx2bS1wcm9qZWN0L2xsdm0vdHJ1bmsvaW5jbHVkZS9sbHZtL0FEVC9TdHJpbmdSZWYuaD92
aWV3PW1hcmt1cCI+PGNvZGU+U3RyaW5nUmVmPC9jb2RlPjwvYT4uCiAgICAgIE9uZSBwb3NzaWJs
ZSByZWFzb24gZm9yIHRoaXMgaXMgdGhhdCBtb3N0IHVzZXMgdGhhdCBuZWVkIHRvIG1vZGlmeSBh
CiAgICAgIHN0cmluZyBhbHNvIG5lZWQgdG8gYmUgYWJsZSB0byBjaGFuZ2UgaXRzIGxlbmd0aCwg
YW5kIHRoYXQncyBpbXBvc3NpYmxlCiAgICAgIHRocm91Z2ggZXZlbiBhIG11dGFibGUgdmVyc2lv
biBvZiA8Y29kZT5zdHJpbmdfcmVmPC9jb2RlPi48L3A+CgogICAgICA8cD5XZSA8ZW0+Y291bGQ8
L2VtPiB1c2UgPGNvZGU+dHlwZWRlZiBiYXNpY19zdHJpbmdfcmVmJmx0O2NvbnN0IGNoYXI+CiAg
ICAgIHN0cmluZ19yZWY8L2NvZGU+IHRvIG1ha2UgdGhlIGltbXV0YWJsZSBjYXNlIHRoZSBkZWZh
dWx0IHdoaWxlIHN0aWxsCiAgICAgIHN1cHBvcnRpbmcgdGhlIG11dGFibGUgY2FzZSB1c2luZyB0
aGUgc2FtZSB0ZW1wbGF0ZS4gIEkgaGF2ZW4ndCBnb25lIHRoaXMKICAgICAgd2F5IGJlY2F1c2Ug
aXQgd291bGQgY29tcGxpY2F0ZSB0aGUgdGVtcGxhdGUncyBkZWZpbml0aW9uIHdpdGhvdXQKICAg
ICAgc2lnbmlmaWNhbnRseSBoZWxwaW5nIHVzZXJzLjwvcD4KICAgIDwvc2VjdGlvbj4KCiAgICA8
c2VjdGlvbj4KICAgICAgPGhlYWRlcj48aDMgaWQ9Im9wZXJhdG9yLWJvb2wiPkFkZCBhbiA8Y29k
ZT5leHBsaWNpdCBvcGVyYXRvciBib29sPC9jb2RlPjwvaDM+PC9oZWFkZXI+CgogICAgICA8cD5U
aGlzIHdvdWxkIGJlIGFuIGFiYnJldmlhdGlvbiBmb3IgPGNvZGU+IWVtcHR5KCk8L2NvZGU+LCB1
c2FibGUgZm9yCiAgICAgIGluaXRpYWxpemF0aW9uIGluIDxjb2RlPmlmPC9jb2RlPiBzdGF0ZW1l
bnRzLiAgSSBkaWRuJ3QgYWRkIHRoaXMgYmVjYXVzZQogICAgICBpdCB3b3VsZCBiZSBpbmNvbnNp
c3RlbnQgd2l0aCB0aGUgcmVzdCBvZiB0aGUgY29udGFpbmVycyBsaWJyYXJ5LCBidXQgaWYKICAg
ICAgYW5vdGhlciBwcm9wb3NhbCBhZGRzIGl0IHRvIHRoZSByZXN0IG9mIHRoZSBjb250YWluZXJz
LCB0aGF0IHByb3Bvc2FsCiAgICAgIHNob3VsZCBhbHNvIGFkZCBpdCB0byA8Y29kZT5zdHJpbmdf
cmVmPC9jb2RlPi48L3A+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24+CiAgICAgIDxoZWFk
ZXI+PGgzIGlkPSJhdm9pZC1zdHJsZW4iPkF2b2lkIDxjb2RlPnN0cmxlbigic3RyaW5nIGxpdGVy
YWwiKTwvY29kZT48L2gzPjwvaGVhZGVyPgoKICAgICAgPHA+V2l0aCBhIGNvbnN0cnVjdG9yIG9m
IHRoZSBmb3JtOjwvcD4KICAgICAgPHByZSBjbGFzcz0iZXhhbXBsZSI+PGNvZGU+dGVtcGxhdGUm
bHQ7c2l6ZV90IE4+CmJhc2ljX3N0cmluZ19yZWYoY29uc3QgY2hhclQgKCZhbXA7c3RyKVtOXSk7
PC9jb2RlPjwvcHJlPgogICAgICA8cD53ZSBjb3VsZCBhdm9pZCBhIDxjb2RlPnN0cmxlbigpPC9j
b2RlPiBjYWxsIHdoZW4gYQogICAgICA8Y29kZT5iYXNpY19zdHJpbmdfcmVmPC9jb2RlPiBpcyBj
b25zdHJ1Y3RlZCBmcm9tIGEgc3RyaW5nIGxpdGVyYWwuCiAgICAgIFVuZm9ydHVuYXRlbHksIHRo
aXMgY29uc3RydWN0b3IgZG9lcyBjb21wbGV0ZWx5IHRoZSB3cm9uZyB0aGluZyB3aGVuCiAgICAg
IGNhbGxlZCBsaWtlOjwvcD4KICAgICAgPHByZSBjbGFzcz0iZXhhbXBsZSI+PGNvZGU+Y2hhciBz
cGFjZVtQQVRIX01BWF07CnNucHJpbnRmKHNwYWNlLCBzaXplb2Yoc3BhY2UpLCAic29tZSBzdHJp
bmciKTsKc3RyaW5nX3JlZiBzdHIoc3BhY2UpOzwvY29kZT48L3ByZT4KICAgICAgPHA+SSBkb24n
dCBrbm93IGFueSB3YXkgdG8gZGlzdGluZ3Vpc2ggc3RyaW5nIGxpdGVyYWxzIGZyb20gbG9jYWwg
YXJyYXlzLAogICAgICBzbyB0aGUgb25seSB3YXkgdG8gYmUgc2FmZSBpcyB0byBjYWxsIDxjb2Rl
PnN0cmxlbigpPC9jb2RlPiBvbiBhcnJheQogICAgICBhcmd1bWVudHMuICBTb21lIHBlb3BsZSBo
YXZlIHN1Z2dlc3RlZCBhCiAgICAgIDxjb2RlPnN0cmluZ19yZWY6OmZyb21fbGl0ZXJhbDwvY29k
ZT4gbWV0aG9kLCBidXQgSSBjb25zaWRlciB0aGF0IHRvbwogICAgICB2ZXJib3NlLjwvcD4KICAg
ICAgPHA+RXZlbiB0aGUgb3JpZ2luYWwgd29ycnkgaXMgb2Jzb2xldGUgZ2l2ZW4gbW9kZXJuIG9w
dGltaXplcnM6IGJvdGggZ2NjCiAgICAgIGFuZCBjbGFuZyBvcHRpbWl6ZSA8Y29kZT5zdHJsZW4o
IkxpdGVyYWwiKTwvY29kZT4gaW50byBhIGNvbnN0YW50LCBtYWtpbmcKICAgICAgdGhlIHNhZmUg
Y29kZSBhcyBlZmZpY2llbnQgYXMgdGhlIHRlbXBsYXRlLiAgT3RoZXIgaW1wbGVtZW50YXRpb25z
IHNob3VsZAogICAgICBwcm92aWRlIHRoZSBzYW1lIG9wdGltaXphdGlvbiBhcyBhIFFvSSBpc3N1
ZS48L3A+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24+CiAgICAgIDxoZWFkZXI+PGgzIGlk
PSJ0cmVhdC1hcy1wb2ludGVyIj5EZWZpbmUgY29tcGFyaXNvbiBvbiA8Y29kZT5iZWdpbjwvY29k
ZT4vPGNvZGU+ZW5kPC9jb2RlPiBpbnN0ZWFkIG9mIHRoZSBlbGVtZW50czwvaDM+PC9oZWFkZXI+
CgogICAgICA8cD5PcGVyYXRpb25zIG9uIDxjb2RlPnN0cmluZ19yZWY8L2NvZGU+IGFwcGx5IHRv
IHRoZSBjaGFyYWN0ZXJzIGluIHRoZQogICAgICBzdHJpbmcsIGFuZCBub3QgdGhlIHBvaW50ZXJz
IHRoYXQgcmVmZXIgdG8gdGhlIGNoYXJhY3RlcnMuICBUaGlzCiAgICAgIGludHJvZHVjZXMgdGhl
IHBvc3NpYmlsaXR5IHRoYXQgdGhlIHVuZGVybHlpbmcgY2hhcmFjdGVycyBtaWdodCBjaGFuZ2UK
ICAgICAgd2hpbGUgYSA8Y29kZT5zdHJpbmdfcmVmPC9jb2RlPiByZWZlcnJpbmcgdG8gdGhlbSBp
cyBpbiBhbiBhc3NvY2lhdGl2ZQogICAgICBjb250YWluZXIsIHdoaWNoIHdvdWxkIGJyZWFrIHRo
ZSBjb250YWluZXIsIGJ1dCB3ZSBiZWxpZXZlIHRoaXMgcmlzayBpcwogICAgICB3b3J0aHdoaWxl
IGJlY2F1c2UgaXQgbWF0Y2hlcyBleGlzdGluZyBwcmFjdGljZSBhbmQgbWF0Y2hlcyB1c2VyCiAg
ICAgIGludGVudGlvbnMgbW9yZSBvZnRlbi48L3A+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rp
b24+CiAgICAgIDxoZWFkZXI+PGgzIGlkPSJjb250aWd1b3VzLXJhbmdlIj5XYWl0IGZvciA8Y29k
ZT5jb250aWd1b3VzX3JhbmdlJmx0O2NoYXJUPjwvY29kZT48L2gzPjwvaGVhZGVyPgoKICAgICAg
PHA+PGNvZGU+Y29udGlndW91c19yYW5nZSZsdDtUPjwvY29kZT4gYWxvbmcgd2l0aCBhbgogICAg
ICA8Y29kZT5pc19jb250aWd1b3VzJmx0O0l0ZXJhdG9yT3JSYW5nZT48L2NvZGU+IHRyYWl0IHdv
dWxkIGJlIHVzZWZ1bCBmb3IKICAgICAgbWFueSBwdXJwb3Nlcy4gIEhvd2V2ZXIsIGEgcmVmZXJl
bmNlIGNsYXNzIHRoYXQncyBzcGVjaWZpY2FsbHkgZm9yIHN0cmluZ3MKICAgICAgcHJvdmlkZXMg
YSBjb3VwbGUgZXh0cmEgYmVuZWZpdHM6PC9wPgogICAgICA8dWw+CiAgICAgICAgPGxpPjxjb2Rl
PnN0cmluZ19yZWY8L2NvZGU+IGNhbiBoYXZlIGFuIGltcGxpY2l0IGNvbnZlcnNpb24gZnJvbQog
ICAgICAgIDxjb2RlPmNvbnN0IGNoYXIqPC9jb2RlPiwgd2hpbGUgaXQgd291bGQgYmUgYSBzdXJw
cmlzaW5nIHNwZWNpYWwgY2FzZSB0bwogICAgICAgIHByb3ZpZGUgdGhhdCBvbiA8Y29kZT5jb250
aWd1b3VzX3JhbmdlJmx0O2NvbnN0IGNoYXIqPjwvY29kZT4uPC9saT4KICAgICAgICA8bGk+V2Ug
Y2FuIHByb3ZpZGUgYSBzdWJzZXQgb2YgPGNvZGU+YmFzaWNfc3RyaW5nPC9jb2RlPidzIGludGVy
ZmFjZSB0bwogICAgICAgIGVhc2UgdHJhbnNpdGlvbnMgdG8gYW5kIGZyb20gb3duZXJzaGlwLCB3
aGlsZSBzdWNoIG1ldGhvZHMgd291bGQgYmUgdmVyeQogICAgICAgIHN0cmFuZ2Ugb24gPGNvZGU+
Y29udGlndW91c19yYW5nZTwvY29kZT4uPC9saT4KICAgICAgICA8bGk+PGNvZGU+YmFzaWNfc3Ry
aW5nX3JlZjwvY29kZT4gdGFrZXMgYSA8Y29kZT5jaGFyX3RyYWl0czwvY29kZT4KICAgICAgICBh
cmd1bWVudCBhbGxvd2luZyBjdXN0b21pemF0aW9uIG9mIGNvbXBhcmlzb24uCiAgICAgICAgPGNv
ZGU+Y29udGlndW91c19yYW5nZTwvY29kZT4gbGlrZWx5IHdvdWxkbid0LjwvbGk+CiAgICAgICAg
PGxpPldlIGNvbXBhcmUgYW5kIGhhc2ggPGNvZGU+c3RyaW5nX3JlZjwvY29kZT5zIHVzaW5nIHRo
ZSBlbGVtZW50cyB0aGV5CiAgICAgICAgcmVmZXIgdG8uICBUaGVyZSdzIGEgc3Ryb25nZXIgYXJn
dW1lbnQgdG8gY29tcGFyZSBhCiAgICAgICAgPGNvZGU+Y29udGlndW91c19yYW5nZTwvY29kZT4g
dXNpbmcgdGhlIHBvaW50ZXJzIGluc2lkZSBpdCwgbWVhbmluZyB0d28KICAgICAgICA8Y29kZT5j
b250aWd1b3VzX3JhbmdlJmx0O2NoYXI+PC9jb2RlPnMgb2YgdGhlIHNhbWUgY2hhcmFjdGVycyBt
aWdodAogICAgICAgIGNvbXBhcmUgdW5lcXVhbC48L2xpPgogICAgICAgIDxsaT5UaGUgbm90aW9u
IG9mIGEgInN0cmluZyIgaXMgZGlmZmVyZW50IGZyb20gdGhlIG5vdGlvbiBvZiBhIHJhbmdlIG9m
CiAgICAgICAgY2hhcmFjdGVycywgd2hpY2ggaXMgb25lIHJlYXNvbiB3ZSBoYXZlIDxjb2RlPnN0
ZDo6c3RyaW5nPC9jb2RlPiBpbgogICAgICAgIGFkZGl0aW9uIHRvIDxjb2RlPnN0ZDo6dmVjdG9y
Jmx0O2NoYXI+PC9jb2RlPi4gIFVzZXJzIGJlbmVmaXQgZnJvbQogICAgICAgIHNheWluZyB3aGlj
aCB0aGV5IG1lYW4gaW4gaW50ZXJmYWNlcy48L2xpPgogICAgICA8L3VsPgogICAgPC9zZWN0aW9u
PgoKICAgIDxzZWN0aW9uPgogICAgICA8aGVhZGVyPjxoMyBpZD0ibnVsbC10ZXJtaW5hdGlvbiI+
TWFrZSA8Y29kZT5zdHJpbmdfcmVmPC9jb2RlPiBudWxsLXRlcm1pbmF0ZWQ8L2gzPjwvaGVhZGVy
PgoKICAgICAgPHA+RG9pbmcgdGhpcyBuYWl2ZWx5IG1ha2VzIDxjb2RlPnN1YnN0cjwvY29kZT4g
aW1wb3NzaWJsZSB0byBpbXBsZW1lbnQKICAgICAgd2l0aG91dCBhIGNvcHkuICBXZSBjb3VsZCBp
bWFnaW5lIGludmVudGluZyBhIG1vcmUgY29tcGxleCBpbnRlcmZhY2UgdGhhdAogICAgICByZWNv
cmRzIHdoZXRoZXIgdGhlIGlucHV0IHN0cmluZyB3YXMgbnVsbC10ZXJtaW5hdGVkLCBnaXZpbmcg
dGhlIHVzZXIgdGhlCiAgICAgIG9wdGlvbiB0byB1c2UgdGhhdCBzdHJpbmcgd2hlbiB0cnlpbmcg
dG8gcGFzcyBhIDxjb2RlPnN0cmluZ19yZWY8L2NvZGU+IHRvCiAgICAgIGEgbGVnYWN5IG9yIEMg
ZnVuY3Rpb24gZXhwZWN0aW5nIGEgbnVsbC10ZXJtaW5hdGVkIDxjb2RlPmNvbnN0CiAgICAgIGNo
YXIqPC9jb2RlPi4gIFRoaXMgcHJvcG9zYWwgZG9lc24ndCBpbmNsdWRlIHN1Y2ggYW4gaW50ZXJm
YWNlIGJlY2F1c2UgaXQKICAgICAgd291bGQgbWFrZSA8Y29kZT5zdHJpbmdfcmVmPC9jb2RlPiBi
aWdnZXIgb3IgbW9yZSBleHBlbnNpdmUsIGFuZCBiZWNhdXNlCiAgICAgIHRoZXJlJ3Mgbm8gZXhp
c3RpbmcgcHJhY3RpY2UgdG8gZ3VpZGUgdXMgdG93YXJkIHRoZSByaWdodCBpbnRlcmZhY2UuPC9w
PgogICAgPC9zZWN0aW9uPgogIDwvc2VjdGlvbj4KCiAgPHNlY3Rpb24+CiAgICA8aGVhZGVyPjxo
MiBpZD0icXVlc3Rpb25zIj5PcGVuIFF1ZXN0aW9uczwvaDI+PC9oZWFkZXI+CiAgICA8cD5Ib3cg
ZG9lcyB0aGlzIGludGVyYWN0IHdpdGggPGEKICAgIGhyZWY9Imh0dHA6Ly93d3cub3Blbi1zdGQu
b3JnL2p0YzEvc2MyMi93ZzIxL2RvY3MvcGFwZXJzLzIwMTIvbjM0NTYuaHRtbCI+TjM0NTY8L2E+
PwogICAgU2V2ZXJhbCA8Y29kZT5iYXNpY19zdHJpbmdfcmVmPC9jb2RlPiBvdmVybG9hZHMgd291
bGQgYmUgaGFuZGxlZCBieSB0aGUKICAgIDxjb2RlPlJhbmdlJiY8L2NvZGU+IGFyZ3VtZW50cyB0
aGF0IE4zNDU2IGFkZHMsIGFuZCBzZXZlcmFsIG1vcmUgKGUuZy4gaW4KICAgIDxjb2RlPiZsdDty
ZWdleD48L2NvZGU+KSB3b3VsZCBiZSBoYW5kbGVkIGJ5IGV4dGVuZGluZyB0aG9zZSB0ZW1wbGF0
ZQogICAgYXJndW1lbnRzIHRvIHRoZSByZXN0IG9mIHRoZSBsaWJyYXJ5LiBJbiBub24tZGVkdWNp
bmcgY29udGV4dHMsCiAgICA8Y29kZT5iYXNpY19zdHJpbmdfcmVmPC9jb2RlPiBjYW4gc2VydmUg
YXMgYW4gaW1wbGljaXQgY29udmVyc2lvbiB0YXJnZXQsIHNvIHdlIHdhbnQgaXQKICAgIGFueXdh
eSwgYnV0IGluIGRlZHVjaW5nIGNvbnRleHQsIEkgdGhpbmsgdGhlIDxjb2RlPlJhbmdlJiY8L2Nv
ZGU+IGFyZ3VtZW50IGlzIHN0cmljdGx5CiAgICBiZXR0ZXIuPC9wPgogIDwvc2VjdGlvbj4KCiAg
PGhyLz4KCiAgPHNlY3Rpb24gY2xhc3M9IndvcmRpbmciPgogICAgPGhlYWRlcj48aDIgaWQ9Indv
cmRpbmciPldvcmRpbmc8L2gyPjwvaGVhZGVyPgoKICAgIDxwPldvcmRpbmcgY2hhbmdlcyBhcmUg
YmVpbmcgbWFpbnRhaW5lZCBhdCA8YQogICAgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2dvb2ds
ZS9jeHgtc3RkLWRyYWZ0L2NvbXBhcmUvc3RyaW5nLXJlZiI+aHR0cHM6Ly9naXRodWIuY29tL2dv
b2dsZS9jeHgtc3RkLWRyYWZ0L2NvbXBhcmUvc3RyaW5nLXJlZjwvYT4KICAgIGFuZCBhIHNuYXBz
aG90IG9mIHRoZSBjaGFuZ2VzIGlzIGNvcGllZCBiZWxvdy4gIEEgdmVyeSBlYXJseSBpbXBsZW1l
bnRhdGlvbgogICAgaXMgYXQgPGEKICAgIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9nb29nbGUv
bGliY3h4L2NvbXBhcmUvc3RyaW5nLXJlZiI+aHR0cHM6Ly9naXRodWIuY29tL2dvb2dsZS9saWJj
eHgvY29tcGFyZS9zdHJpbmctcmVmPC9hPi4KICAgIFBhdGNoZXMgYW5kIHB1bGwgcmVxdWVzdHMg
YXJlIHdlbGNvbWUgYWdhaW5zdCBib3RoLjwvcD4KCgogICAgPGgzPk1vZGlmeSB0aGUgbm90ZSBp
biBbZGVmbnMuY29tcG9uZW50XTwvaDM+CiAgICA8cD5Gb3IgZXhhbXBsZSwgdGhlIGNsYXNzIDxk
ZWw+dGVtcGxhdGUgPC9kZWw+PGlucz50ZW1wbGF0ZXMKICAgIDwvaW5zPmJhc2ljX3N0cmluZyA8
aW5zPmFuZCBiYXNpY19zdHJpbmdfcmVmIDwvaW5zPmFuZCB0aGUgbm9uLW1lbWJlcgogICAgZnVu
Y3Rpb24gdGVtcGxhdGVzIHRoYXQgb3BlcmF0ZSBvbiBzdHJpbmdzIGFyZSByZWZlcnJlZCB0byBh
cyB0aGUKICAgIDxkZm4+c3RyaW5nIGNvbXBvbmVudDwvZGZuPi48L3A+CgogICAgPGgzPkFkZCBh
IGNvbnN0cnVjdG9yIHRvIGNsYXNzIGJpdHNldCBpbiBbdGVtcGxhdGUuYml0c2V0XTwvaDM+Cjxw
cmU+PGNvZGU+dGVtcGxhdGUmbHQ7Y2xhc3MgY2hhclQsIGNsYXNzIHRyYWl0cz4KICBleHBsaWNp
dCBiaXRzZXQoCiAgICBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULHRyYWl0cz4gc3RyLAogICAg
Y2hhclQgemVybyA9IGNoYXJUKOKAmTDigJkpLCBjaGFyVCBvbmUgPSBjaGFyVCjigJkx4oCZKSk7
PC9jb2RlPjwvcHJlPgoKICAgIDxoMz5Nb2RpZnkgdGhlIGNvbnN0cnVjdG9yIGRlZmluaXRpb25z
IGluIFtiaXRzZXQuY29uc108L2gzPgoKPHByZT48Y29kZT50ZW1wbGF0ZSAmbHQ7Y2xhc3MgY2hh
clQsIGNsYXNzIHRyYWl0cywgY2xhc3MgQWxsb2NhdG9yPgpleHBsaWNpdApiaXRzZXQoY29uc3Qg
YmFzaWNfc3RyaW5nJmx0O2NoYXJULCB0cmFpdHMsIEFsbG9jYXRvcj4mIHN0ciwKICAgICAgIHR5
cGVuYW1lIGJhc2ljX3N0cmluZyZsdDtjaGFyVCwgdHJhaXRzLCBBbGxvY2F0b3I+OjpzaXplX3R5
cGUgcG9zID0gMCwKICAgICAgIHR5cGVuYW1lIGJhc2ljX3N0cmluZyZsdDtjaGFyVCwgdHJhaXRz
LCBBbGxvY2F0b3I+OjpzaXplX3R5cGUgbiA9CiAgICAgICAgIGJhc2ljX3N0cmluZyZsdDtjaGFy
VCwgdHJhaXRzLCBBbGxvY2F0b3I+OjpucG9zLAogICAgICAgY2hhclQgemVybyA9IGNoYXJUKOKA
mTDigJkpLCBjaGFyVCBvbmUgPSBjaGFyVCjigJkx4oCZKSk7PC9jb2RlPjwvcHJlPgo8ZGl2IGNs
YXNzPSJhdHRyaWJ1dGVzIj4KPHA+PGlucz48aT5FZmZlY3RzOjwvaT4gRXF1aXZhbGVudCB0byA8
Y29kZT5iaXRzZXQoYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPihzdHIpLnN1YnN0
cihwb3MsIG4pLAp6ZXJvLCBvbmUpPC9jb2RlPjwvaW5zPjwvcD4KPC9kaXY+Cgo8cHJlPjxjb2Rl
PjxpbnM+dGVtcGxhdGUgJmx0O2NsYXNzIGNoYXJULCBjbGFzcyB0cmFpdHM+CmV4cGxpY2l0CmJp
dHNldChiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCB0cmFpdHM+IHN0ciwKICAgICAgIGNoYXJU
IHplcm8gPSBjaGFyVCjigJkw4oCZKSwgY2hhclQgb25lID0gY2hhclQo4oCZMeKAmSkpOzwvaW5z
PjwvY29kZT48L3ByZT4KCjxkaXYgY2xhc3M9ImF0dHJpYnV0ZXMiPgo8cD48ZGVsPjxpPlJlcXVp
cmVzOjwvaT4gPGNvZGU+cG9zICZsdDs9IHN0ci5zaXplKCk8L2NvZGU+LjwvZGVsPjwvcD4KCjxw
PjxkZWw+PGk+VGhyb3dzOjwvaT4gPGNvZGU+b3V0X29mX3JhbmdlPC9jb2RlPiBpZiA8Y29kZT5w
b3MgPiBzdHIuc2l6ZSgpPC9jb2RlPi48L2RlbD48L3A+Cgo8cD48ZGVsPjxpPkVmZmVjdHM6PC9p
PiBEZXRlcm1pbmVzIHRoZSBlZmZlY3RpdmUgbGVuZ3RoIDxjb2RlPjx2YXI+cmxlbjwvdmFyPjwv
Y29kZT4gb2YgdGhlIGluaXRpYWxpemluZyBzdHJpbmcgYXMgdGhlIHNtYWxsZXIgb2YgPGNvZGU+
bjwvY29kZT4gYW5kIDxjb2RlPnN0ci5zaXplKCkgLSBwb3M8L2NvZGU+LjwvZGVsPjwvcD4KCjxw
PjxkZWw+VGhlIGZ1bmN0aW9uIHRoZW4gdGhyb3dzIDwvZGVsPjxpbnM+PGk+VGhyb3dzOjwvaT4K
PC9pbnM+PGNvZGU+aW52YWxpZF9hcmd1bWVudDwvY29kZT4gaWYgYW55IG9mIHRoZSA8ZGVsPnJs
ZW4gPC9kZWw+Y2hhcmFjdGVycyBpbgo8Y29kZT5zdHI8L2NvZGU+IDxkZWw+YmVnaW5uaW5nIGF0
IHBvc2l0aW9uIHBvcyA8L2RlbD5pcyBvdGhlciB0aGFuIHplcm8gb3Igb25lLiBUaGUgZnVuY3Rp
b24KdXNlcyA8Y29kZT50cmFpdHM6OmVxKCk8L2NvZGU+IHRvIGNvbXBhcmUgdGhlIGNoYXJhY3Rl
ciB2YWx1ZXMuPC9wPgoKPHA+PGRlbD5PdGhlcndpc2UsIHRoZSA8L2RlbD48aW5zPjxpPkVmZmVj
dHM6PC9pPiA8L2lucz5mdW5jdGlvbgpjb25zdHJ1Y3RzIGFuIG9iamVjdCBvZiBjbGFzcyA8Y29k
ZT5iaXRzZXQmbHQ7Tj48L2NvZGU+LCBpbml0aWFsaXppbmcKdGhlIGZpcnN0IDxjb2RlPk08L2Nv
ZGU+IGJpdCBwb3NpdGlvbnMgdG8gdmFsdWVzIGRldGVybWluZWQgZnJvbSB0aGUKY29ycmVzcG9u
ZGluZyBjaGFyYWN0ZXJzIGluIHRoZSBzdHJpbmcKPGNvZGU+c3RyPC9jb2RlPi4gPGNvZGU+TTwv
Y29kZT4gaXMgdGhlIHNtYWxsZXIgb2YgPGNvZGU+TjwvY29kZT4gYW5kCjxjb2RlPjxkZWw+cmxl
bjwvZGVsPjxpbnM+c3RyLnNpemUoKTwvaW5zPjwvY29kZT4uPC9wPgoKPHA+QW4gZWxlbWVudCBv
ZiB0aGUgY29uc3RydWN0ZWQgc3RyaW5nIGhhcyB2YWx1ZSB6ZXJvIGlmIHRoZSBjb3JyZXNwb25k
aW5nCmNoYXJhY3RlciBpbiA8Y29kZT5zdHI8L2NvZGU+LCA8ZGVsPmJlZ2lubmluZyBhdCBwb3Np
dGlvbiBwb3MsIDwvZGVsPmlzIDxkZWw+MAo8L2RlbD48Y29kZT56ZXJvPC9jb2RlPi4gT3RoZXJ3
aXNlLCB0aGUgZWxlbWVudCBoYXMgdGhlIHZhbHVlIDEuIENoYXJhY3Rlcgpwb3NpdGlvbiA8Y29k
ZT5wb3MgPGRlbD4rIE0gPC9kZWw+LSAxPC9jb2RlPiBjb3JyZXNwb25kcyB0byBiaXQgcG9zaXRp
b24KemVyby4gU3Vic2VxdWVudCBkZWNyZWFzaW5nIGNoYXJhY3RlciBwb3NpdGlvbnMgY29ycmVz
cG9uZCB0byBpbmNyZWFzaW5nIGJpdApwb3NpdGlvbnMuPC9wPgoKPHA+SWYgPGNvZGU+TSAmbHQ7
IE48L2NvZGU+LCByZW1haW5pbmcgYml0IHBvc2l0aW9ucyBhcmUgaW5pdGlhbGl6ZWQgdG8gemVy
by48L3A+CjwvZGl2PgoKPHByZT48Y29kZT50ZW1wbGF0ZSAmbHQ7Y2xhc3MgY2hhclQ+CiAgZXhw
bGljaXQgYml0c2V0KAogICAgY29uc3QgY2hhclQqIHN0ciwKICAgIHR5cGVuYW1lIGJhc2ljX3N0
cmluZyZsdDtjaGFyVD46OnNpemVfdHlwZSBuID0gYmFzaWNfc3RyaW5nJmx0O2NoYXJUPjo6bnBv
cywKICAgIGNoYXJUIHplcm8gPSBjaGFyVCjigJkw4oCZKSwgY2hhclQgb25lID0gY2hhclQo4oCZ
MeKAmSkpOzwvY29kZT48L3ByZT4KCjxkaXYgY2xhc3M9ImF0dHJpYnV0ZXMiPgo8cD48aT5FZmZl
Y3RzOjwvaT4gQ29uc3RydWN0cyBhbiBvYmplY3Qgb2YgY2xhc3MgYml0c2V0Jmx0O04+IGFzIGlm
IGJ5PC9wPgo8cHJlPjxjb2RlPmJpdHNldCgKICBuID09IGJhc2ljX3N0cmluZyZsdDtjaGFyVD46
Om5wb3MKICAgID8gYmFzaWNfc3RyaW5nPGlucz5fcmVmPC9pbnM+Jmx0O2NoYXJUPihzdHIpCiAg
ICA6IGJhc2ljX3N0cmluZzxpbnM+X3JlZjwvaW5zPiZsdDtjaGFyVD4oc3RyLCBuKSwKICA8ZGVs
PjAsIG4sIDwvZGVsPnplcm8sIG9uZSk8L2NvZGU+PC9wcmU+CjwvZGl2PgoKICAgIDxoMz5Nb2Rp
ZnkgW2NoYXIudHJhaXRzLnNwZWNpYWxpemF0aW9ucy5jaGFyXSwgW2NoYXIudHJhaXRzLnNwZWNp
YWxpemF0aW9ucy5jaGFyMTZfdF0sIFtjaGFyLnRyYWl0cy5zcGVjaWFsaXphdGlvbnMuY2hhcjMy
X3RdLCBhbmQgW2NoYXIudHJhaXRzLnNwZWNpYWxpemF0aW9ucy53Y2hhci50XTwvaDM+CgogICAg
PGRpdiBjbGFzcz0iZWRub3RlIj48cD5UaGlzIGltcGxlbWVudHMgdGhlIHByb3Bvc2VkIHJlc29s
dXRpb24gb2YgPGEKICAgIGhyZWY9IiI+TFdHIGlzc3VlICMjIyM8L2E+LiAgSSBjb3VsZCB0YWtl
IGl0IG91dCBhdCB0aGUgY29zdCBvZiBtYWtpbmcKICAgIDxjb2RlPmJhc2ljX3N0cmluZ19yZWYo
Y29uc3QgY2hhclQqKTwvY29kZT4gYW5kIGFsbCBvZiB0aGUgY29tcGFyaXNvbgogICAgb3BlcmF0
b3JzIGFuZCBtZXRob2RzIG5vbi08Y29kZT5jb25zdGV4cHI8L2NvZGU+LjwvcD48L2Rpdj4KCjxw
cmU+PGNvZGU+c3RhdGljIDxpbnM+Y29uc3RleHByIDwvaW5zPmludCBjb21wYXJlKGNvbnN0IGNo
YXJfdHlwZSogczEsIGNvbnN0IGNoYXJfdHlwZSogczIsIHNpemVfdCBuKTsKc3RhdGljIDxpbnM+
Y29uc3RleHByIDwvaW5zPnNpemVfdCBsZW5ndGgoY29uc3QgY2hhcl90eXBlKiBzKTsKc3RhdGlj
IDxpbnM+Y29uc3RleHByIDwvaW5zPmNvbnN0IGNoYXJfdHlwZSogZmluZChjb25zdCBjaGFyX3R5
cGUqIHMsIHNpemVfdCBuLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj
b25zdCBjaGFyX3R5cGUmIGEpOzwvY29kZT48L3ByZT4KCiAgICA8aDMgaWQ9InN0cmluZ3Muc3Ry
aW5nX3JlZi5oZWFkZXIiPk1vZGlmeSBbc3RyaW5nLmNsYXNzZXNdPC9oMz4KCiAgICA8cD5UaGUg
aGVhZGVyICZsdDtzdHJpbmc+IGRlZmluZXMgdGhlIGJhc2ljX3N0cmluZyBjbGFzcyB0ZW1wbGF0
ZSBmb3IgbWFuaXB1bGF0aW5nCiAgICB2YXJ5aW5nLWxlbmd0aCBzZXF1ZW5jZXMgb2YgY2hhci1s
aWtlIG9iamVjdHMgYW5kIGZvdXIgdHlwZWRlZnMsIHN0cmluZywKICAgIHUxNnN0cmluZywgdTMy
c3RyaW5nLCBhbmQgd3N0cmluZywgdGhhdCBuYW1lIHRoZSBzcGVjaWFsaXphdGlvbnMKICAgIGJh
c2ljX3N0cmluZyZsdDtjaGFyPiwgYmFzaWNfc3RyaW5nJmx0O2NoYXIxNl90PiwgYmFzaWNfc3Ry
aW5nJmx0O2NoYXIzMl90PiwgYW5kCiAgICBiYXNpY19zdHJpbmcmbHQ7d2NoYXJfdD4sIHJlc3Bl
Y3RpdmVseS48L3A+CgogICAgPHA+PGlucz4mbHQ7c3RyaW5nPiBhbHNvIGRlZmluZXMgdGhlIDxj
b2RlPmJhc2ljX3N0cmluZ19yZWY8L2NvZGU+IGNsYXNzCiAgICB0ZW1wbGF0ZSBmb3IgcmVmZXJy
aW5nIHRvIGNvbnN0YW50IHNlcXVlbmNlcyBvZiBjaGFyLWxpa2Ugb2JqZWN0cyBhbmQgZm91cgog
ICAgdHlwZWRlZnMsIDxjb2RlPnN0cmluZ19yZWY8L2NvZGU+LCA8Y29kZT51MTZzdHJpbmdfcmVm
PC9jb2RlPiwKICAgIDxjb2RlPnUzMnN0cmluZ19yZWY8L2NvZGU+LCBhbmQgPGNvZGU+d3N0cmlu
Z19yZWY8L2NvZGU+LCB0aGF0IG5hbWUgdGhlCiAgICBzcGVjaWFsaXphdGlvbnMgPGNvZGU+YmFz
aWNfc3RyaW5nX3JlZiZsdDtjaGFyPjwvY29kZT4sCiAgICA8Y29kZT5iYXNpY19zdHJpbmdfcmVm
Jmx0O2NoYXIxNl90PjwvY29kZT4sCiAgICA8Y29kZT5iYXNpY19zdHJpbmdfcmVmJmx0O2NoYXIz
Ml90PjwvY29kZT4sIGFuZAogICAgPGNvZGU+YmFzaWNfc3RyaW5nX3JlZiZsdDt3Y2hhcl90Pjwv
Y29kZT4sIHJlc3BlY3RpdmVseS48L2lucz48L3A+CgogICAgPGgzPkFkZCB0byB0aGUgYXBwcm9w
cmlhdGUgcGxhY2VzIHdpdGhpbiAiSGVhZGVyICZsdDtzdHJpbmc+IHN5bm9wc2lzIjwvaDM+Cgog
ICAgPHByZT48Y29kZT4gIC8vIFtiYXNpYy5zdHJpbmcucmVmXSwgYmFzaWNfc3RyaW5nX3JlZjoK
ICB0ZW1wbGF0ZSZsdDtjbGFzcyBjaGFyVCwgY2xhc3MgdHJhaXRzID0gY2hhcl90cmFpdHMmbHQ7
Y2hhclQ+PgogICAgICBjbGFzcyBiYXNpY19zdHJpbmdfcmVmOwoKICAvLyBbc3RyaW5nLnJlZi5j
b21wYXJpc29uXSwgbm9uLW1lbWJlciBiYXNpY19zdHJpbmdfcmVmIGNvbXBhcmlzb24gZnVuY3Rp
b25zCiAgdGVtcGxhdGUmbHQ7dHlwZW5hbWUgY2hhclQsIHR5cGVuYW1lIHRyYWl0cz4KICBib29s
IG9wZXJhdG9yPT0oYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPiB4LCBiYXNpY19z
dHJpbmdfcmVmJmx0O2NoYXJULCB0cmFpdHM+IHkpOwogIHRlbXBsYXRlJmx0O3R5cGVuYW1lIGNo
YXJULCB0eXBlbmFtZSB0cmFpdHM+CiAgYm9vbCBvcGVyYXRvciE9KGJhc2ljX3N0cmluZ19yZWYm
bHQ7Y2hhclQsIHRyYWl0cz4geCwgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPiB5
KTsKICB0ZW1wbGF0ZSZsdDt0eXBlbmFtZSBjaGFyVCwgdHlwZW5hbWUgdHJhaXRzPgogIGJvb2wg
b3BlcmF0b3ImbHQ7IChiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCB0cmFpdHM+IHgsIGJhc2lj
X3N0cmluZ19yZWYmbHQ7Y2hhclQsIHRyYWl0cz4geSk7CiAgdGVtcGxhdGUmbHQ7dHlwZW5hbWUg
Y2hhclQsIHR5cGVuYW1lIHRyYWl0cz4KICBib29sIG9wZXJhdG9yPiAoYmFzaWNfc3RyaW5nX3Jl
ZiZsdDtjaGFyVCwgdHJhaXRzPiB4LCBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCB0cmFpdHM+
IHkpOwogIHRlbXBsYXRlJmx0O3R5cGVuYW1lIGNoYXJULCB0eXBlbmFtZSB0cmFpdHM+CiAgYm9v
bCBvcGVyYXRvciZsdDs9KGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIHRyYWl0cz4geCwgYmFz
aWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPiB5KTsKICB0ZW1wbGF0ZSZsdDt0eXBlbmFt
ZSBjaGFyVCwgdHlwZW5hbWUgdHJhaXRzPgogIGJvb2wgb3BlcmF0b3I+PShiYXNpY19zdHJpbmdf
cmVmJmx0O2NoYXJULCB0cmFpdHM+IHgsIGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIHRyYWl0
cz4geSk7CiAgLy8gU3VmZmljaWVudCBhZGRpdGlvbmFsIG92ZXJsb2FkcyB0byBhbGxvdyBtaXhl
ZCBjb21wYXJpc29ucyB3aXRoIGFueSB0eXBlCiAgLy8gdGhhdCBoYXMgYW4gaW1wbGljaXQgY29u
dmVyc2lvbiB0byBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCB0cmFpdHM+LgoKICAvLyBbc3Ry
aW5nLnJlZi5ub25tZW1dLCBvdGhlciBub24tbWVtYmVyIGJhc2ljX3N0cmluZ19yZWYgZnVuY3Rp
b25zCiAgdGVtcGxhdGUmbHQ7Y2xhc3MgY2hhclQsIGNsYXNzIHRyYWl0cyA9IGNoYXJfdHJhaXRz
Jmx0O2NoYXJUPiwKICAgICAgICAgICBjbGFzcyBBbGxvY2F0b3IgPSBhbGxvY2F0b3ImbHQ7Y2hh
clQ+ID4KICAgIGJhc2ljX3N0cmluZyZsdDtjaGFyVCwgdHJhaXRzLCBBbGxvY2F0b3I+IHRvX3N0
cmluZygKICAgICAgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPiwKICAgICAgY29u
c3QgQWxsb2NhdG9yJiBhID0gQWxsb2NhdG9yKCkpOwoKICB0ZW1wbGF0ZSZsdDtjbGFzcyBjaGFy
VCwgY2xhc3MgdHJhaXRzPgogICAgYmFzaWNfb3N0cmVhbSZsdDtjaGFyVCwgdHJhaXRzPiYKICAg
ICAgb3BlcmF0b3ImbHQ7Jmx0OyhiYXNpY19vc3RyZWFtJmx0O2NoYXJULCB0cmFpdHM+JiBvcywK
ICAgICAgICAgICAgICAgICBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULHRyYWl0cz4gc3RyKTsK
CiAgLy8gYmFzaWNfc3RyaW5nX3JlZiB0eXBlZGVmIG5hbWVzCiAgdHlwZWRlZiBiYXNpY19zdHJp
bmdfcmVmJmx0O2NoYXI+IHN0cmluZ19yZWY7CiAgdHlwZWRlZiBiYXNpY19zdHJpbmdfcmVmJmx0
O2NoYXIxNl90PiB1MTZzdHJpbmdfcmVmOwogIHR5cGVkZWYgYmFzaWNfc3RyaW5nX3JlZiZsdDtj
aGFyMzJfdD4gdTMyc3RyaW5nX3JlZjsKICB0eXBlZGVmIGJhc2ljX3N0cmluZ19yZWYmbHQ7d2No
YXJfdD4gd3N0cmluZ19yZWY7PC9jb2RlPjwvcHJlPgoKICAgIDxkaXYgY2xhc3M9ImVkbm90ZSI+
CiAgICAgIDxwPkl0IHdvdWxkIGJlIG5pY2UgdG8gcmVtb3ZlIHRoZSA8Y29kZT5zdHJpbmc8L2Nv
ZGU+IG92ZXJsb2FkcyBmb3IgdGhlCiAgICAgIG51bWVyaWMgY29udmVyc2lvbiBmdW5jdGlvbnMs
IGJ1dCB0aGF0IGNvdWxkIGJyZWFrIGNvZGUgdGhhdCByZWxpZXMgb24gYW4KICAgICAgaW1wbGlj
aXQgY29udmVyc2lvbiB0byBzdHJpbmcuICBJbnN0ZWFkLCB3ZSBuZWVkIHRvIGFkZCA8Y29kZT5j
b25zdAogICAgICBjaGFyKjwvY29kZT4gb3ZlcmxvYWRzIHRvIGF2b2lkIGFtYmlndWl0eS48L3A+
CgogICAgICA8cD5JJ2QgYWxzbyBsaWtlIHRvIGFkZCA8Y29kZT5vcHRpb25hbCZsdDtUPgogICAg
ICBzdG88dmFyPng8L3Zhcj5fY29uc3VtZShzdHJpbmdfcmVmJiwgaW50IGJhc2U9MTApPC9jb2Rl
PiBpZi93aGVuCiAgICAgIDxjb2RlPm9wdGlvbmFsPC9jb2RlPiBiZWNvbWVzIGF2YWlsYWJsZS48
L3A+CiAgICA8L2Rpdj4KCjxwcmU+PGNvZGU+ICBpbnQgc3RvaShzdHJpbmdfcmVmIHN0ciwgc2l6
ZV90KiBpZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsKICBpbnQgc3RvaShjb25zdCBjaGFyKiBzdHIs
IHNpemVfdCogaWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7CiAgbG9uZyBzdG9sKHN0cmluZ19yZWYg
c3RyLCBzaXplX3QqIGlkeCA9IDAsIGludCBiYXNlID0gMTApOwogIGxvbmcgc3RvbChjb25zdCBj
aGFyKiBzdHIsIHNpemVfdCogaWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7CiAgdW5zaWduZWQgbG9u
ZyBzdG91bChzdHJpbmdfcmVmIHN0ciwgc2l6ZV90KiBpZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsK
ICB1bnNpZ25lZCBsb25nIHN0b3VsKGNvbnN0IGNoYXIqIHN0ciwgc2l6ZV90KiBpZHggPSAwLCBp
bnQgYmFzZSA9IDEwKTsKICBsb25nIGxvbmcgc3RvbGwoc3RyaW5nX3JlZiBzdHIsIHNpemVfdCog
aWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7CiAgbG9uZyBsb25nIHN0b2xsKGNvbnN0IGNoYXIqIHN0
ciwgc2l6ZV90KiBpZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsKICB1bnNpZ25lZCBsb25nIGxvbmcg
c3RvdWxsKHN0cmluZ19yZWYgc3RyLCBzaXplX3QqIGlkeCA9IDAsIGludCBiYXNlID0gMTApOwog
IHVuc2lnbmVkIGxvbmcgbG9uZyBzdG91bGwoY29uc3QgY2hhciogc3RyLCBzaXplX3QqIGlkeCA9
IDAsIGludCBiYXNlID0gMTApOwogIGZsb2F0IHN0b2Yoc3RyaW5nX3JlZiBzdHIsIHNpemVfdCog
aWR4ID0gMCk7CiAgZmxvYXQgc3RvZihjb25zdCBjaGFyKiBzdHIsIHNpemVfdCogaWR4ID0gMCk7
CiAgZG91YmxlIHN0b2Qoc3RyaW5nX3JlZiBzdHIsIHNpemVfdCogaWR4ID0gMCk7CiAgZG91Ymxl
IHN0b2QoY29uc3QgY2hhciogc3RyLCBzaXplX3QqIGlkeCA9IDApOwogIGxvbmcgZG91YmxlIHN0
b2xkKHN0cmluZ19yZWYgc3RyLCBzaXplX3QqIGlkeCA9IDApOwogIGxvbmcgZG91YmxlIHN0b2xk
KGNvbnN0IGNoYXIqIHN0ciwgc2l6ZV90KiBpZHggPSAwKTsKCiAgaW50IHN0b2kod3N0cmluZ19y
ZWYgc3RyLCBzaXplX3QqIGlkeCA9IDAsIGludCBiYXNlID0gMTApOwogIGludCBzdG9pKGNvbnN0
IHdjaGFyX3QqIHN0ciwgc2l6ZV90KiBpZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsKICBsb25nIHN0
b2wod3N0cmluZ19yZWYgc3RyLCBzaXplX3QqIGlkeCA9IDAsIGludCBiYXNlID0gMTApOwogIGxv
bmcgc3RvbChjb25zdCB3Y2hhcl90KiBzdHIsIHNpemVfdCogaWR4ID0gMCwgaW50IGJhc2UgPSAx
MCk7CiAgdW5zaWduZWQgbG9uZyBzdG91bCh3c3RyaW5nX3JlZiBzdHIsIHNpemVfdCogaWR4ID0g
MCwgaW50IGJhc2UgPSAxMCk7CiAgdW5zaWduZWQgbG9uZyBzdG91bChjb25zdCB3Y2hhcl90KiBz
dHIsIHNpemVfdCogaWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7CiAgbG9uZyBsb25nIHN0b2xsKHdz
dHJpbmdfcmVmIHN0ciwgc2l6ZV90KiBpZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsKICBsb25nIGxv
bmcgc3RvbGwoY29uc3Qgd2NoYXJfdCogc3RyLCBzaXplX3QqIGlkeCA9IDAsIGludCBiYXNlID0g
MTApOwogIHVuc2lnbmVkIGxvbmcgbG9uZyBzdG91bGwod3N0cmluZ19yZWYgc3RyLCBzaXplX3Qq
IGlkeCA9IDAsIGludCBiYXNlID0gMTApOwogIHVuc2lnbmVkIGxvbmcgbG9uZyBzdG91bGwoY29u
c3Qgd2NoYXJfdCogc3RyLCBzaXplX3QqIGlkeCA9IDAsIGludCBiYXNlID0gMTApOwogIGZsb2F0
IHN0b2Yod3N0cmluZ19yZWYgc3RyLCBzaXplX3QqIGlkeCA9IDApOwogIGZsb2F0IHN0b2YoY29u
c3Qgd2NoYXJfdCogc3RyLCBzaXplX3QqIGlkeCA9IDApOwogIGRvdWJsZSBzdG9kKHdzdHJpbmdf
cmVmIHN0ciwgc2l6ZV90KiBpZHggPSAwKTsKICBkb3VibGUgc3RvZChjb25zdCB3Y2hhcl90KiBz
dHIsIHNpemVfdCogaWR4ID0gMCk7CiAgbG9uZyBkb3VibGUgc3RvbGQod3N0cmluZ19yZWYgc3Ry
LCBzaXplX3QqIGlkeCA9IDApOwogIGxvbmcgZG91YmxlIHN0b2xkKGNvbnN0IHdjaGFyX3QqIHN0
ciwgc2l6ZV90KiBpZHggPSAwKTsKCiAgdGVtcGxhdGUgJmx0Oz4gc3RydWN0IGhhc2gmbHQ7c3Ry
aW5nX3JlZj47CiAgdGVtcGxhdGUgJmx0Oz4gc3RydWN0IGhhc2gmbHQ7dTE2c3RyaW5nX3JlZj47
CiAgdGVtcGxhdGUgJmx0Oz4gc3RydWN0IGhhc2gmbHQ7dTMyc3RyaW5nX3JlZj47CiAgdGVtcGxh
dGUgJmx0Oz4gc3RydWN0IGhhc2gmbHQ7d3N0cmluZ19yZWY+OzwvY29kZT48L3ByZT4KCiAgICA8
aDMgaWQ9ImJhc2ljLnN0cmluZy5yZWYiPkFkZCBhIHN1YmNsYXVzZSAieC55IENsYXNzIHRlbXBs
YXRlCiAgICBiYXNpY19zdHJpbmdfcmVmIFtiYXNpYy5zdHJpbmcucmVmXSI8L2gzPgoKICAgIDxw
PlRoZSBjbGFzcyB0ZW1wbGF0ZSBiYXNpY19zdHJpbmdfcmVmIGRlc2NyaWJlcyBvYmplY3RzIHRo
YXQgY2FuIHJlZmVyIHRvIGEKICAgIGNvbnN0YW50IHNlcXVlbmNlIG9mIGFyYml0cmFyeSBjaGFy
LWxpa2Ugb2JqZWN0cyB3aXRoIHRoZSBmaXJzdCBlbGVtZW50IG9mCiAgICB0aGUgc2VxdWVuY2Ug
YXQgcG9zaXRpb24gemVyby4gSW4gdGhlIHJlc3Qgb2YgdGhpcyBDbGF1c2UsIHRoZSB0eXBlIG9m
IHRoZQogICAgY2hhci1saWtlIG9iamVjdHMgaGVsZCBpbiBhIGJhc2ljX3N0cmluZ19yZWYgb2Jq
ZWN0IGlzIGRlc2lnbmF0ZWQgYnkKICAgIGNoYXJULjwvcD4KCiAgICA8cD5bTm90ZTogVGhlIGxp
YnJhcnkgcHJvdmlkZXMgaW1wbGljaXQgY29udmVyc2lvbnMgZnJvbSBjb25zdCBjaGFyVCogYW5k
CiAgICBzdGQ6OmJhc2ljX3N0cmluZyZsdDtjaGFyVCwgLi4uPiB0byBzdGQ6OmJhc2ljX3N0cmlu
Z19yZWYmbHQ7Y2hhclQsIC4uLj4gc28KICAgIHRoYXQgdXNlciBjb2RlIGNhbiBhY2NlcHQganVz
dCBzdGQ6OmJhc2ljX3N0cmluZ18tIHJlZiZsdDtjaGFyVD4gYXMgYQogICAgcGFyYW1ldGVyIHdo
ZXJldmVyIGEgc2VxdWVuY2Ugb2YgY2hhcmFjdGVycyBpcyBleHBlY3RlZC4gVXNlci1kZWZpbmVk
IHR5cGVzCiAgICBzaG91bGQgZGVmaW5lIHRoZWlyIG93biBpbXBsaWNpdCBjb252ZXJzaW9ucyB0
byBzdGQ6OmJhc2ljX3N0cmluZ19yZWYgaW4KICAgIG9yZGVyIHRvIGludGVyb3BlcmF0ZSB3aXRo
IHRoZXNlIGZ1bmN0aW9ucy4g4oCUIGVuZCBub3RlIF08L3A+CgogICAgPHA+VGhlIGNvbXBsZXhp
dHkgb2YgbWVtYmVyIGZ1bmN0aW9ucyBpcyBPKDEpIHVubGVzcyBvdGhlcndpc2UKICAgIHNwZWNp
ZmllZC48L3A+CgoKICAgICA8cHJlPjxjb2RlPm5hbWVzcGFjZSBzdGQgewogIHRlbXBsYXRlJmx0
O3R5cGVuYW1lIGNoYXJULCB0eXBlbmFtZSB0cmFpdHMgPSBjaGFyX3RyYWl0cyZsdDtjaGFyVD4+
CiAgY2xhc3MgYmFzaWNfc3RyaW5nX3JlZiB7CiAgICBwdWJsaWM6CiAgICAvLyB0eXBlcwogICAg
dHlwZWRlZiBjaGFyVCB2YWx1ZV90eXBlOwogICAgdHlwZWRlZiBjb25zdCBjaGFyVCogcG9pbnRl
cjsKICAgIHR5cGVkZWYgY29uc3QgY2hhclQqIGNvbnN0X3BvaW50ZXI7CiAgICB0eXBlZGVmIGNv
bnN0IGNoYXJUJiByZWZlcmVuY2U7CiAgICB0eXBlZGVmIGNvbnN0IGNoYXJUJiBjb25zdF9yZWZl
cmVuY2U7CiAgICB0eXBlZGVmIDx2YXI+aW1wbGVtZW50YXRpb24tZGVmaW5lZDwvdmFyPiBjb25z
dF9pdGVyYXRvcjsgLy8gU2VlIFtzdHJpbmcucmVmLml0ZXJhdG9yc10KICAgIHR5cGVkZWYgY29u
c3RfaXRlcmF0b3IgaXRlcmF0b3I7ICAvLyBbRm9vdG5vdGU6IEJlY2F1c2UgYmFzaWNfc3RyaW5n
X3JlZiByZWZlcnMgdG8gYSBjb25zdGFudCBzZXF1ZW5jZSwgaXRlcmF0b3IgYW5kIGNvbnN0X2l0
ZXJhdG9yIGFyZSB0aGUgc2FtZSB0eXBlLiAtLWVuZCBmb290bm90ZV0KICAgIHR5cGVkZWYgc3Rk
OjpyZXZlcnNlX2l0ZXJhdG9yJmx0O2NvbnN0X2l0ZXJhdG9yPiBjb25zdF9yZXZlcnNlX2l0ZXJh
dG9yOyB0eXBlZGVmIGNvbnN0X3JldmVyc2VfaXRlcmF0b3IgcmV2ZXJzZV9pdGVyYXRvcjsKICAg
IHR5cGVkZWYgc2l6ZV90IHNpemVfdHlwZTsKICAgIHR5cGVkZWYgcHRyZGlmZl90IGRpZmZlcmVu
Y2VfdHlwZTsKICAgIHN0YXRpYyBjb25zdGV4cHIgc2l6ZV90eXBlIG5wb3MgPSBzaXplX3R5cGUo
LTEpOwoKICAgIC8vIFtzdHJpbmcucmVmLmNvbnNdLCBjb25zdHJ1Y3QvY29weQogICAgY29uc3Rl
eHByIGJhc2ljX3N0cmluZ19yZWYoKSBub2V4Y2VwdDsKICAgIGNvbnN0ZXhwciBiYXNpY19zdHJp
bmdfcmVmKGNvbnN0IGJhc2ljX3N0cmluZ19yZWYmKSBub2V4Y2VwdCA9IGRlZmF1bHQ7CiAgICBi
YXNpY19zdHJpbmdfcmVmJiBvcGVyYXRvcj0oY29uc3QgYmFzaWNfc3RyaW5nX3JlZiYpIG5vZXhj
ZXB0ID0gZGVmYXVsdDsKICAgIGNvbnN0ZXhwciBiYXNpY19zdHJpbmdfcmVmKGNvbnN0IGNoYXJU
KiBzdHIpOwogICAgY29uc3RleHByIGJhc2ljX3N0cmluZ19yZWYoY29uc3QgY2hhclQqIHN0ciwg
c2l6ZV90eXBlIGxlbik7PC9jb2RlPjwvcHJlPgogICAgPGRpdiBjbGFzcz0iZWRub3RlIj48cD5O
byBpbml0aWFsaXplcl9saXN0IGNvbnN0cnVjdG9yIGJlY2F1c2UgW2RjbC5pbml0Lmxpc3RdcDYg
c2F5cyBpdCB3b3VsZCBsaWtlbHkgc3RvcmUgYSBkYW5nbGluZyByZWZlcmVuY2UgaW50byB0aGUg
c3RyaW5nX3JlZi48L3A+PC9kaXY+Cgo8cHJlPjxjb2RlPiAgICAvLyBbc3RyaW5nLnJlZi5pdGVy
YXRvcnNdLCBpdGVyYXRvcnMKICAgIGNvbnN0ZXhwciBjb25zdF9pdGVyYXRvciBiZWdpbigpIGNv
bnN0IG5vZXhjZXB0OwogICAgY29uc3RleHByIGNvbnN0X2l0ZXJhdG9yIGVuZCgpIGNvbnN0IG5v
ZXhjZXB0OwogICAgY29uc3RleHByIGNvbnN0X2l0ZXJhdG9yIGNiZWdpbigpIGNvbnN0IG5vZXhj
ZXB0OwogICAgY29uc3RleHByIGNvbnN0X2l0ZXJhdG9yIGNlbmQoKSBjb25zdCBub2V4Y2VwdDs8
L2NvZGU+PC9wcmU+CiAgICA8ZGl2IGNsYXNzPSJlZG5vdGUiPjxwPnJldmVyc2VfaXRlcmF0b3Ig
bWV0aG9kcyBhcmVu4oCZdCBjb25zdGV4cHIgYmVjYXVzZSByZXZlcnNlX2l0ZXJhdG9yIGlzbuKA
mXQgYSBsaXRlcmFsIHR5cGUuIFNlZSA8YSBocmVmPSJodHRwOi8vd3d3Lm9wZW4tc3RkLm9yZy9q
dGMxL3NjMjIvd2cyMS9kb2NzL3BhcGVycy8yMDEyL24zNDczLmh0bWwjMjIwOCI+TFdHIElzc3Vl
IDIyMDg8L2E+LjwvcD48L2Rpdj4KPHByZT48Y29kZT4gICAgY29uc3RfcmV2ZXJzZV9pdGVyYXRv
ciByYmVnaW4oKSBjb25zdCBub2V4Y2VwdDsKICAgIGNvbnN0X3JldmVyc2VfaXRlcmF0b3IgcmVu
ZCgpIGNvbnN0IG5vZXhjZXB0OwogICAgY29uc3RfcmV2ZXJzZV9pdGVyYXRvciBjcmJlZ2luKCkg
Y29uc3Qgbm9leGNlcHQ7CiAgICBjb25zdF9yZXZlcnNlX2l0ZXJhdG9yIGNyZW5kKCkgY29uc3Qg
bm9leGNlcHQ7CgogICAgLy8gW3N0cmluZy5yZWYuY2FwYWNpdHldLCBjYXBhY2l0eQogICAgY29u
c3RleHByIHNpemVfdHlwZSBzaXplKCkgY29uc3Qgbm9leGNlcHQ7CiAgICBjb25zdGV4cHIgc2l6
ZV90eXBlIGxlbmd0aCgpIGNvbnN0IG5vZXhjZXB0OwogICAgY29uc3RleHByIHNpemVfdHlwZSBt
YXhfc2l6ZSgpIGNvbnN0IG5vZXhjZXB0OwogICAgY29uc3RleHByIGJvb2wgZW1wdHkoKSBjb25z
dCBub2V4Y2VwdDsKCiAgICAvLyBbc3RyaW5nLnJlZi5hY2Nlc3NdLCBlbGVtZW50IGFjY2Vzcwog
ICAgY29uc3RleHByIGNvbnN0IGNoYXJUJiBvcGVyYXRvcltdKHNpemVfdHlwZSBwb3MpIGNvbnN0
OwogICAgY29uc3QgY2hhclQmIGF0KHNpemVfdCBwb3MpIGNvbnN0OwogICAgY29uc3RleHByIGNv
bnN0IGNoYXJUJiBmcm9udCgpIGNvbnN0OwogICAgY29uc3RleHByIGNvbnN0IGNoYXJUJiBiYWNr
KCkgY29uc3Q7CiAgICBjb25zdGV4cHIgY29uc3QgY2hhclQqIGRhdGEoKSBjb25zdCBub2V4Y2Vw
dDsKCiAgICAvLyBbc3RyaW5nLnJlZi5tb2RpZmllcnNdLCBtb2RpZmllcnM6CiAgICB2b2lkIGNs
ZWFyKCkgbm9leGNlcHQ7CiAgICB2b2lkIHJlbW92ZV9wcmVmaXgoc2l6ZV90eXBlIG4pOwogICAg
dm9pZCByZW1vdmVfc3VmZml4KHNpemVfdHlwZSBuKTsKCiAgICAvLyBbc3RyaW5nLnJlZi5vcHNd
LCBzdHJpbmcgb3BlcmF0aW9uczoKICAgIGNvbnN0ZXhwciBiYXNpY19zdHJpbmdfcmVmIHN1YnN0
cihzaXplX3R5cGUgcG9zLCBzaXplX3R5cGUgbj1ucG9zKSBjb25zdDsKICAgIGNvbnN0ZXhwciBp
bnQgY29tcGFyZShiYXNpY19zdHJpbmdfcmVmIHMpIGNvbnN0IG5vZXhjZXB0OwogICAgY29uc3Rl
eHByIGludCBjb21wYXJlKGNvbnN0IGNoYXJUKiBzKSBjb25zdCBub2V4Y2VwdDsKICAgIGNvbnN0
ZXhwciBib29sIHN0YXJ0c193aXRoKGJhc2ljX3N0cmluZ19yZWYgcykgY29uc3Qgbm9leGNlcHQ7
CiAgICBjb25zdGV4cHIgYm9vbCBzdGFydHNfd2l0aChjaGFyVCBjKSBjb25zdCBub2V4Y2VwdDsK
ICAgIGNvbnN0ZXhwciBib29sIHN0YXJ0c193aXRoKGNvbnN0IGNoYXJUKiBzKSBjb25zdCBub2V4
Y2VwdDsKICAgIGNvbnN0ZXhwciBib29sIGVuZHNfd2l0aChiYXNpY19zdHJpbmdfcmVmIHMpIGNv
bnN0IG5vZXhjZXB0OwogICAgY29uc3RleHByIGJvb2wgZW5kc193aXRoKGNoYXJUIGMpIGNvbnN0
IG5vZXhjZXB0OwogICAgY29uc3RleHByIGJvb2wgZW5kc193aXRoKGNvbnN0IGNoYXJUKiBzKSBj
b25zdCBub2V4Y2VwdDsKICAgIHNpemVfdHlwZSBmaW5kKGJhc2ljX3N0cmluZ19yZWYgcykgY29u
c3Qgbm9leGNlcHQ7CiAgICBzaXplX3R5cGUgZmluZChjaGFyVCBjKSBjb25zdCBub2V4Y2VwdDsK
ICAgIHNpemVfdHlwZSBmaW5kKGNvbnN0IGNoYXJUKiBzKSBjb25zdCBub2V4Y2VwdDsKICAgIHNp
emVfdHlwZSByZmluZChiYXNpY19zdHJpbmdfcmVmIHMpIGNvbnN0IG5vZXhjZXB0OwogICAgc2l6
ZV90eXBlIHJmaW5kKGNoYXJUIGMpIGNvbnN0IG5vZXhjZXB0OwogICAgc2l6ZV90eXBlIHJmaW5k
KGNvbnN0IGNoYXJUKiBzKSBjb25zdCBub2V4Y2VwdDsKICAgIHNpemVfdHlwZSBmaW5kX2ZpcnN0
X29mKGJhc2ljX3N0cmluZ19yZWYgcykgY29uc3Qgbm9leGNlcHQ7CiAgICBzaXplX3R5cGUgZmlu
ZF9maXJzdF9vZihjaGFyVCBjKSBjb25zdCBub2V4Y2VwdDsKICAgIHNpemVfdHlwZSBmaW5kX2Zp
cnN0X29mKGNvbnN0IGNoYXJUKiBzKSBjb25zdCBub2V4Y2VwdDsKICAgIHNpemVfdHlwZSBmaW5k
X2xhc3Rfb2YoYmFzaWNfc3RyaW5nX3JlZiBzKSBjb25zdCBub2V4Y2VwdDsKICAgIHNpemVfdHlw
ZSBmaW5kX2xhc3Rfb2YoY2hhclQgYykgY29uc3Qgbm9leGNlcHQ7CiAgICBzaXplX3R5cGUgZmlu
ZF9sYXN0X29mKGNvbnN0IGNoYXJUKiBzKSBjb25zdCBub2V4Y2VwdDsKICAgIHNpemVfdHlwZSBm
aW5kX2ZpcnN0X25vdF9vZihiYXNpY19zdHJpbmdfcmVmIHMpIGNvbnN0IG5vZXhjZXB0OwogICAg
c2l6ZV90eXBlIGZpbmRfZmlyc3Rfbm90X29mKGNoYXJUIGMpIGNvbnN0IG5vZXhjZXB0OwogICAg
c2l6ZV90eXBlIGZpbmRfZmlyc3Rfbm90X29mKGNvbnN0IGNoYXJUKiBzKSBjb25zdCBub2V4Y2Vw
dDsKICAgIHNpemVfdHlwZSBmaW5kX2xhc3Rfbm90X29mKGJhc2ljX3N0cmluZ19yZWYgcykgY29u
c3Qgbm9leGNlcHQ7CiAgICBzaXplX3R5cGUgZmluZF9sYXN0X25vdF9vZihjaGFyVCBjKSBjb25z
dCBub2V4Y2VwdDsKICAgIHNpemVfdHlwZSBmaW5kX2xhc3Rfbm90X29mKGNvbnN0IGNoYXJUKiBz
KSBjb25zdCBub2V4Y2VwdDsKfTs8L2NvZGU+PC9wcmU+CgogICAgPHA+RWFjaCBtZW1iZXIgZnVu
Y3Rpb24gb2YgdGhlIGZvcm08L3A+CiAgICA8cHJlPjxjb2RlPnJ0IGZ4MShjb25zdCBjaGFyVCog
cyk7IC8vIHN1Y2ggYXMgY29tcGFyZSgpLCBmaW5kKCk8L2NvZGU+PC9wcmU+CiAgICA8cD5pcyBl
cXVpdmFsZW50IHRvIDxjb2RlPmZ4MShiYXNpY19zdHJpbmdfcmVmKHMpKTwvY29kZT4uPC9wPgoK
ICAgIDxwPkVhY2ggbWVtYmVyIGZ1bmN0aW9uIG9mIHRoZSBmb3JtPC9wPgogICAgPHByZT48Y29k
ZT5ydCBmeDIoY2hhclQgYyk7IC8vIHN1Y2ggYXMgc3RhcnRzX3dpdGgoKSwgZmluZCgpPC9jb2Rl
PjwvcHJlPgogICAgPHA+aXMgZXF1aXZhbGVudCB0byA8Y29kZT5meDIoYmFzaWNfc3RyaW5nX3Jl
ZigmYywgMSkpPC9jb2RlPi48L3A+CgogICAgPGg0PkFkZCBhIHN1Yi1zdWJjbGF1c2UgIngueS4x
IGJhc2ljX3N0cmluZ19yZWYgY29uc3RydWN0b3JzIGFuZCBhc3NpZ25tZW50IG9wZXJhdG9ycyAg
W3N0cmluZy5yZWYuY29uc10iPC9oND4KCiAgICA8cHJlPjxjb2RlPmNvbnN0ZXhwciBiYXNpY19z
dHJpbmdfcmVmKCk7PC9jb2RlPjwvcHJlPgogICAgPGRpdiBjbGFzcz0iYXR0cmlidXRlcyI+CiAg
ICAgIDxwPjxpPkVmZmVjdHM8L2k+OiBDb25zdHJ1Y3RzIGFuIGVtcHR5IGJhc2ljX3N0cmluZ19y
ZWYuPC9wPgogICAgICA8cD48aT5Qb3N0Y29uZGl0aW9uPC9pPjogZW1wdHkoKSA9PSB0cnVlIGFu
ZCBbZGF0YSgpLGRhdGEoKSkgaXMgYSB2YWxpZCByYW5nZS48L3A+CiAgICA8L2Rpdj4KCiAgICA8
cHJlPjxjb2RlPmJhc2ljX3N0cmluZ19yZWYoY29uc3QgY2hhclQqIHN0cik7PC9jb2RlPjwvcHJl
PgogICAgPGRpdiBjbGFzcz0iYXR0cmlidXRlcyI+CiAgICAgIDxwPjxpPlJlcXVpcmVzPC9pPjog
W3N0cixzdHIgKyB0cmFpdHM6Omxlbmd0aChzdHIpKSBpcyBhIHZhbGlkIHJhbmdlLjwvcD4KICAg
ICAgPHA+PGk+RWZmZWN0czwvaT46IENvbnN0cnVjdHMgYSBiYXNpY19zdHJpbmdfcmVmIHJlZmVy
cmluZyB0byB0aGUgc2FtZSBzdHJpbmcgYXMgc3RyLCB3aXRoIHRoZSBwb3N0Y29uZGl0aW9ucwog
ICAgICBpbiBUYWJsZSBbdGFiOnN0cmluZy5yZWYuY3RyLjFdPC9wPgoKICAgICAgPHRhYmxlPjxj
YXB0aW9uPlRhYmxlIFt0YWI6c3RyaW5nLnJlZi5jdHIuMV0g4oCUIGJhc2ljX3N0cmluZ19yZWYo
Y29uc3QgY2hhclQqKSBlZmZlY3RzPC9jYXB0aW9uPgogICAgICA8dHI+PHRoPkVsZW1lbnQ8L3Ro
Pjx0aD5WYWx1ZTwvdGg+PC90cj4KICAgICAgPHRyPjx0ZD5kYXRhKCk8L3RkPjx0ZD5zdHI8L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQ+c2l6ZSgpPC90ZD48dGQ+dHJhaXRzOjpsZW5ndGgoc3RyKTwv
dGQ+PC90cj4KICAgICAgPC90YWJsZT4KCiAgICAgIDxwPjxpPkNvbXBsZXhpdHk8L2k+OiBPKHNp
emUoKSk8L3A+CiAgICA8L2Rpdj4KCiAgICA8cHJlPjxjb2RlPmNvbnN0ZXhwciBiYXNpY19zdHJp
bmdfcmVmKGNvbnN0IGNoYXJUKiBzdHIsIHNpemVfdHlwZSBsZW4pOzwvY29kZT48L3ByZT4KICAg
IDxkaXYgY2xhc3M9ImF0dHJpYnV0ZXMiPgogICAgICA8cD48aT5SZXF1aXJlczwvaT46IHN0ciBp
cyBub3QgYSBudWxsIHBvaW50ZXIgYW5kIFtzdHIsc3RyICsgbGVuKSBpcyBhIHZhbGlkIHJhbmdl
LjwvcD4KICAgICAgPHA+PGk+RWZmZWN0czwvaT46IENvbnN0cnVjdHMgYSBiYXNpY19zdHJpbmdf
cmVmLCB3aXRoIHRoZSBwb3N0Y29uZGl0aW9ucyBpbiBUYWJsZSBbdGFiOnN0cmluZy5yZWYuY3Ry
LjJdPC9wPgogICAgICA8dGFibGU+PGNhcHRpb24+VGFibGUgW3RhYjpzdHJpbmcucmVmLmN0ci4y
XSDigJQgYmFzaWNfc3RyaW5nX3JlZihjb25zdCBjaGFyVCosIHNpemVfdHlwZSkgZWZmZWN0czwv
Y2FwdGlvbj4KICAgICAgPHRyPjx0aD5FbGVtZW50PC90aD48dGg+VmFsdWU8L3RoPjwvdHI+CiAg
ICAgIDx0cj48dGQ+ZGF0YSgpPC90ZD48dGQ+c3RyPC90ZD48L3RyPgogICAgICA8dHI+PHRkPnNp
emUoKTwvdGQ+PHRkPmxlbjwvdGQ+PC90cj4KICAgICAgPC90YWJsZT4KICAgIDwvZGl2PgoKCiAg
ICA8aDQ+QWRkIGEgc3ViLXN1YmNsYXVzZSAieC55LjIgYmFzaWNfc3RyaW5nX3JlZiBpdGVyYXRv
ciBzdXBwb3J0IFtzdHJpbmcucmVmLml0ZXJhdG9yc10iPC9oND4KCiAgICA8cHJlPjxjb2RlPnR5
cGVkZWYgaW1wbGVtZW50YXRpb24tZGVmaW5lZCBjb25zdF9pdGVyYXRvcjs8L2NvZGU+PC9wcmU+
CiAgICA8ZGl2IGNsYXNzPSJhdHRyaWJ1dGVzIj4KICAgICAgPHA+QSByYW5kb20tYWNjZXNzLCBj
b250aWd1b3VzIGl0ZXJhdG9yIHR5cGUuPC9wPgogICAgICA8cD5Gb3IgYSBiYXNpY19zdHJpbmdf
cmVmIHN0ciwgYW55IG9wZXJhdGlvbiB0aGF0IGludmFsaWRhdGVzIGEgcG9pbnRlciBpbgogICAg
ICB0aGUgcmFuZ2UgW3N0ci5kYXRhKCksIHN0ci5kYXRhKCkrc3RyLnNpemUoKSkgaW52YWxpZGF0
ZXMgcG9pbnRlcnMgYW5kCiAgICAgIGl0ZXJhdG9ycyByZXR1cm5lZCBmcm9tIHN0cuKAmXMgbWV0
aG9kcy48L3A+CiAgICA8L2Rpdj4KCgogICAgPHByZT48Y29kZT5jb25zdGV4cHIgY29uc3RfaXRl
cmF0b3IgYmVnaW4oKSBjb25zdCBub2V4Y2VwdDsKY29uc3RleHByIGNvbnN0X2l0ZXJhdG9yIGNi
ZWdpbigpIGNvbnN0IG5vZXhjZXB0OzwvY29kZT48L3ByZT4KICAgIDxwIGNsYXNzPSJhdHRyaWJ1
dGUiPjxpPlJldHVybnM8L2k+OiBBbiBpdGVyYXRvciByZWZlcnJpbmcgdG8gdGhlIGZpcnN0IGNo
YXJhY3RlciBpbiB0aGUgc3RyaW5nLjwvcD4KCiAgICA8cHJlPjxjb2RlPmNvbnN0ZXhwciBjb25z
dF9pdGVyYXRvciBlbmQoKSBjb25zdCBub2V4Y2VwdDsKY29uc3RleHByIGNvbnN0X2l0ZXJhdG9y
IGNlbmQoKSBjb25zdCBub2V4Y2VwdDs8L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0iYXR0cmli
dXRlIj48aT5SZXR1cm5zPC9pPjogQW4gaXRlcmF0b3Igd2hpY2ggaXMgdGhlIHBhc3QtdGhlLWVu
ZCB2YWx1ZS48L3A+CgogICAgPHByZT48Y29kZT5jb25zdF9yZXZlcnNlX2l0ZXJhdG9yIHJiZWdp
bigpIGNvbnN0IG5vZXhjZXB0Owpjb25zdF9yZXZlcnNlX2l0ZXJhdG9yIGNyYmVnaW4oKSBjb25z
dCBub2V4Y2VwdDs8L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0iYXR0cmlidXRlIj48aT5SZXR1
cm5zPC9pPjogQW4gaXRlcmF0b3Igd2hpY2ggaXMgc2VtYW50aWNhbGx5IGVxdWl2YWxlbnQgdG8g
cmV2ZXJzZV9pdGVyYXRvcihlbmQoKSkuPC9wPgoKICAgIDxwcmU+PGNvZGU+Y29uc3RfcmV2ZXJz
ZV9pdGVyYXRvciByZW5kKCkgY29uc3Qgbm9leGNlcHQ7CmNvbnN0X3JldmVyc2VfaXRlcmF0b3Ig
Y3JlbmQoKSBjb25zdCBub2V4Y2VwdDs8L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0iYXR0cmli
dXRlIj48aT5SZXR1cm5zPC9pPjogQW4gaXRlcmF0b3Igd2hpY2ggaXMgc2VtYW50aWNhbGx5IGVx
dWl2YWxlbnQgdG8gcmV2ZXJzZV9pdGVyYXRvcihiZWdpbigpKS48L3A+CgogICAgPGg0PkFkZCBh
IHN1Yi1zdWJjbGF1c2UgIngueS4zIGJhc2ljX3N0cmluZ19yZWYgY2FwYWNpdHkgW3N0cmluZy5y
ZWYuY2FwYWNpdHldIjwvaDQ+CgogICAgPHByZT48Y29kZT5zaXplX3R5cGUgc2l6ZSgpIGNvbnN0
IG5vZXhjZXB0OzwvY29kZT48L3ByZT4KICAgIDxkaXYgY2xhc3M9ImF0dHJpYnV0ZXMiPgogICAg
ICA8cD48aT5SZXR1cm5zPC9pPjogQSBjb3VudCBvZiB0aGUgbnVtYmVyIG9mIGNoYXItbGlrZSBv
YmplY3RzIHJlZmVycmVkIHRvIGJ5IHRoZSBzdHJpbmdfcmVmLjwvcD4KICAgICAgPHA+PGk+Q29t
cGxleGl0eTwvaT46IGNvbnN0YW50IHRpbWUuPC9wPgogICAgPC9kaXY+CgogICAgPHByZT48Y29k
ZT5zaXplX3R5cGUgbGVuZ3RoKCkgY29uc3Qgbm9leGNlcHQ7PC9jb2RlPjwvcHJlPgogICAgPHAg
Y2xhc3M9ImF0dHJpYnV0ZSI+PGk+UmV0dXJuczwvaT46IHNpemUoKS48L3A+CgogICAgPHByZT48
Y29kZT5zaXplX3R5cGUgbWF4X3NpemUoKSBjb25zdCBub2V4Y2VwdDs8L2NvZGU+PC9wcmU+CiAg
ICA8cCBjbGFzcz0iYXR0cmlidXRlIj48aT5SZXR1cm5zPC9pPjogVGhlIHNpemUgb2YgdGhlIGxh
cmdlc3QgcG9zc2libGUgc3RyaW5nX3JlZi48L3A+CgogICAgPHByZT48Y29kZT5ib29sIGVtcHR5
KCkgY29uc3Qgbm9leGNlcHQ7PC9jb2RlPjwvcHJlPgogICAgPHAgY2xhc3M9ImF0dHJpYnV0ZSI+
PGk+UmV0dXJuczwvaT46IHNpemUoKSA9PSAwLjwvcD4KCgogICAgPGg0PkFkZCBhIHN1Yi1zdWJj
bGF1c2UgIngueS40IGJhc2ljX3N0cmluZ19yZWYgZWxlbWVudCBhY2Nlc3MgW3N0cmluZy5yZWYu
YWNjZXNzXSI8L2g0PgoKICAgIDxwcmU+PGNvZGU+Y29uc3RleHByIGNvbnN0X3JlZmVyZW5jZSBv
cGVyYXRvcltdKHNpemVfdHlwZSBwb3MpIGNvbnN0OzwvY29kZT48L3ByZT4KICAgIDxkaXYgY2xh
c3M9ImF0dHJpYnV0ZXMiPgogICAgICA8cD48aT5SZXF1aXJlczwvaT46IHBvcyAmbHQ7IHNpemUo
KS48L3A+CiAgICAgIDxwPjxpPlJldHVybnM8L2k+OiAqKGJlZ2luKCkgKyBwb3MpPC9wPgogICAg
ICA8cD48aT5UaHJvd3M8L2k+OiBOb3RoaW5nLjwvcD4KICAgICAgPHA+WyBOb3RlOiBVbmxpa2Ug
YmFzaWNfc3RyaW5nOjpvcGVyYXRvcltdLAogICAgICBiYXNpY19zdHJpbmdfcmVmOjpvcGVyYXRv
cltdKHNpemUoKSkgaGFzIHVuZGVmaW5lZCBiZWhhdmlvciBpbnN0ZWFkIG9mCiAgICAgIHJldHVy
bmluZyBjaGFyVCgpLiDigJQgZW5kIG5vdGUgXTwvcD4KICAgIDwvZGl2PgoKICAgIDxwcmU+PGNv
ZGU+Y29uc3RleHByIGNvbnN0X3JlZmVyZW5jZSBhdChzaXplX3R5cGUgcG9zKSBjb25zdDs8L2Nv
ZGU+PC9wcmU+CiAgICA8ZGl2IGNsYXNzPSJhdHRyaWJ1dGVzIj4KICAgICAgPHA+PGk+VGhyb3dz
PC9pPjogb3V0X29mX3JhbmdlIGlmIHBvcyA+PSBzaXplKCkuPC9wPgogICAgICA8cD48aT5SZXR1
cm5zPC9pPjogb3BlcmF0b3JbXShwb3MpLjwvcD4KICAgIDwvZGl2PgoKICAgIDxwcmU+PGNvZGU+
Y29uc3RleHByIGNvbnN0IGNoYXJUJiBmcm9udCgpIGNvbnN0OzwvY29kZT48L3ByZT4KICAgIDxk
aXYgY2xhc3M9ImF0dHJpYnV0ZXMiPgogICAgICA8cD48aT5SZXF1aXJlczwvaT46ICFlbXB0eSgp
PC9wPgogICAgICA8cD48aT5FZmZlY3RzPC9pPjogRXF1aXZhbGVudCB0byBvcGVyYXRvcltdKDAp
LjwvcD4KICAgIDwvZGl2PgoKICAgIDxwcmU+PGNvZGU+Y29uc3RleHByIGNvbnN0IGNoYXJUJiBi
YWNrKCkgY29uc3Q7PC9jb2RlPjwvcHJlPgogICAgPGRpdiBjbGFzcz0iYXR0cmlidXRlcyI+CiAg
ICAgIDxwPjxpPlJlcXVpcmVzPC9pPjogIWVtcHR5KCk8L3A+CiAgICAgIDxwPjxpPkVmZmVjdHM8
L2k+OiBFcXVpdmFsZW50IHRvIG9wZXJhdG9yW10oc2l6ZSgpIC0gMSkuPC9wPgogICAgPC9kaXY+
CgogICAgPHByZT48Y29kZT5jb25zdCBjaGFyVCogZGF0YSgpIGNvbnN0IG5vZXhjZXB0OzwvY29k
ZT48L3ByZT4KICAgIDxkaXYgY2xhc3M9ImF0dHJpYnV0ZXMiPgogICAgICA8cD48aT5SZXR1cm5z
PC9pPjogQSBub24tbnVsbCBwb2ludGVyIHAgc3VjaCB0aGF0IHAgKyBpID09ICZvcGVyYXRvcltd
KGkpIGZvciBlYWNoIGkgaW4gWzAsc2l6ZSgpKS48L3A+CiAgICAgIDxwPlsgTm90ZTogVW5saWtl
IHN0ZDo6c3RyaW5nOjpkYXRhKCkgYW5kIHN0cmluZyBsaXRlcmFscywgZGF0YSgpIG1heQogICAg
ICByZXR1cm4gYSBwb2ludGVyIHRvIGEgYnVmZmVyIHRoYXQgaXMgbm90IG51bGwtdGVybWluYXRl
ZC4gVGhlcmVmb3JlIGl0IGlzCiAgICAgIHR5cGljYWxseSBhIG1pc3Rha2UgdG8gcGFzcyBkYXRh
KCkgdG8gYSByb3V0aW5lIHRoYXQgdGFrZXMganVzdCBhIGNvbnN0CiAgICAgIGNoYXJUKiBhbmQg
ZXhwZWN0cyBhIG51bGwtdGVybWluYXRlZCBzdHJpbmcuIOKAlCBlbmQgbm90ZSBdPC9wPgogICAg
PC9kaXY+CgogICAgPGg0IGlkPSJzdHJpbmcucmVmLm1vZGlmaWVycyI+QWRkIGEgc3ViLXN1YmNs
YXVzZSAieC55LjUgYmFzaWNfc3RyaW5nX3JlZiBtb2RpZmllcnMgW3N0cmluZy5yZWYubW9kaWZp
ZXJzXSI8L2g0PgoKICAgIDxwcmU+PGNvZGU+dm9pZCBjbGVhcigpIG5vZXhjZXB0OzwvY29kZT48
L3ByZT4KICAgIDxwIGNsYXNzPSJhdHRyaWJ1dGUiPjxpPkVmZmVjdHM8L2k+OiBTYW1lIGFzICp0
aGlzID0gYmFzaWNfc3RyaW5nX3JlZigpPC9wPgoKICAgIDxwcmU+PGNvZGU+dm9pZCByZW1vdmVf
cHJlZml4KHNpemVfdHlwZSBuKSBub2V4Y2VwdDs8L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0i
YXR0cmlidXRlIj48aT5FZmZlY3RzPC9pPjogU2FtZSBhcyAqdGhpcyA9IHN1YnN0cihuLCBucG9z
KTwvcD4KICAgIDxwcmU+PGNvZGU+dm9pZCByZW1vdmVfc3VmZml4KHNpemVfdHlwZSBuKSBub2V4
Y2VwdDs8L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0iYXR0cmlidXRlIj48aT5FZmZlY3RzPC9p
PjogU2FtZSBhcyAqdGhpcyA9IHN1YnN0cigwLCBzaXplKCkgLSBuKTwvcD4KCgogICAgPGg0IGlk
PSJzdHJpbmcucmVmLm9wcyI+QWRkIGEgc3ViLXN1YmNsYXVzZSAieC55LjYgYmFzaWNfc3RyaW5n
X3JlZiBzdHJpbmcgb3BlcmF0aW9ucyBbc3RyaW5nLnJlZi5vcHNdIjwvaDQ+CgogICAgPHA+WyBO
b3RlOiBVbmxpa2Ugc3RkOjpiYXNpY19zdHJpbmcsIHN0ZDo6YmFzaWNfc3RyaW5nX3JlZiBwcm92
aWRlcyBubwogICAgd2hvbGUtc3RyaW5nIG1ldGhvZHMgd2l0aCBwb3NpLSB0aW9uIG9yIGxlbmd0
aCBwYXJhbWV0ZXJzLiBJbnN0ZWFkLCB1c2VycwogICAgc2hvdWxkIHVzZSB0aGUgc3Vic3RyKCkg
bWV0aG9kIHRvIGNyZWF0ZSB0aGUgY2hhcmFjdGVyIHNlcXVlbmNlIHRoZXnigJlyZQogICAgYWN0
dWFsbHkgaW50ZXJlc3RlZCBpbiwgYW5kIHVzZSB0aGF0LiDigJQgZW5kIG5vdGUgXTwvcD4KCiAg
ICA8cHJlPjxjb2RlPmJhc2ljX3N0cmluZ19yZWYgc3Vic3RyKHNpemVfdHlwZSBwb3MsIHNpemVf
dHlwZSBuID0gbnBvcykgY29uc3Q7PC9jb2RlPjwvcHJlPgogICAgPGRpdiBjbGFzcz0iYXR0cmli
dXRlcyI+CiAgICAgIDxwPjxpPlRocm93czwvaT46IG91dF9vZl9yYW5nZSBpZiBwb3MgPiBzaXpl
KCkuPC9wPgogICAgICA8cD48aT5FZmZlY3RzPC9pPjogRGV0ZXJtaW5lcyB0aGUgZWZmZWN0aXZl
IGxlbmd0aCBybGVuIG9mIHRoZSBzdHJpbmcgdG8gcmVmZXJlbmNlIGFzIHRoZSBzbWFsbGVyIG9m
IG4gYW5kIHNpemUoKSAtIHBvcy48L3A+CiAgICAgIDxwPjxpPlJldHVybnM8L2k+OiBiYXNpY19z
dHJpbmdfcmVmKGRhdGEoKStwb3MsIHJsZW4pLjwvcD4KICAgIDwvZGl2PgoKICAgIDxwcmU+PGNv
ZGU+aW50IGNvbXBhcmUoY29uc3QgYmFzaWNfc3RyaW5nX3JlZiYgc3RyKSBjb25zdCBub2V4Y2Vw
dDs8L2NvZGU+PC9wcmU+CiAgICA8ZGl2IGNsYXNzPSJhdHRyaWJ1dGVzIj4KICAgICAgPHA+PGk+
RWZmZWN0czwvaT46IERldGVybWluZXMgdGhlIGVmZmVjdGl2ZSBsZW5ndGggcmxlbiBvZiB0aGUg
c3RyaW5ncyB0byBjb21wYXJlIGFzIHRoZSBzbWFsbGVzdCBvZiBzaXplKCkgYW5kIHN0ci5zaXpl
KCkuIFRoZSBmdW5jdGlvbiB0aGVuIGNvbXBhcmVzIHRoZSB0d28gc3RyaW5ncyBieSBjYWxsaW5n
IHRyYWl0czo6Y29tcGFyZShkYXRhKCksIHN0ci5kYXRhKCksIHJsZW4pLjwvcD4KICAgICAgPHA+
PGk+Q29tcGxleGl0eTwvaT46IE8ocmxlbik8L3A+CiAgICAgIDxwPjxpPlJldHVybnM8L2k+OiBU
aGUgbm9uemVybyByZXN1bHQgaWYgdGhlIHJlc3VsdCBvZiB0aGUgY29tcGFyaXNvbiBpcyBub256
ZXJvLiBPdGhlcndpc2UsIHJldHVybnMgYSB2YWx1ZSBhcwogICAgICBpbmRpY2F0ZWQgaW4gVGFi
bGUgW3RhYjpzdHJpbmcucmVmLmNvbXBhcmVdLjwvcD4KICAgICAgPHRhYmxlPjxjYXB0aW9uPlRh
YmxlIFt0YWI6c3RyaW5nLnJlZi5jb21wYXJlXSDigJQgY29tcGFyZSgpIHJlc3VsdHM8L2NhcHRp
b24+CiAgICAgIDx0cj48dGg+Q29uZGl0aW9uPC90aD48dGg+UmV0dXJuIFZhbHVlPC90aD48L3Ry
PgogICAgICA8dHI+PHRkPnNpemUoKSAmbHQ7IHN0ci5zaXplKCk8L3RkPjx0ZD4mbHQ7IDA8L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQ+c2l6ZSgpID09IHN0ci5zaXplKCk8L3RkPjx0ZD4wPC90ZD48
L3RyPgogICAgICA8dHI+PHRkPnNpemUoKSA+ICBzdHIuc2l6ZSgpPC90ZD48dGQ+PiAwPC90ZD48
L3RyPgogICAgICA8L3RhYmxlPgogICAgPC9kaXY+CgogICAgPHByZT48Y29kZT5ib29sIHN0YXJ0
c193aXRoKGNvbnN0IGJhc2ljX3N0cmluZ19yZWYmIHByZWZpeCkgY29uc3Qgbm9leGNlcHQ7PC9j
b2RlPjwvcHJlPgogICAgPGRpdiBjbGFzcz0iYXR0cmlidXRlcyI+CiAgICAgIDxwPjxpPkNvbXBs
ZXhpdHk8L2k+OiBPKG1pbihzaXplKCksIHByZWZpeC5zaXplKCkpKTwvcD4KICAgICAgPHA+PGk+
UmV0dXJuczwvaT46IDxjb2RlPnNpemUoKSA+PSBwcmVmaXguc2l6ZSgpICYmPHdici8+IHN1YnN0
cigwLCBwcmVmaXguc2l6ZSgpKSA9PSBwcmVmaXg8L2NvZGU+PC9wPgogICAgPC9kaXY+CgogICAg
PHByZT48Y29kZT5ib29sIGVuZHNfd2l0aChjb25zdCBiYXNpY19zdHJpbmdfcmVmJiBzdWZmaXgp
IGNvbnN0IG5vZXhjZXB0OzwvY29kZT48L3ByZT4KICAgIDxkaXYgY2xhc3M9ImF0dHJpYnV0ZXMi
PgogICAgICA8cD48aT5Db21wbGV4aXR5PC9pPjogTyhtaW4oc2l6ZSgpLCBzdWZmaXguc2l6ZSgp
KSk8L3A+CiAgICAgIDxwPjxpPlJldHVybnM8L2k+OiA8Y29kZT5zaXplKCkgPj0gc3VmZml4LnNp
emUoKSAmJjx3YnIvPiBzdWJzdHIoc2l6ZSgpIC0gc3VmZml4LnNpemUoKSwgbnBvcykgPT0gc3Vm
Zml4PC9jb2RlPjwvcD4KICAgIDwvZGl2PgoKICAgIDxoNT5BZGQgYSBzdWI8c3VwPjM8L3N1cD5j
bGF1c2UgIngueS42LjEgU2VhcmNoaW5nIGJhc2ljX3N0cmluZ19yZWYgW3N0cmluZy5yZWYuZmlu
ZF0iPC9oNT4KCiAgICA8cD5NZW1iZXIgZnVuY3Rpb25zIGluIHRoaXMgc2VjdGlvbiBoYXZlIGNv
bXBsZXhpdHkgTyhzaXplKCkgKgogICAgYXJndW1lbnQuc2l6ZSgpKSBhdCB3b3JzdCwgYWx0aG91
Z2ggaW1wbGVtZW50YXRpb25zIGFyZSBlbmNvdXJhZ2VkIHRvIGRvCiAgICBiZXR0ZXIuPC9wPgoK
ICAgIDxwcmU+PGNvZGU+c2l6ZV90eXBlIGZpbmQoY29uc3QgYmFzaWNfc3RyaW5nX3JlZiYgc3Ry
KSBjb25zdCBub2V4Y2VwdDs8L2NvZGU+PC9wcmU+CiAgICA8ZGl2IGNsYXNzPSJhdHRyaWJ1dGVz
Ij4KICAgICAgPHA+PGk+RWZmZWN0czwvaT46IERldGVybWluZXMgdGhlIGxvd2VzdCBwb3NpdGlv
biB4cG9zLCBpZiBwb3NzaWJsZSwgc3VjaCB0aGF0IGJvdGggb2YgdGhlIGZvbGxvd2luZyBjb25k
aXRpb25zIG9idGFpbjo8L3A+CiAgICAgIDx1bD48bGk+eHBvcyArIHN0ci5zaXplKCkgPD0gc2l6
ZSgpOzwvbGk+CiAgICAgIDxsaT50cmFpdHM6OmVxKGF0KHhwb3MrSSksIHN0ci5hdChJKSkgZm9y
IGFsbCBlbGVtZW50cyBJIG9mIHRoZSBzdHJpbmcgcmVmZXJlbmNlZCBieSBzdHIuPC9saT4KICAg
ICAgPC91bD4KICAgICAgPHA+PGk+UmV0dXJuczwvaT46IHhwb3MgaWYgdGhlIGZ1bmN0aW9uIGNh
biBkZXRlcm1pbmUgc3VjaCBhIHZhbHVlIGZvciB4cG9zLiBPdGhlcndpc2UsIHJldHVybnMgbnBv
cy48L3A+CiAgICAgIDxwPjxpPlJlbWFya3M8L2k+OiBVc2VzIHRyYWl0czo6ZXEoKS48L3A+CiAg
ICA8L2Rpdj4KCiAgICA8cHJlPjxjb2RlPnNpemVfdHlwZSByZmluZChjb25zdCBiYXNpY19zdHJp
bmdfcmVmJiBzdHIpIGNvbnN0IG5vZXhjZXB0OzwvY29kZT48L3ByZT4KICAgIDxkaXYgY2xhc3M9
ImF0dHJpYnV0ZXMiPgogICAgICA8cD48aT5FZmZlY3RzPC9pPjogRGV0ZXJtaW5lcyB0aGUgaGln
aGVzdCBwb3NpdGlvbiB4cG9zLCBpZiBwb3NzaWJsZSwgc3VjaCB0aGF0IGJvdGggb2YgdGhlIGZv
bGxvd2luZyBjb25kaXRpb25zIG9idGFpbjo8L3A+CiAgICAgIDx1bD48bGk+eHBvcyArIHN0ci5z
aXplKCkgPD0gc2l6ZSgpOzwvbGk+CiAgICAgIDxsaT50cmFpdHM6OmVxKGF0KHhwb3MrSSksIHN0
ci5hdChJKSkgZm9yIGFsbCBlbGVtZW50cyBJIG9mIHRoZSBzdHJpbmcgcmVmZXJlbmNlZCBieSBz
dHIuPC9saT48L3VsPgogICAgICA8cD48aT5SZXR1cm5zPC9pPjogeHBvcyBpZiB0aGUgZnVuY3Rp
b24gY2FuIGRldGVybWluZSBzdWNoIGEgdmFsdWUgZm9yIHhwb3MuIE90aGVyd2lzZSwgcmV0dXJu
cyBucG9zLjwvcD4KICAgICAgPHA+PGk+UmVtYXJrczwvaT46IFVzZXMgdHJhaXRzOjplcSgpLjwv
cD4KICAgIDwvZGl2PgoKICAgIDxwcmU+PGNvZGU+c2l6ZV90eXBlIGZpbmRfZmlyc3Rfb2YoY29u
c3QgYmFzaWNfc3RyaW5nX3JlZiYgc3RyKSBjb25zdCBub2V4Y2VwdDs8L2NvZGU+PC9wcmU+CiAg
ICA8ZGl2IGNsYXNzPSJhdHRyaWJ1dGVzIj4KICAgICAgPHA+PGk+RWZmZWN0czwvaT46IERldGVy
bWluZXMgdGhlIGxvd2VzdCBwb3NpdGlvbiB4cG9zLCBpZiBwb3NzaWJsZSwgc3VjaCB0aGF0IGJv
dGggb2YgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zIG9idGFpbjo8L3A+CiAgICAgIDx1bD48bGk+
eHBvcyAmbHQ7IHNpemUoKTs8L2xpPgogICAgICA8bGk+dHJhaXRzOjplcShhdCh4cG9zKSwgc3Ry
LmF0KEkpKSBmb3Igc29tZSBlbGVtZW50IEkgb2YgdGhlIHN0cmluZyByZWZlcmVuY2VkIGJ5IHN0
ci48L2xpPjwvdWw+CiAgICAgIDxwPjxpPlJldHVybnM8L2k+OiB4cG9zIGlmIHRoZSBmdW5jdGlv
biBjYW4gZGV0ZXJtaW5lIHN1Y2ggYSB2YWx1ZSBmb3IgeHBvcy4gT3RoZXJ3aXNlLCByZXR1cm5z
IG5wb3MuPC9wPgogICAgICA8cD48aT5SZW1hcmtzPC9pPjogVXNlcyB0cmFpdHM6OmVxKCkuPC9w
PgogICAgPC9kaXY+CgogICAgPHByZT48Y29kZT5zaXplX3R5cGUgZmluZF9sYXN0X29mKGNvbnN0
IGJhc2ljX3N0cmluZ19yZWYmIHN0cikgY29uc3Qgbm9leGNlcHQ7PC9jb2RlPjwvcHJlPgogICAg
PGRpdiBjbGFzcz0iYXR0cmlidXRlcyI+CiAgICAgIDxwPjxpPkVmZmVjdHM8L2k+OiBEZXRlcm1p
bmVzIHRoZSBoaWdoZXN0IHBvc2l0aW9uIHhwb3MsIGlmIHBvc3NpYmxlLCBzdWNoIHRoYXQgYm90
aCBvZiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgb2J0YWluOjwvcD4KICAgICAgPHVsPjxsaT54
cG9zICZsdDsgc2l6ZSgpOzwvbGk+CiAgICAgIDxsaT50cmFpdHM6OmVxKGF0KHhwb3MpLCBzdHIu
YXQoSSkpIGZvciBzb21lIGVsZW1lbnQgSSBvZiB0aGUgc3RyaW5nIHJlZmVyZW5jZWQgYnkgc3Ry
LjwvbGk+PC91bD4KICAgICAgPHA+PGk+UmV0dXJuczwvaT46IHhwb3MgaWYgdGhlIGZ1bmN0aW9u
IGNhbiBkZXRlcm1pbmUgc3VjaCBhIHZhbHVlIGZvciB4cG9zLiBPdGhlcndpc2UsIHJldHVybnMg
bnBvcy48L3A+CiAgICAgIDxwPjxpPlJlbWFya3M8L2k+OiBVc2VzIHRyYWl0czo6ZXEoKS48L3A+
CiAgICA8L2Rpdj4KCiAgICA8cHJlPjxjb2RlPnNpemVfdHlwZSBmaW5kX2ZpcnN0X25vdF9vZihj
b25zdCBiYXNpY19zdHJpbmdfcmVmJiBzdHIpIGNvbnN0IG5vZXhjZXB0OzwvY29kZT48L3ByZT4K
ICAgIDxkaXYgY2xhc3M9ImF0dHJpYnV0ZXMiPgogICAgICA8cD48aT5FZmZlY3RzPC9pPjogRGV0
ZXJtaW5lcyB0aGUgbG93ZXN0IHBvc2l0aW9uIHhwb3MsIGlmIHBvc3NpYmxlLCBzdWNoIHRoYXQg
Ym90aCBvZiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgb2J0YWluOjwvcD4KICAgICAgPHVsPjxs
aT54cG9zICZsdDsgc2l6ZSgpOzwvbGk+CiAgICAgIDxsaT50cmFpdHM6OmVxKGF0KHhwb3MpLCBz
dHIuYXQoSSkpIGZvciBubyBlbGVtZW50IEkgb2YgdGhlIHN0cmluZyByZWZlcmVuY2VkIGJ5IHN0
ci48L2xpPjwvdWw+CiAgICAgIDxwPjxpPlJldHVybnM8L2k+OiB4cG9zIGlmIHRoZSBmdW5jdGlv
biBjYW4gZGV0ZXJtaW5lIHN1Y2ggYSB2YWx1ZSBmb3IgeHBvcy4gT3RoZXJ3aXNlLCByZXR1cm5z
IG5wb3MuPC9wPgogICAgICA8cD48aT5SZW1hcmtzPC9pPjogVXNlcyB0cmFpdHM6OmVxKCkuPC9w
PgogICAgPC9kaXY+CgogICAgPHByZT48Y29kZT5zaXplX3R5cGUgZmluZF9sYXN0X25vdF9vZihj
b25zdCBiYXNpY19zdHJpbmdfcmVmJiBzdHIpIGNvbnN0IG5vZXhjZXB0OzwvY29kZT48L3ByZT4K
ICAgIDxkaXYgY2xhc3M9ImF0dHJpYnV0ZXMiPgogICAgICA8cD48aT5FZmZlY3RzPC9pPjogRGV0
ZXJtaW5lcyB0aGUgaGlnaGVzdCBwb3NpdGlvbiB4cG9zLCBpZiBwb3NzaWJsZSwgc3VjaCB0aGF0
IGJvdGggb2YgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zIG9idGFpbjo8L3A+CiAgICAgIDx1bD48
bGk+eHBvcyAmbHQ7IHNpemUoKTs8L2xpPgogICAgICA8bGk+dHJhaXRzOjplcShhdCh4cG9zKSwg
c3RyLmF0KEkpKSBmb3Igbm8gZWxlbWVudCBJIG9mIHRoZSBzdHJpbmcgcmVmZXJlbmNlZCBieSBz
dHIuPC9saT48L3VsPgogICAgICA8cD48aT5SZXR1cm5zPC9pPjogeHBvcyBpZiB0aGUgZnVuY3Rp
b24gY2FuIGRldGVybWluZSBzdWNoIGEgdmFsdWUgZm9yIHhwb3MuIE90aGVyd2lzZSwgcmV0dXJu
cyBucG9zLjwvcD4KICAgICAgPHA+PGk+UmVtYXJrczwvaT46IFVzZXMgdHJhaXRzOjplcSgpLjwv
cD4KICAgIDwvZGl2PgoKCiAgICA8aDQ+QWRkIGEgc3ViLXN1YmNsYXVzZSAieC55LjcgYmFzaWNf
c3RyaW5nX3JlZiBub24tbWVtYmVyIGNvbXBhcmlzb24gZnVuY3Rpb25zIFtzdHJpbmcucmVmLmNv
bXBhcmlzb25dIjwvaDQ+CgogICAgPHA+SW1wbGVtZW50YXRpb25zIHNoYWxsIHByb3ZpZGUgc3Vm
ZmljaWVudCBhZGRpdGlvbmFsIG92ZXJsb2FkcyBzbyB0aGF0IGFuCiAgICBvYmplY3QgPGNvZGU+
PHZhcj50PC92YXI+PC9jb2RlPiB3aXRoIGFuIGltcGxpY2l0IGNvbnZlcnNpb24gdG8KICAgIDxj
b2RlPmJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIHRyYWl0cz48L2NvZGU+IGNhbiBiZSBjb21w
YXJlZCBhY2NvcmRpbmcgdG8KICAgIFRhYmxlIFt0YWI6c3RyaW5nLnJlZi5jb21wYXJpc29uLm92
ZXJsb2Fkc10sIHdoZXJlCiAgICA8Y29kZT48dmFyPnNwPC92YXI+PC9jb2RlPiBpcyBhbiBpbnN0
YW5jZSBvZgogICAgPGNvZGU+YmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPjwvY29k
ZT4uPC9wPgoKICAgIDx0YWJsZT48Y2FwdGlvbj5UYWJsZSBbdGFiOnN0cmluZy5yZWYuY29tcGFy
aXNvbi5vdmVybG9hZHNdIOKAlDx3YnIvPiBBZGRpdGlvbmFsIGJhc2ljX3N0cmluZ19yZWYgY29t
cGFyaXNvbiBvdmVybG9hZHM8L2NhcHRpb24+CiAgICA8dHI+PHRoPkV4cHJlc3Npb248L3RoPjx0
aD5FcXVpdmFsZW50IHRvPC90aD48L3RyPgogICAgPHRyPjx0ZD50ID09IHNwPC90ZD48dGQ+YmFz
aWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPih0KSA9PSBzcDwvdGQ+PC90cj4KICAgIDx0
cj48dGQ+c3AgPT0gdDwvdGQ+PHRkPnNwID09IGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIHRy
YWl0cz4odCk8L3RkPjwvdHI+CiAgICA8dHI+PHRkPnQgIT0gc3A8L3RkPjx0ZD5iYXNpY19zdHJp
bmdfcmVmJmx0O2NoYXJULCB0cmFpdHM+KHQpICE9IHNwPC90ZD48L3RyPgogICAgPHRyPjx0ZD5z
cCAhPSB0PC90ZD48dGQ+c3AgIT0gYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPih0
KTwvdGQ+PC90cj4KICAgIDx0cj48dGQ+dCAmbHQ7IHNwPC90ZD48dGQ+YmFzaWNfc3RyaW5nX3Jl
ZiZsdDtjaGFyVCwgdHJhaXRzPih0KSAmbHQ7IHNwPC90ZD48L3RyPgogICAgPHRyPjx0ZD5zcCAm
bHQ7IHQ8L3RkPjx0ZD5zcCAmbHQ7IGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIHRyYWl0cz4o
dCk8L3RkPjwvdHI+CiAgICA8dHI+PHRkPnQgPiBzcDwvdGQ+PHRkPmJhc2ljX3N0cmluZ19yZWYm
bHQ7Y2hhclQsIHRyYWl0cz4odCkgPiBzcDwvdGQ+PC90cj4KICAgIDx0cj48dGQ+c3AgPiB0PC90
ZD48dGQ+c3AgPiBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCB0cmFpdHM+KHQpPC90ZD48L3Ry
PgogICAgPHRyPjx0ZD50ICZsdDs9IHNwPC90ZD48dGQ+YmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFy
VCwgdHJhaXRzPih0KSAmbHQ7PSBzcDwvdGQ+PC90cj4KICAgIDx0cj48dGQ+c3AgJmx0Oz0gdDwv
dGQ+PHRkPnNwICZsdDs9IGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIHRyYWl0cz4odCk8L3Rk
PjwvdHI+CiAgICA8dHI+PHRkPnQgPj0gc3A8L3RkPjx0ZD5iYXNpY19zdHJpbmdfcmVmJmx0O2No
YXJULCB0cmFpdHM+KHQpID49IHNwPC90ZD48L3RyPgogICAgPHRyPjx0ZD5zcCA+PSB0PC90ZD48
dGQ+c3AgPj0gYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPih0KTwvdGQ+PC90cj4K
ICAgIDwvdGFibGU+CgogICAgPHA+WyBFeGFtcGxlOiBBIHNhbXBsZSBjb25mb3JtaW5nIGltcGxl
bWVudGF0aW9uIGZvciBvcGVyYXRvcj09IHdvdWxkIGJlOjwvcD4KPHByZT48Y29kZT4gIHRlbXBs
YXRlJmx0O3R5cGVuYW1lIFQ+IHN0cnVjdCBfX2lkZW50aXR5IHsgdHlwZWRlZiBUIHR5cGU7IH07
CiAgdGVtcGxhdGUmbHQ7dHlwZW5hbWUgY2hhclQsIHR5cGVuYW1lIHRyYWl0cz4KICBib29sIG9w
ZXJhdG9yPT0oYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPiBsaHMsCiAgICAgICAg
ICAgICAgICAgIGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIHRyYWl0cz4gcmhzKSB7CiAgICBy
ZXR1cm4gbGhzLmNvbXBhcmUocmhzKSA9PSAwOwogIH0KICB0ZW1wbGF0ZSZsdDt0eXBlbmFtZSBj
aGFyVCwgdHlwZW5hbWUgdHJhaXRzPgogIGJvb2wgb3BlcmF0b3I9PShiYXNpY19zdHJpbmdfcmVm
Jmx0O2NoYXJULCB0cmFpdHM+IGxocywKICAgICAgICAgICAgICAgICAgdHlwZW5hbWUgX19pZGVu
dGl0eSZsdDtiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCB0cmFpdHM+Pjo6dHlwZSByaHMpIHsK
ICAgIHJldHVybiBsaHMuY29tcGFyZShyaHMpID09IDA7CiAgfQogIHRlbXBsYXRlJmx0O3R5cGVu
YW1lIGNoYXJULCB0eXBlbmFtZSB0cmFpdHM+CiAgYm9vbCBvcGVyYXRvcj09KHR5cGVuYW1lIF9f
aWRlbnRpdHkmbHQ7YmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPj46OnR5cGUgbGhz
LAogICAgICAgICAgICAgICAgICBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCB0cmFpdHM+IHJo
cykgewogICAgcmV0dXJuIGxocy5jb21wYXJlKHJocykgPT0gMDsKfTwvY29kZT48L3ByZT4KICAg
IDxwPuKAlCBlbmQgZXhhbXBsZSBdPC9wPgoKPHByZT48Y29kZT50ZW1wbGF0ZSZsdDtjbGFzcyBj
aGFyVCwgY2xhc3MgdHJhaXRzPgogIGJvb2wgb3BlcmF0b3I9PShiYXNpY19zdHJpbmdfcmVmJmx0
O2NoYXJULHRyYWl0cz4gbGhzLAogICAgICAgICAgICAgICAgICBiYXNpY19zdHJpbmdfcmVmJmx0
O2NoYXJULHRyYWl0cz4gcmhzKSBub2V4Y2VwdDs8L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0i
YXR0cmlidXRlIj48aT5SZXR1cm5zPC9pPjogbGhzLmNvbXBhcmUocmhzKSA9PSAwLjwvcD4KCjxw
cmU+PGNvZGU+dGVtcGxhdGUmbHQ7Y2xhc3MgY2hhclQsIGNsYXNzIHRyYWl0cz4KICBib29sIG9w
ZXJhdG9yIT0oYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCx0cmFpdHM+IGxocywKICAgICAgICAg
ICAgICAgICAgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCx0cmFpdHM+IHJocykgbm9leGNlcHQ7
PC9jb2RlPjwvcHJlPgogICAgPHAgY2xhc3M9ImF0dHJpYnV0ZSI+PGk+UmV0dXJuczwvaT46ICEo
bGhzID09IHJocykuPC9wPgoKPHByZT48Y29kZT50ZW1wbGF0ZSZsdDtjbGFzcyBjaGFyVCwgY2xh
c3MgdHJhaXRzPgogIGJvb2wgb3BlcmF0b3ImbHQ7IChiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJU
LHRyYWl0cz4gbGhzLAogICAgICAgICAgICAgICAgICBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJU
LHRyYWl0cz4gcmhzKSBub2V4Y2VwdDs8L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0iYXR0cmli
dXRlIj48aT5SZXR1cm5zPC9pPjogbGhzLmNvbXBhcmUocmhzKSAmbHQ7IDAuPC9wPgoKPHByZT48
Y29kZT50ZW1wbGF0ZSZsdDtjbGFzcyBjaGFyVCwgY2xhc3MgdHJhaXRzPgogIGJvb2wgb3BlcmF0
b3I+IChiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULHRyYWl0cz4gbGhzLAogICAgICAgICAgICAg
ICAgICBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULHRyYWl0cz4gcmhzKSBub2V4Y2VwdDs8L2Nv
ZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0iYXR0cmlidXRlIj48aT5SZXR1cm5zPC9pPjogbGhzLmNv
bXBhcmUocmhzKSA+IDAuPC9wPgoKPHByZT48Y29kZT50ZW1wbGF0ZSZsdDtjbGFzcyBjaGFyVCwg
Y2xhc3MgdHJhaXRzPgogIGJvb2wgb3BlcmF0b3ImbHQ7PShiYXNpY19zdHJpbmdfcmVmJmx0O2No
YXJULHRyYWl0cz4gbGhzLAogICAgICAgICAgICAgICAgICBiYXNpY19zdHJpbmdfcmVmJmx0O2No
YXJULHRyYWl0cz4gcmhzKSBub2V4Y2VwdDs8L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0iYXR0
cmlidXRlIj48aT5SZXR1cm5zPC9pPjogbGhzLmNvbXBhcmUocmhzKSAmbHQ7PSAwLjwvcD4KCjxw
cmU+PGNvZGU+dGVtcGxhdGUmbHQ7Y2xhc3MgY2hhclQsIGNsYXNzIHRyYWl0cz4KICBib29sIG9w
ZXJhdG9yPj0oYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCx0cmFpdHM+IGxocywKICAgICAgICAg
ICAgICAgICAgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCx0cmFpdHM+IHJocykgbm9leGNlcHQ7
PC9jb2RlPjwvcHJlPgogICAgPHAgY2xhc3M9ImF0dHJpYnV0ZSI+PGk+UmV0dXJuczwvaT46IGxo
cy5jb21wYXJlKHJocykgPj0gMC48L3A+CgogICAgPGg0IGlkPSJzdHJpbmcucmVmLm5vbm1lbSI+
QWRkIGEgc3ViLXN1YmNsYXVzZSAieC55LjggT3RoZXIgYmFzaWNfc3RyaW5nX3JlZiBub24tbWVt
YmVyIGZ1bmN0aW9ucyBbc3RyaW5nLnJlZi5ub25tZW1dIjwvaDQ+CgogICAgPHByZT48Y29kZT50
ZW1wbGF0ZSZsdDtjbGFzcyBjaGFyVCwgY2xhc3MgdHJhaXRzID0gY2hhcl90cmFpdHMmbHQ7Y2hh
clQ+LAogICAgICAgICBjbGFzcyBBbGxvY2F0b3IgPSBhbGxvY2F0b3ImbHQ7Y2hhclQ+ID4KICBi
YXNpY19zdHJpbmcmbHQ7Y2hhclQsIHRyYWl0cywgQWxsb2NhdG9yPiB0b19zdHJpbmcoCiAgICBi
YXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCB0cmFpdHM+IHN0ciwKICAgIGNvbnN0IEFsbG9jYXRv
ciYgYSA9IEFsbG9jYXRvcigpKTs8L2NvZGU+PC9wcmU+CiAgICA8ZGl2IGNsYXNzPSJhdHRyaWJ1
dGVzIj4KICAgICAgPHA+PGk+Q29tcGxleGl0eTwvaT46IE8oc3RyLnNpemUoKSk8L3A+CiAgICAg
IDxwPjxpPlJldHVybnM8L2k+OiBiYXNpY19zdHJpbmcmbHQ7Y2hhclQsIHRyYWl0cywgQWxsb2Nh
dG9yPihzdHIsIGEpLjwvcD4KICAgIDwvZGl2PgoKICAgIDxoMz5BZGQgdG8gdGhlIGFwcHJvcHJp
YXRlIHBsYWNlcyB3aXRoaW4gdGhlIGNsYXNzIGRlZmluaXRpb24gb2YgW2Jhc2ljLnN0cmluZ108
L2gzPgo8cHJlPjxjb2RlPiAgICBleHBsaWNpdCAvLyBGb290bm90ZTogVGhpcyBjb252ZXJzaW9u
IGlzIGV4cGxpY2l0IHRvIGF2b2lkIGFjY2lkZW50YWwgTyhOKSBvcGVyYXRpb25zIG9uIHR5cGUg
bWlzbWF0Y2hlcy4gLS1lbmQgZm9vdG5vdGUKICAgIGJhc2ljX3N0cmluZyhiYXNpY19zdHJpbmdf
cmVmJmx0O2NoYXJULCB0cmFpdHM+LAogICAgICAgICAgICAgICAgIGNvbnN0IEFsbG9jYXRvciYg
PSBBbGxvY2F0b3IoKSk7CiAgICBiYXNpY19zdHJpbmcmIG9wZXJhdG9yPShiYXNpY19zdHJpbmdf
cmVmJmx0O2NoYXJULCB0cmFpdHM+KTsKICAgIGJhc2ljX3N0cmluZyYgb3BlcmF0b3IrPShiYXNp
Y19zdHJpbmdfcmVmJmx0O2NoYXJULCB0cmFpdHM+KTsKICAgIGJhc2ljX3N0cmluZyYgYXBwZW5k
KGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIHRyYWl0cz4pOwogICAgYmFzaWNfc3RyaW5nJiBh
c3NpZ24oYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPik7CiAgICBiYXNpY19zdHJp
bmcmIHJlcGxhY2UoY29uc3RfaXRlcmF0b3IsIGNvbnN0X2l0ZXJhdG9yLCBiYXNpY19zdHJpbmdf
cmVmJmx0O2NoYXJULCB0cmFpdHM+KTsKICAgIG9wZXJhdG9yIGJhc2ljX3N0cmluZ19yZWYmbHQ7
Y2hhclQsIHRyYWl0cz4oKSBjb25zdCBub2V4Y2VwdDsKICAgIGJvb2wgc3RhcnRzX3dpdGgoYmFz
aWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPiBzKSBjb25zdCBub2V4Y2VwdDsKICAgIGJv
b2wgc3RhcnRzX3dpdGgoY2hhclQgYykgY29uc3Qgbm9leGNlcHQ7CiAgICBib29sIHN0YXJ0c193
aXRoKGNvbnN0IGNoYXJUKiBzKSBjb25zdCBub2V4Y2VwdDsKICAgIGJvb2wgZW5kc193aXRoKGJh
c2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIHRyYWl0cz4gcykgY29uc3Qgbm9leGNlcHQ7CiAgICBi
b29sIGVuZHNfd2l0aChjaGFyVCBjKSBjb25zdCBub2V4Y2VwdDsKICAgIGJvb2wgZW5kc193aXRo
KGNvbnN0IGNoYXJUKiBzKSBjb25zdCBub2V4Y2VwdDs8L2NvZGU+PC9wcmU+CgogICAgPGgzIGlk
PSJzdHJpbmcuY29ucyI+QWRkIHRvIFtzdHJpbmcuY29uc108L2gzPgogICAgPHByZT48Y29kZT5l
eHBsaWNpdCBiYXNpY19zdHJpbmcoYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPiBz
dHIsIGNvbnN0IEFsbG9jYXRvciYgYSA9IEFsbG9jYXRvcigpKTs8L2NvZGU+PC9wcmU+CiAgICA8
cCBjbGFzcz0iYXR0cmlidXRlIj48aT5FZmZlY3RzPC9pPjogU2FtZSBhcyBiYXNpY19zdHJpbmco
c3RyLmJlZ2luKCksIHN0ci5lbmQoKSwgYSkuPC9wPgogICAgPGRpdiBjbGFzcz0iZWRub3RlIj48
cD5UaGlzIHVzZXMgIlNhbWUgYXMiIGluc3RlYWQgb2YgIkVxdWl2YWxlbnQgdG8iIHRvIGJlIGNv
bnNpc3RlbnQgd2l0aCB0aGUgcmVzdCBvZiB0aGUgYmFzaWNfc3RyaW5nIHNwZWNpZmljYXRpb24u
PC9wPjwvZGl2PgoKICAgIDxoMz5BZGQgdG8gW3N0cmluZy5hY2Nlc3NvcnNdPC9oMz4KICAgIDxw
cmU+PGNvZGU+b3BlcmF0b3IgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRzPigpIGNv
bnN0IG5vZXhjZXB0OzwvY29kZT48L3ByZT4KICAgIDxkaXYgY2xhc3M9ImF0dHJpYnV0ZXMiPgog
ICAgICA8cD48aT5SZXR1cm5zPC9pPjogYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgdHJhaXRz
PihkYXRhKCksIHNpemUoKSkuPC9wPgogICAgICA8cD48aT5Db21wbGV4aXR5PC9pPjogY29uc3Rh
bnQgdGltZS48L3A+CiAgICAgIDxwPjxpPlJlcXVpcmVzPC9pPjogVGhlIHByb2dyYW0gc2hhbGwg
bm90IGFsdGVyIGFueSBvZiB0aGUgdmFsdWVzIHN0b3JlZCBpbiB0aGUgY2hhcmFjdGVyIGFycmF5
LjwvcD4KICAgIDwvZGl2PgoKICAgIDxoMyBpZD0ic3RyaW5nLnN0YXJ0cy5lbmRzLndpdGgiPkFk
ZCBhIHNlY3Rpb24gImJhc2ljX3N0cmluZzo6c3RhcnRzX3dpdGggYW5kIGVuZHNfd2l0aCBbc3Ry
aW5nLnN0YXJ0cy5lbmRzLndpdGhdIiBpbnNpZGUgW3N0cmluZy5vcHNdPC9oMz4KCiAgICA8cHJl
Pjxjb2RlPmJvb2wgc3RhcnRzX3dpdGgoY29uc3QgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwg
dHJhaXRzPiYgcHJlZml4KSBjb25zdCBub2V4Y2VwdDsKYm9vbCBzdGFydHNfd2l0aChjaGFyVCBw
cmVmaXgpIGNvbnN0IG5vZXhjZXB0Owpib29sIHN0YXJ0c193aXRoKGNvbnN0IGNoYXJUKiBwcmVm
aXgpIGNvbnN0IG5vZXhjZXB0OzwvY29kZT48L3ByZT4KICAgIDxwIGNsYXNzPSJhdHRyaWJ1dGUi
PjxpPkVmZmVjdHM8L2k+OiBFcXVpdmFsZW50IHRvIDxjb2RlPmJhc2ljX3N0cmluZ19yZWYmbHQ7
Y2hhclQsIHRyYWl0cz4oKnRoaXMpLnN0YXJ0c193aXRoKHByZWZpeCk8L2NvZGU+PC9wPgoKICAg
IDxwcmU+PGNvZGU+Ym9vbCBlbmRzX3dpdGgoY29uc3QgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFy
VCwgdHJhaXRzPiYgc3VmZml4KSBjb25zdCBub2V4Y2VwdDsKYm9vbCBlbmRzX3dpdGgoY2hhclQg
c3VmZml4KSBjb25zdCBub2V4Y2VwdDsKYm9vbCBlbmRzX3dpdGgoY29uc3QgY2hhclQqIHN1ZmZp
eCkgY29uc3Qgbm9leGNlcHQ7PC9jb2RlPjwvcHJlPgogICAgPHAgY2xhc3M9ImF0dHJpYnV0ZSI+
PGk+RWZmZWN0czwvaT46IEVxdWl2YWxlbnQgdG8gPGNvZGU+YmFzaWNfc3RyaW5nX3JlZiZsdDtj
aGFyVCwgdHJhaXRzPigqdGhpcykuZW5kc193aXRoKHN1ZmZpeCk8L2NvZGU+PC9wPgoKICAgIDxo
Mz5Nb3ZlIFtzdHJpbmcuaW9dIGRpcmVjdGx5IHVuZGVyIFtzdHJpbmdzXSBhbmQgbW9kaWZ5IGl0
PC9oMz4KCiAgICA8cHJlPjxjb2RlPnRlbXBsYXRlJmx0O2NsYXNzIGNoYXJULCBjbGFzcyB0cmFp
dHMsIGNsYXNzIEFsbG9jYXRvcj4KICBiYXNpY19vc3RyZWFtJmx0O2NoYXJULCB0cmFpdHM+Jgog
ICAgb3BlcmF0b3ImbHQ7Jmx0OyhiYXNpY19vc3RyZWFtJmx0O2NoYXJULCB0cmFpdHM+JiBvcywK
ICAgICAgICAgICAgICAgY29uc3QgYmFzaWNfc3RyaW5nJmx0O2NoYXJULHRyYWl0cyxBbGxvY2F0
b3I+JiBzdHIpOwo8aW5zPnRlbXBsYXRlJmx0O2NsYXNzIGNoYXJULCBjbGFzcyB0cmFpdHMsIGNs
YXNzIEFsbG9jYXRvcj4KICBiYXNpY19vc3RyZWFtJmx0O2NoYXJULCB0cmFpdHM+JgogICAgb3Bl
cmF0b3ImbHQ7Jmx0OyhiYXNpY19vc3RyZWFtJmx0O2NoYXJULCB0cmFpdHM+JiBvcywKICAgICAg
ICAgICAgICAgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCx0cmFpdHM+IHN0cik7PC9pbnM+PC9j
b2RlPjwvcHJlPgogICAgPGRpdiBjbGFzcz0iYXR0cmlidXRlcyI+CiAgICAgIDxwPjxpPkVmZmVj
dHM8L2k+OiBCZWhhdmVzIGFzIGEgZm9ybWF0dGVkIG91dHB1dCBmdW5jdGlvbgogICAgICAoW29z
dHJlYW0uZm9ybWF0dGVkLnJlcW10c10pIG9mIDxjb2RlPm9zPC9jb2RlPi4gRm9ybXMgYSBjaGFy
YWN0ZXIKICAgICAgc2VxdWVuY2UgPGNvZGU+c2VxPC9jb2RlPiwgaW5pdGlhbGx5IGNvbnNpc3Rp
bmcgb2YgdGhlIGVsZW1lbnRzIGRlZmluZWQgYnkKICAgICAgdGhlIHJhbmdlIDxjb2RlPltzdHIu
YmVnaW4oKSwgc3RyLmVuZCgpKTwvY29kZT4uIERldGVybWluZXMgcGFkZGluZyBmb3IKICAgICAg
PGNvZGU+c2VxPC9jb2RlPiBhcyBkZXNjcmliZWQgaW4gW29zdHJlYW0uZm9ybWF0dGVkLnJlcW10
c10uIFRoZW4gaW5zZXJ0cwogICAgICA8Y29kZT5zZXE8L2NvZGU+IGFzIGlmIGJ5IGNhbGxpbmcg
PGNvZGU+b3MucmRidWYoKS0+c3B1dG4oc2VxLCBuKTwvY29kZT4sCiAgICAgIHdoZXJlIDxjb2Rl
Pm48L2NvZGU+IGlzIHRoZSBsYXJnZXIgb2YgPGNvZGU+b3Mud2lkdGgoKTwvY29kZT4gYW5kCiAg
ICAgIDxjb2RlPnN0ci5zaXplKCk8L2NvZGU+OyB0aGVuIGNhbGxzIDxjb2RlPm9zLndpZHRoKDAp
PC9jb2RlPi48L3A+CiAgICAgIDxwPjxpPlJldHVybnM8L2k+OiBvczwvcD4KICAgIDwvZGl2PgoK
CiAgICA8aDMgaWQ9InN0cmluZy5jb252ZXJzaW9ucyI+QWRkIHRvIFtzdHJpbmcuY29udmVyc2lv
bnNdPC9oMz4KICAgIDxwcmU+PGNvZGU+aW50IHN0b2koc3RyaW5nX3JlZiBzdHIsIHNpemVfdCAq
aWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7Cmxvbmcgc3RvbChzdHJpbmdfcmVmIHN0ciwgc2l6ZV90
ICppZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsKdW5zaWduZWQgbG9uZyBzdG91bChzdHJpbmdfcmVm
IHN0ciwgc2l6ZV90ICppZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsKbG9uZyBsb25nIHN0b2xsKHN0
cmluZ19yZWYgc3RyLCBzaXplX3QgKmlkeCA9IDAsIGludCBiYXNlID0gMTApOwp1bnNpZ25lZCBs
b25nIGxvbmcgc3RvdWxsKHN0cmluZ19yZWYgc3RyLCBzaXplX3QgKmlkeCA9IDAsIGludCBiYXNl
ID0gMTApOwpmbG9hdCBzdG9mKHN0cmluZ19yZWYgc3RyLCBzaXplX3QgKmlkeCA9IDApOwpkb3Vi
bGUgc3RvZChzdHJpbmdfcmVmIHN0ciwgc2l6ZV90ICppZHggPSAwKTsKbG9uZyBkb3VibGUgc3Rv
bGQoc3RyaW5nX3JlZiBzdHIsIHNpemVfdCAqaWR4ID0gMCk7CgppbnQgc3RvaShjb25zdCBjaGFy
KiBzdHIsIHNpemVfdCAqaWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7Cmxvbmcgc3RvbChjb25zdCBj
aGFyKiBzdHIsIHNpemVfdCAqaWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7CnVuc2lnbmVkIGxvbmcg
c3RvdWwoY29uc3QgY2hhciogc3RyLCBzaXplX3QgKmlkeCA9IDAsIGludCBiYXNlID0gMTApOwps
b25nIGxvbmcgc3RvbGwoY29uc3QgY2hhciogc3RyLCBzaXplX3QgKmlkeCA9IDAsIGludCBiYXNl
ID0gMTApOwp1bnNpZ25lZCBsb25nIGxvbmcgc3RvdWxsKGNvbnN0IGNoYXIqIHN0ciwgc2l6ZV90
ICppZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsKZmxvYXQgc3RvZihjb25zdCBjaGFyKiBzdHIsIHNp
emVfdCAqaWR4ID0gMCk7CmRvdWJsZSBzdG9kKGNvbnN0IGNoYXIqIHN0ciwgc2l6ZV90ICppZHgg
PSAwKTsKbG9uZyBkb3VibGUgc3RvbGQoY29uc3QgY2hhciogc3RyLCBzaXplX3QgKmlkeCA9IDAp
OzwvY29kZT48L3ByZT4KCiAgICA8ZGl2IGNsYXNzPSJhdHRyaWJ1dGVzIj4KICAgICAgPHA+RWFj
aCBmdW5jdGlvbiBvZiB0aGUgZm9ybXM8L3A+CiAgICAgIDxwcmU+PGNvZGU+ICBydCBmbihzdHJp
bmdfcmVmIHN0ciwgc2l6ZV90ICppZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsKICBydCBmbihjb25z
dCBjaGFyKiBzdHIsIHNpemVfdCAqaWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7PC9jb2RlPjwvcHJl
PgogICAgICA8cD5pcyBlcXVpdmFsZW50IHRvIDxjb2RlPmZuKHN0cmluZyhzdHIpLCBpZHgsIGJh
c2UpPC9jb2RlPi48L3A+CgogICAgICA8cD5FYWNoIGZ1bmN0aW9uIG9mIHRoZSBmb3JtczwvcD4K
ICAgICAgPHByZT48Y29kZT4gIHJ0IGZuKHN0cmluZ19yZWYgc3RyLCBzaXplX3QgKmlkeCA9IDAp
OwogIHJ0IGZuKGNvbnN0IGNoYXIqIHN0ciwgc2l6ZV90ICppZHggPSAwKTs8L2NvZGU+PC9wcmU+
CiAgICAgIDxwPmlzIGVxdWl2YWxlbnQgdG8gPGNvZGU+Zm4oc3RyaW5nKHN0ciksIGlkeCk8L2Nv
ZGU+LjwvcD4KPC9kaXY+Cgo8cHJlPjxjb2RlPmludCBzdG9pKHdzdHJpbmdfcmVmIHN0ciwgc2l6
ZV90ICppZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsKbG9uZyBzdG9sKHdzdHJpbmdfcmVmIHN0ciwg
c2l6ZV90ICppZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsKdW5zaWduZWQgbG9uZyBzdG91bCh3c3Ry
aW5nX3JlZiBzdHIsIHNpemVfdCAqaWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7CmxvbmcgbG9uZyBz
dG9sbCh3c3RyaW5nX3JlZiBzdHIsIHNpemVfdCAqaWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7CnVu
c2lnbmVkIGxvbmcgbG9uZyBzdG91bGwod3N0cmluZ19yZWYgc3RyLCBzaXplX3QgKmlkeCA9IDAs
IGludCBiYXNlID0gMTApOwpmbG9hdCBzdG9mKHdzdHJpbmdfcmVmIHN0ciwgc2l6ZV90ICppZHgg
PSAwKTsKZG91YmxlIHN0b2Qod3N0cmluZ19yZWYgc3RyLCBzaXplX3QgKmlkeCA9IDApOwpsb25n
IGRvdWJsZSBzdG9sZCh3c3RyaW5nX3JlZiBzdHIsIHNpemVfdCAqaWR4ID0gMCk7CgppbnQgc3Rv
aShjb25zdCB3Y2hhcl90KiBzdHIsIHNpemVfdCAqaWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7Cmxv
bmcgc3RvbChjb25zdCB3Y2hhcl90KiBzdHIsIHNpemVfdCAqaWR4ID0gMCwgaW50IGJhc2UgPSAx
MCk7CnVuc2lnbmVkIGxvbmcgc3RvdWwoY29uc3Qgd2NoYXJfdCogc3RyLCBzaXplX3QgKmlkeCA9
IDAsIGludCBiYXNlID0gMTApOwpsb25nIGxvbmcgc3RvbGwoY29uc3Qgd2NoYXJfdCogc3RyLCBz
aXplX3QgKmlkeCA9IDAsIGludCBiYXNlID0gMTApOwp1bnNpZ25lZCBsb25nIGxvbmcgc3RvdWxs
KGNvbnN0IHdjaGFyX3QqIHN0ciwgc2l6ZV90ICppZHggPSAwLCBpbnQgYmFzZSA9IDEwKTsKZmxv
YXQgc3RvZihjb25zdCB3Y2hhcl90KiBzdHIsIHNpemVfdCAqaWR4ID0gMCk7CmRvdWJsZSBzdG9k
KGNvbnN0IHdjaGFyX3QqIHN0ciwgc2l6ZV90ICppZHggPSAwKTsKbG9uZyBkb3VibGUgc3RvbGQo
Y29uc3Qgd2NoYXJfdCogc3RyLCBzaXplX3QgKmlkeCA9IDApOzwvY29kZT48L3ByZT4KCiAgICA8
ZGl2IGNsYXNzPSJhdHRyaWJ1dGVzIj4KICAgICAgPHA+RWFjaCBmdW5jdGlvbiBvZiB0aGUgZm9y
bXM8L3A+CiAgICAgIDxwcmU+PGNvZGU+ICBydCBmbih3c3RyaW5nX3JlZiBzdHIsIHNpemVfdCAq
aWR4ID0gMCwgaW50IGJhc2UgPSAxMCk7CiAgcnQgZm4oY29uc3Qgd2NoYXJfdCogc3RyLCBzaXpl
X3QgKmlkeCA9IDAsIGludCBiYXNlID0gMTApOzwvY29kZT48L3ByZT4KICAgICAgPHA+aXMgZXF1
aXZhbGVudCB0byA8Y29kZT5mbih3c3RyaW5nKHN0ciksIGlkeCwgYmFzZSk8L2NvZGU+LjwvcD4K
CiAgICAgIDxwPkVhY2ggZnVuY3Rpb24gb2YgdGhlIGZvcm1zPC9wPgogICAgICA8cHJlPjxjb2Rl
PiAgcnQgZm4od3N0cmluZ19yZWYgc3RyLCBzaXplX3QgKmlkeCA9IDApOwogIHJ0IGZuKGNvbnN0
IHdjaGFyX3QqIHN0ciwgc2l6ZV90ICppZHggPSAwKTs8L2NvZGU+PC9wcmU+CiAgICAgIDxwPmlz
IGVxdWl2YWxlbnQgdG8gPGNvZGU+Zm4od3N0cmluZyhzdHIpLCBpZHgpPC9jb2RlPi48L3A+CiAg
ICA8L2Rpdj4KCgogICAgPGgzIGlkPSJiYXNpYy5zdHJpbmcuaGFzaCI+TW9kaWZ5IFtiYXNpYy5z
dHJpbmcuaGFzaF08L2gzPgoKICAgIDxwcmU+PGNvZGU+PGlucz50ZW1wbGF0ZSAmbHQ7PiBzdHJ1
Y3QgaGFzaCZsdDtzdHJpbmdfcmVmPjsKdGVtcGxhdGUgJmx0Oz4gc3RydWN0IGhhc2gmbHQ7dTE2
c3RyaW5nX3JlZj47CnRlbXBsYXRlICZsdDs+IHN0cnVjdCBoYXNoJmx0O3UzMnN0cmluZ19yZWY+
Owp0ZW1wbGF0ZSAmbHQ7PiBzdHJ1Y3QgaGFzaCZsdDt3c3RyaW5nX3JlZj47PC9pbnM+CnRlbXBs
YXRlICZsdDs+IHN0cnVjdCBoYXNoJmx0O3N0cmluZz47CnRlbXBsYXRlICZsdDs+IHN0cnVjdCBo
YXNoJmx0O3UxNnN0cmluZz47CnRlbXBsYXRlICZsdDs+IHN0cnVjdCBoYXNoJmx0O3UzMnN0cmlu
Zz47CnRlbXBsYXRlICZsdDs+IHN0cnVjdCBoYXNoJmx0O3dzdHJpbmc+OzwvY29kZT48L3ByZT4K
ICAgIDxwIGNsYXNzPSJhdHRyaWJ1dGUiPjxpPlJlcXVpcmVzPC9pPjogdGhlIHRlbXBsYXRlIHNw
ZWNpYWxpemF0aW9ucyBzaGFsbAogICAgbWVldCB0aGUgcmVxdWlyZW1lbnRzIG9mIGNsYXNzIHRl
bXBsYXRlIGhhc2ggKFt1bm9yZC5oYXNoXSkuPC9wPgoKCiAgICA8aDM+TW9kaWZ5IGEgbm90ZSBp
biBbbG9jYWxlXTwvaDM+CiAgICA8cD5bIE5vdGU6IEFsbCBsb2NhbGUgc2VtYW50aWNzIGFyZSBh
Y2Nlc3NlZCB2aWEgdXNlX2ZhY2V0Jmx0Oz4gYW5kIGhhc19mYWNldCZsdDs+LCBleGNlcHQgdGhh
dDo8L3A+CiAgICA8dWw+CiAgICAgIDxsaT48ZGVsPkEgbWVtYmVyIG9wZXJhdG9yIHRlbXBsYXRl
IDwvZGVsPjxpbnM+VHdvIG1lbWJlciBvcGVyYXRvcgogICAgICB0ZW1wbGF0ZXMgPC9pbnM+b3Bl
cmF0b3IoKShjb25zdCBiYXNpY19zdHJpbmcmbHQ7QywgVCwgQT4mLCBjb25zdAogICAgICBiYXNp
Y19zdHJpbmcmbHQ7QywgVCwgQT4mKSA8ZGVsPmlzIDwvZGVsPjxpbnM+YW5kIG9wZXJhdG9yKCko
Y29uc3QKICAgICAgYmFzaWNfc3RyaW5nX3JlZiZsdDtDLCBUPiYsIGNvbnN0IGJhc2ljX3N0cmlu
Z19yZWYmbHQ7QywgVD4mKSBhcmUKICAgICAgPC9pbnM+cHJvdmlkZWQgc28gdGhhdCBhIGxvY2Fs
ZSBtYXkgYmUgdXNlZCBhcyBhIHByZWRpY2F0ZSBhcmd1bWVudCB0byB0aGUKICAgICAgc3RhbmRh
cmQgY29sbGVjdGlvbnMsIHRvIGNvbGxhdGUgc3RyaW5ncy48L2xpPgogICAgICA8bGk+Q29udmVu
aWVudCBnbG9iYWwgaW50ZXJmYWNlcyBhcmUgcHJvdmlkZWQgZm9yIHRyYWRpdGlvbmFsIGN0eXBl
CiAgICAgIGZ1bmN0aW9ucyBzdWNoIGFzIGlzZGlnaXQoKSBhbmQgaXNzcGFjZSgpLCBzbyB0aGF0
IGdpdmVuIGEgbG9jYWxlIG9iamVjdAogICAgICBsb2MgYSBDKysgcHJvZ3JhbSBjYW4gY2FsbCBp
c3NwYWNlKGMsbG9jKS4gKFRoaXMgZWFzZXMgdXBncmFkaW5nIGV4aXN0aW5nCiAgICAgIGV4dHJh
Y3RvcnMgKDI3LjcuMi4yKS4pIOKAlCBlbmQgbm90ZSBdPC9saT4KICAgIDwvdWw+CgoKICAgIDxo
Mz5Nb2RpZnkgW2xvY2FsZS5vcGVyYXRvcnNdPC9oMz4KPHByZT48Y29kZT50ZW1wbGF0ZSAmbHQ7
Y2xhc3MgY2hhclQsIGNsYXNzIHRyYWl0cywgY2xhc3MgQWxsb2NhdG9yPgogIGJvb2wgb3BlcmF0
b3IoKShjb25zdCBiYXNpY19zdHJpbmcmbHQ7Y2hhclQsdHJhaXRzLEFsbG9jYXRvcj4mIHMxLAog
ICAgICAgICAgICAgICAgICBjb25zdCBiYXNpY19zdHJpbmcmbHQ7Y2hhclQsdHJhaXRzLEFsbG9j
YXRvcj4mIHMyKSBjb25zdDsKPGlucz50ZW1wbGF0ZSAmbHQ7Y2xhc3MgY2hhclQsIGNsYXNzIHRy
YWl0cz4KICBib29sIG9wZXJhdG9yKCkoY29uc3QgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCx0
cmFpdHM+JiBzMSwKICAgICAgICAgICAgICAgICAgY29uc3QgYmFzaWNfc3RyaW5nX3JlZiZsdDtj
aGFyVCx0cmFpdHM+JiBzMikgY29uc3Q7PC9pbnM+PC9jb2RlPjwvcHJlPgoKICAgIDxkaXYgY2xh
c3M9ImF0dHJpYnV0ZXMiPgogICAgICA8cD48aT5FZmZlY3RzPC9pPjogQ29tcGFyZXMgdHdvIHN0
cmluZ3MgYWNjb3JkaW5nIHRvIHRoZSBjb2xsYXRlJmx0O2NoYXJUPiBmYWNldC48L3A+CiAgICAg
IDxwPjxpPlJlbWFya3M8L2k+OiBUaGlzIG1lbWJlciBvcGVyYXRvciB0ZW1wbGF0ZSAoYW5kIHRo
ZXJlZm9yZSBsb2NhbGUgaXRzZWxmKQogICAgICBzYXRpc2ZpZXMgcmVxdWlyZW1lbnRzIGZvciBh
IGNvbXBhcmF0b3IgcHJlZGljYXRlIHRlbXBsYXRlIGFyZ3VtZW50IChDbGF1c2UgMjUpCiAgICAg
IGFwcGxpZWQgdG8gc3RyaW5ncy48L3A+CiAgICAgIDxwPjxpPlJldHVybnM8L2k+OiBUaGUgcmVz
dWx0IG9mIHRoZSBmb2xsb3dpbmcgZXhwcmVzc2lvbjoKICAgICAgPGNvZGU+dXNlX2ZhY2V0Jmx0
OyBjb2xsYXRlJmx0O2NoYXJUPiA+KCp0aGlzKS5jb21wYXJlPHdici8+CiAgICAgIChzMS5kYXRh
KCksIHMxLmRhdGEoKStzMS5zaXplKCksIHMyLmRhdGEoKSwgczIuZGF0YSgpK3MyLnNpemUoKSkg
Jmx0OyAwOzwvY29kZT48L3A+CiAgICA8L2Rpdj4KCgogICAgPGgzPk1vZGlmeSBbY29udmVyc2lv
bnMuc3RyaW5nXTwvaDM+CjxwcmU+PGNvZGU+bmFtZXNwYWNlIHN0ZCB7CnRlbXBsYXRlJmx0O2Ns
YXNzIENvZGVjdnQsIGNsYXNzIEVsZW0gPSB3Y2hhcl90LAogICAgY2xhc3MgV2lkZV9hbGxvYyA9
IHN0ZDo6YWxsb2NhdG9yJmx0O0VsZW0+LAogICAgY2xhc3MgQnl0ZV9hbGxvYyA9IHN0ZDo6YWxs
b2NhdG9yJmx0O2NoYXI+ID4gY2xhc3Mgd3N0cmluZ19jb252ZXJ0IHsKICAgIC8vIC4uLgogICAg
PGlucz53aWRlX3N0cmluZyBmcm9tX2J5dGVzKGNvbnN0IGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hh
cj4mIHN0cik7CiAgICBieXRlX3N0cmluZyB0b19ieXRlcyhjb25zdCBiYXNpY19zdHJpbmdfcmVm
Jmx0O0VsZW0+JiB3c3RyKTs8L2lucz4KICAgIC8vIC4uLgogIH07Cn08L2NvZGU+PC9wcmU+Cgo8
cHJlPjxjb2RlPndpZGVfc3RyaW5nIGZyb21fYnl0ZXMoY2hhciBieXRlKTsKd2lkZV9zdHJpbmcg
ZnJvbV9ieXRlcyhjb25zdCBjaGFyICpwdHIpOwp3aWRlX3N0cmluZyBmcm9tX2J5dGVzKGNvbnN0
IGJ5dGVfc3RyaW5nJiBzdHIpOwo8aW5zPndpZGVfc3RyaW5nIGZyb21fYnl0ZXMoY29uc3QgYmFz
aWNfc3RyaW5nX3JlZiZsdDtjaGFyPiYgc3RyKTs8L2lucz4Kd2lkZV9zdHJpbmcgZnJvbV9ieXRl
cyhjb25zdCBjaGFyICpmaXJzdCwgY29uc3QgY2hhciAqbGFzdCk7PC9jb2RlPjwvcHJlPgoKICAg
ICA8cCBjbGFzcz0iYXR0cmlidXRlIj48aT5FZmZlY3RzPC9pPjogVGhlIGZpcnN0IG1lbWJlciBm
dW5jdGlvbiBzaGFsbAogICAgIGNvbnZlcnQgdGhlIHNpbmdsZS1lbGVtZW50IHNlcXVlbmNlIGJ5
dGUgdG8gYSB3aWRlIHN0cmluZy4gIFRoZSBzZWNvbmQKICAgICBtZW1iZXIgZnVuY3Rpb24gc2hh
bGwgY29udmVydCB0aGUgbnVsbC10ZXJtaW5hdGVkIHNlcXVlbmNlIGJlZ2lubmluZyBhdCBwdHIK
ICAgICB0byBhIHdpZGUgc3RyaW5nLiBUaGUgdGhpcmQgPGRlbD5tZW1iZXIgZnVuY3Rpb24gPC9k
ZWw+PGlucz5hbmQgZm91cnRoCiAgICAgbWVtYmVyIGZ1bmN0aW9ucyA8L2lucz5zaGFsbCBjb252
ZXJ0IHRoZSBzZXF1ZW5jZSBzdG9yZWQgaW4gc3RyIHRvIGEgd2lkZQogICAgIHN0cmluZy4gVGhl
IDxkZWw+Zm91cnRoIDwvZGVsPjxpbnM+ZmlmdGggPC9pbnM+bWVtYmVyIGZ1bmN0aW9uIHNoYWxs
CiAgICAgY29udmVydCB0aGUgc2VxdWVuY2UgZGVmaW5lZCBieSB0aGUgcmFuZ2UgW2ZpcnN0LGxh
c3QpIHRvIGEgd2lkZQogICAgIHN0cmluZy48L3A+Cgo8cHJlPjxjb2RlPmJ5dGVfc3RyaW5nIHRv
X2J5dGVzKEVsZW0gd2NoYXIpOwpieXRlX3N0cmluZyB0b19ieXRlcyhjb25zdCBFbGVtICp3cHRy
KTsKYnl0ZV9zdHJpbmcgdG9fYnl0ZXMoY29uc3Qgd2lkZV9zdHJpbmcmIHdzdHIpOwo8aW5zPmJ5
dGVfc3RyaW5nIHRvX2J5dGVzKGNvbnN0IGJhc2ljX3N0cmluZ19yZWYmbHQ7RWxlbT4mIHdzdHIp
OzwvaW5zPgpieXRlX3N0cmluZyB0b19ieXRlcyhjb25zdCBFbGVtICpmaXJzdCwgY29uc3QgRWxl
bSAqbGFzdCk7PC9jb2RlPjwvcHJlPgoKICAgIDxwIGNsYXNzPSJhdHRyaWJ1dGUiPjxpPkVmZmVj
dHM8L2k+OiBUaGUgZmlyc3QgbWVtYmVyIGZ1bmN0aW9uIHNoYWxsIGNvbnZlcnQKICAgIHRoZSBz
aW5nbGUtZWxlbWVudCBzZXF1ZW5jZSB3Y2hhciB0byBhIGJ5dGUgc3RyaW5nLiAgVGhlIHNlY29u
ZCBtZW1iZXIKICAgIGZ1bmN0aW9uIHNoYWxsIGNvbnZlcnQgdGhlIG51bGwtdGVybWluYXRlZCBz
ZXF1ZW5jZSBiZWdpbm5pbmcgYXQgd3B0ciB0byBhCiAgICBieXRlIHN0cmluZy4gVGhlIHRoaXJk
IDxkZWw+bWVtYmVyIGZ1bmN0aW9uIDwvZGVsPjxpbnM+YW5kIGZvdXJ0aCBtZW1iZXIKICAgIGZ1
bmN0aW9ucyA8L2lucz5zaGFsbCBjb252ZXJ0IHRoZSBzZXF1ZW5jZSBzdG9yZWQgaW4gd3N0ciB0
byBhIGJ5dGUKICAgIHN0cmluZy4gVGhlIDxkZWw+Zm91cnRoIDwvZGVsPjxpbnM+ZmlmdGggPC9p
bnM+bWVtYmVyIGZ1bmN0aW9uIHNoYWxsIGNvbnZlcnQKICAgIHRoZSBzZXF1ZW5jZSBkZWZpbmVk
IGJ5IHRoZSByYW5nZSBbZmlyc3QsbGFzdCkgdG8gYSBieXRlIHN0cmluZy48L3A+CgoKICAgIDxo
Mz5BZGQgdG8gdGhlIGFwcHJvcHJpYXRlIHBsYWNlcyB3aXRoaW4gW3JlLnN5bl08L2gzPgo8cHJl
Pjxjb2RlPnRlbXBsYXRlICZsdDtjbGFzcyBCaUl0ZXIsIGNsYXNzIFNUPgogIGJvb2wgb3BlcmF0
b3I9PSgKICAgIGJhc2ljX3N0cmluZ19yZWYmbHQ7CiAgICAgIHR5cGVuYW1lIGl0ZXJhdG9yX3Ry
YWl0cyZsdDtCaUl0ZXI+Ojp2YWx1ZV90eXBlLCBTVD4gbGhzLAogICAgY29uc3Qgc3ViX21hdGNo
Jmx0O0JpSXRlcj4mIHJocyk7CnRlbXBsYXRlICZsdDtjbGFzcyBCaUl0ZXIsIGNsYXNzIFNUPgog
IGJvb2wgb3BlcmF0b3IhPSgKICAgIGJhc2ljX3N0cmluZ19yZWYmbHQ7CiAgICAgIHR5cGVuYW1l
IGl0ZXJhdG9yX3RyYWl0cyZsdDtCaUl0ZXI+Ojp2YWx1ZV90eXBlLCBTVD4gbGhzLAogICAgY29u
c3Qgc3ViX21hdGNoJmx0O0JpSXRlcj4mIHJocyk7CnRlbXBsYXRlICZsdDtjbGFzcyBCaUl0ZXIs
IGNsYXNzIFNUPgogIGJvb2wgb3BlcmF0b3ImbHQ7KAogICAgYmFzaWNfc3RyaW5nX3JlZiZsdDsK
ICAgICAgdHlwZW5hbWUgaXRlcmF0b3JfdHJhaXRzJmx0O0JpSXRlcj46OnZhbHVlX3R5cGUsIFNU
PiBsaHMsCiAgICBjb25zdCBzdWJfbWF0Y2gmbHQ7QmlJdGVyPiYgcmhzKTsKdGVtcGxhdGUgJmx0
O2NsYXNzIEJpSXRlciwgY2xhc3MgU1Q+CiAgYm9vbCBvcGVyYXRvcj4oCiAgICBiYXNpY19zdHJp
bmdfcmVmJmx0OwogICAgICB0eXBlbmFtZSBpdGVyYXRvcl90cmFpdHMmbHQ7QmlJdGVyPjo6dmFs
dWVfdHlwZSwgU1Q+IGxocywKICAgIGNvbnN0IHN1Yl9tYXRjaCZsdDtCaUl0ZXI+JiByaHMpOwp0
ZW1wbGF0ZSAmbHQ7Y2xhc3MgQmlJdGVyLCBjbGFzcyBTVD4KICBib29sIG9wZXJhdG9yPj0oCiAg
ICBiYXNpY19zdHJpbmdfcmVmJmx0OwogICAgICB0eXBlbmFtZSBpdGVyYXRvcl90cmFpdHMmbHQ7
QmlJdGVyPjo6dmFsdWVfdHlwZSwgU1Q+IGxocywKICAgIGNvbnN0IHN1Yl9tYXRjaCZsdDtCaUl0
ZXI+JiByaHMpOwp0ZW1wbGF0ZSAmbHQ7Y2xhc3MgQmlJdGVyLCBjbGFzcyBTVD4KICBib29sIG9w
ZXJhdG9yJmx0Oz0oCiAgICBiYXNpY19zdHJpbmdfcmVmJmx0OwogICAgICB0eXBlbmFtZSBpdGVy
YXRvcl90cmFpdHMmbHQ7QmlJdGVyPjo6dmFsdWVfdHlwZSwgU1Q+IGxocywKICAgIGNvbnN0IHN1
Yl9tYXRjaCZsdDtCaUl0ZXI+JiByaHMpOwoKdGVtcGxhdGUgJmx0O2NsYXNzIEJpSXRlciwgY2xh
c3MgU1Q+CiAgYm9vbCBvcGVyYXRvcj09KAogICAgY29uc3Qgc3ViX21hdGNoJmx0O0JpSXRlcj4m
IGxocywKICAgIGJhc2ljX3N0cmluZ19yZWYmbHQ7CiAgICAgIHR5cGVuYW1lIGl0ZXJhdG9yX3Ry
YWl0cyZsdDtCaUl0ZXI+Ojp2YWx1ZV90eXBlLCBTVD4gcmhzKTsKdGVtcGxhdGUgJmx0O2NsYXNz
IEJpSXRlciwgY2xhc3MgU1Q+CmJvb2wgb3BlcmF0b3IhPSgKICAgICAgIGNvbnN0IHN1Yl9tYXRj
aCZsdDtCaUl0ZXI+JiBsaHMsCiAgICAgICAgYmFzaWNfc3RyaW5nX3JlZiZsdDsKICAgICAgICAg
IHR5cGVuYW1lIGl0ZXJhdG9yX3RyYWl0cyZsdDtCaUl0ZXI+Ojp2YWx1ZV90eXBlLCBTVD4gcmhz
KTsKdGVtcGxhdGUgJmx0O2NsYXNzIEJpSXRlciwgY2xhc3MgU1Q+CiAgYm9vbCBvcGVyYXRvciZs
dDsoCiAgICBjb25zdCBzdWJfbWF0Y2gmbHQ7QmlJdGVyPiYgbGhzLAogICAgYmFzaWNfc3RyaW5n
X3JlZiZsdDsKICAgICAgdHlwZW5hbWUgaXRlcmF0b3JfdHJhaXRzJmx0O0JpSXRlcj46OnZhbHVl
X3R5cGUsIFNUPiByaHMpOwp0ZW1wbGF0ZSAmbHQ7Y2xhc3MgQmlJdGVyLCBjbGFzcyBTVD4KICBi
b29sIG9wZXJhdG9yPigKICAgIGNvbnN0IHN1Yl9tYXRjaCZsdDtCaUl0ZXI+JiBsaHMsCiAgICBi
YXNpY19zdHJpbmdfcmVmJmx0OwogICAgICB0eXBlbmFtZSBpdGVyYXRvcl90cmFpdHMmbHQ7QmlJ
dGVyPjo6dmFsdWVfdHlwZSwgU1Q+IHJocyk7CnRlbXBsYXRlICZsdDtjbGFzcyBCaUl0ZXIsIGNs
YXNzIFNUPgogIGJvb2wgb3BlcmF0b3I+PSgKICAgIGNvbnN0IHN1Yl9tYXRjaCZsdDtCaUl0ZXI+
JiBsaHMsCiAgICBiYXNpY19zdHJpbmdfcmVmJmx0OwogICAgICB0eXBlbmFtZSBpdGVyYXRvcl90
cmFpdHMmbHQ7QmlJdGVyPjo6dmFsdWVfdHlwZSwgU1Q+IHJocyk7CnRlbXBsYXRlICZsdDtjbGFz
cyBCaUl0ZXIsIGNsYXNzIFNUPgogIGJvb2wgb3BlcmF0b3ImbHQ7PSgKICAgIGNvbnN0IHN1Yl9t
YXRjaCZsdDtCaUl0ZXI+JiBsaHMsCiAgICBiYXNpY19zdHJpbmdfcmVmJmx0OwogICAgICB0eXBl
bmFtZSBpdGVyYXRvcl90cmFpdHMmbHQ7QmlJdGVyPjo6dmFsdWVfdHlwZSwgU1Q+IHJocyk7Cgp0
ZW1wbGF0ZSAmbHQ7Y2xhc3MgU1QsIGNsYXNzIEFsbG9jYXRvciwgY2xhc3MgY2hhclQsIGNsYXNz
IHRyYWl0cz4KICBib29sIHJlZ2V4X21hdGNoKGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIFNU
PiBzLAogICAgICAgICAgICAgICAgICAgbWF0Y2hfcmVzdWx0cyZsdDsKICAgICAgICAgICAgICAg
ICAgICAgdHlwZW5hbWUgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgU1Q+Ojpjb25zdF9pdGVy
YXRvciwKICAgICAgICAgICAgICAgICAgICAgQWxsb2NhdG9yPiYgbSwKICAgICAgICAgICAgICAg
ICAgIGNvbnN0IGJhc2ljX3JlZ2V4Jmx0O2NoYXJULCB0cmFpdHM+JiBlLAogICAgICAgICAgICAg
ICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9mbGFnX3R5cGUgZmxhZ3MgPQogICAgICAgICAg
ICAgICAgICAgICByZWdleF9jb25zdGFudHM6Om1hdGNoX2RlZmF1bHQpOwp0ZW1wbGF0ZSAmbHQ7
Y2xhc3MgU1QsIGNsYXNzIGNoYXJULCBjbGFzcyB0cmFpdHM+CiAgYm9vbCByZWdleF9tYXRjaChi
YXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCBTVD4gcywKICAgICAgICAgICAgICAgICAgIGNvbnN0
IGJhc2ljX3JlZ2V4Jmx0O2NoYXJULCB0cmFpdHM+JiBlLAogICAgICAgICAgICAgICAgICAgcmVn
ZXhfY29uc3RhbnRzOjptYXRjaF9mbGFnX3R5cGUgZmxhZ3MgPQogICAgICAgICAgICAgICAgICAg
ICByZWdleF9jb25zdGFudHM6Om1hdGNoX2RlZmF1bHQpOwoKdGVtcGxhdGUgJmx0O2NsYXNzIFNU
LCBjbGFzcyBjaGFyVCwgY2xhc3MgdHJhaXRzPgogIGJvb2wgcmVnZXhfc2VhcmNoKGJhc2ljX3N0
cmluZ19yZWYmbHQ7Y2hhclQsIFNUPiBzLAogICAgICAgICAgICAgICAgICAgIGNvbnN0IGJhc2lj
X3JlZ2V4Jmx0O2NoYXJULCB0cmFpdHM+JiBlLAogICAgICAgICAgICAgICAgICAgIHJlZ2V4X2Nv
bnN0YW50czo6bWF0Y2hfZmxhZ190eXBlIGZsYWdzID0KICAgICAgICAgICAgICAgICAgICAgIHJl
Z2V4X2NvbnN0YW50czo6bWF0Y2hfZGVmYXVsdCk7CnRlbXBsYXRlICZsdDtjbGFzcyBTVCwgY2xh
c3MgQWxsb2NhdG9yLCBjbGFzcyBjaGFyVCwgY2xhc3MgdHJhaXRzPgogIGJvb2wgcmVnZXhfc2Vh
cmNoKGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIFNUPiBzLAogICAgICAgICAgICAgICAgICAg
IG1hdGNoX3Jlc3VsdHMmbHQ7CiAgICAgICAgICAgICAgICAgICAgICB0eXBlbmFtZSBiYXNpY19z
dHJpbmdfcmVmJmx0O2NoYXJULCBTVD46OmNvbnN0X2l0ZXJhdG9yLAogICAgICAgICAgICAgICAg
ICAgICAgQWxsb2NhdG9yPiYgbSwKICAgICAgICAgICAgICAgICAgICBjb25zdCBiYXNpY19yZWdl
eCZsdDtjaGFyVCwgdHJhaXRzPiYgZSwKICAgICAgICAgICAgICAgICAgICByZWdleF9jb25zdGFu
dHM6Om1hdGNoX2ZsYWdfdHlwZSBmbGFncyA9CiAgICAgICAgICAgICAgICAgICAgICByZWdleF9j
b25zdGFudHM6Om1hdGNoX2RlZmF1bHQpOwoKdGVtcGxhdGUgJmx0O2NsYXNzIE91dHB1dEl0ZXJh
dG9yLCBjbGFzcyBCaWRpcmVjdGlvbmFsSXRlcmF0b3IsCiAgICBjbGFzcyB0cmFpdHMsIGNsYXNz
IGNoYXJULCBjbGFzcyBTVD4KICBPdXRwdXRJdGVyYXRvcgogIHJlZ2V4X3JlcGxhY2UoT3V0cHV0
SXRlcmF0b3Igb3V0LAogICAgICAgICAgICAgICAgQmlkaXJlY3Rpb25hbEl0ZXJhdG9yIGZpcnN0
LCBCaWRpcmVjdGlvbmFsSXRlcmF0b3IgbGFzdCwKICAgICAgICAgICAgICAgIGNvbnN0IGJhc2lj
X3JlZ2V4Jmx0O2NoYXJULCB0cmFpdHM+JiBlLAogICAgICAgICAgICAgICAgYmFzaWNfc3RyaW5n
X3JlZiZsdDtjaGFyVCwgU1Q+IGZtdCwKICAgICAgICAgICAgICAgIHJlZ2V4X2NvbnN0YW50czo6
bWF0Y2hfZmxhZ190eXBlIGZsYWdzID0KICAgICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRz
OjptYXRjaF9kZWZhdWx0KTs8L2NvZGU+PC9wcmU+CiAgICA8ZGl2IGNsYXNzPSJlZG5vdGUiPjxw
PlRoaXMgd29yZGluZyA8YSBocmVmPSIjbm8tZml4LTIyMTYiPmRvZXMgbm90IGluY2x1ZGUKICAg
IGEgZml4PC9hPiBmb3IgPGEKICAgIGhyZWY9Imh0dHA6Ly9jcGx1c3BsdXMuZ2l0aHViLmNvbS9M
V0cvbHdnLWFjdGl2ZS5odG1sIzIyMTYiPkxXRyBpc3N1ZQogICAgMjIxNjwvYT4uIFRoYXQgaXMs
IHRoZSBuZXcgb3ZlcmxvYWRzIGFsd2F5cyB1c2UgdGhlIGRlZmF1bHQKICAgIGFsbG9jYXRvci48
L3A+PC9kaXY+CjxwcmU+PGNvZGU+dGVtcGxhdGUgJmx0O2NsYXNzIHRyYWl0cywgY2xhc3MgY2hh
clQsIGNsYXNzIFNULCBjbGFzcyBGU1Q+CiAgYmFzaWNfc3RyaW5nJmx0O2NoYXJULCBTVD4KICBy
ZWdleF9yZXBsYWNlKGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIFNUPiBzLAogICAgICAgICAg
ICAgICAgY29uc3QgYmFzaWNfcmVnZXgmbHQ7Y2hhclQsIHRyYWl0cz4mIGUsCiAgICAgICAgICAg
ICAgICBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCBGU1Q+IGZtdCwKICAgICAgICAgICAgICAg
IHJlZ2V4X2NvbnN0YW50czo6bWF0Y2hfZmxhZ190eXBlIGZsYWdzID0KICAgICAgICAgICAgICAg
ICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9kZWZhdWx0KTsKdGVtcGxhdGUgJmx0O2NsYXNzIHRy
YWl0cywgY2xhc3MgY2hhclQsIGNsYXNzIFNUPgogIGJhc2ljX3N0cmluZyZsdDtjaGFyVCwgU1Q+
CiAgcmVnZXhfcmVwbGFjZShiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCBTVD4gcywKICAgICAg
ICAgICAgICAgIGNvbnN0IGJhc2ljX3JlZ2V4Jmx0O2NoYXJULCB0cmFpdHM+JiBlLAogICAgICAg
ICAgICAgICAgY29uc3QgY2hhclQqIGZtdCwKICAgICAgICAgICAgICAgIHJlZ2V4X2NvbnN0YW50
czo6bWF0Y2hfZmxhZ190eXBlIGZsYWdzID0KICAgICAgICAgICAgICAgICAgcmVnZXhfY29uc3Rh
bnRzOjptYXRjaF9kZWZhdWx0KTsKdGVtcGxhdGUgJmx0O2NsYXNzIHRyYWl0cywgY2xhc3MgY2hh
clQsIGNsYXNzIFNUPgogIGJhc2ljX3N0cmluZyZsdDtjaGFyVD4KICByZWdleF9yZXBsYWNlKGNv
bnN0IGNoYXJUKiBzLAogICAgICAgICAgICAgICAgY29uc3QgYmFzaWNfcmVnZXgmbHQ7Y2hhclQs
IHRyYWl0cz4mIGUsCiAgICAgICAgICAgICAgICBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCBT
VD4gZm10LAogICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9mbGFnX3R5cGUg
ZmxhZ3MgPQogICAgICAgICAgICAgICAgICByZWdleF9jb25zdGFudHM6Om1hdGNoX2RlZmF1bHQp
Owp0ZW1wbGF0ZSAmbHQ7Y2xhc3MgdHJhaXRzLCBjbGFzcyBjaGFyVCwgY2xhc3MgU1QsIGNsYXNz
IFNBLAogICAgICAgICAgY2xhc3MgRlNUPgogIGJhc2ljX3N0cmluZyZsdDtjaGFyVCwgU1QsIFNB
PgogIHJlZ2V4X3JlcGxhY2UoY29uc3QgYmFzaWNfc3RyaW5nJmx0O2NoYXJULCBTVCwgU0E+JiBz
LAogICAgICAgICAgICAgICAgY29uc3QgYmFzaWNfcmVnZXgmbHQ7Y2hhclQsIHRyYWl0cz4mIGUs
CiAgICAgICAgICAgICAgICBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCBGU1Q+IGZtdCwKICAg
ICAgICAgICAgICAgIHJlZ2V4X2NvbnN0YW50czo6bWF0Y2hfZmxhZ190eXBlIGZsYWdzID0KICAg
ICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9kZWZhdWx0KTsKdGVtcGxhdGUg
Jmx0O2NsYXNzIHRyYWl0cywgY2xhc3MgY2hhclQsIGNsYXNzIFNULAogICAgICAgICAgY2xhc3Mg
RlNULCBjbGFzcyBGU0E+CiAgYmFzaWNfc3RyaW5nJmx0O2NoYXJULCBTVD4KICByZWdleF9yZXBs
YWNlKGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIFNUPiBzLAogICAgICAgICAgICAgICAgY29u
c3QgYmFzaWNfcmVnZXgmbHQ7Y2hhclQsIHRyYWl0cz4mIGUsCiAgICAgICAgICAgICAgICBjb25z
dCBiYXNpY19zdHJpbmcmbHQ7Y2hhclQsIEZTVCwgRlNBPiYgZm10LAogICAgICAgICAgICAgICAg
cmVnZXhfY29uc3RhbnRzOjptYXRjaF9mbGFnX3R5cGUgZmxhZ3MgPQogICAgICAgICAgICAgICAg
ICByZWdleF9jb25zdGFudHM6Om1hdGNoX2RlZmF1bHQpOzwvY29kZT48L3ByZT4KCgogICAgPGgz
PkFkZCB0byB0aGUgYXBwcm9wcmlhdGUgcGxhY2VzIHdpdGhpbiBbcmUucmVnZXhdPC9oMz4KPHBy
ZT48Y29kZT50ZW1wbGF0ZSAmbHQ7Y2xhc3MgU1Q+CiAgZXhwbGljaXQgYmFzaWNfcmVnZXgoYmFz
aWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgU1Q+IHAsCiAgICAgICAgICAgICAgICAgICAgICAgZmxh
Z190eXBlIGYgPSByZWdleF9jb25zdGFudHM6OkVDTUFTY3JpcHQpOwp0ZW1wbGF0ZSAmbHQ7Y2xh
c3MgU1Q+CiAgYmFzaWNfcmVnZXgmIG9wZXJhdG9yPShiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJU
LCBTVD4gcCk7CnRlbXBsYXRlICZsdDtjbGFzcyBzdHJpbmdfdHJhaXRzPgogIGJhc2ljX3JlZ2V4
JiBhc3NpZ24oYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgc3RyaW5nX3RyYWl0cz4gcywKICAg
ICAgICAgICAgICAgICAgICAgIGZsYWdfdHlwZSBmID0gcmVnZXhfY29uc3RhbnRzOjpFQ01BU2Ny
aXB0KTs8L2NvZGU+PC9wcmU+CgoKICAgIDxoMz5Nb2RpZnkgW3JlLnJlZ2V4LmNvbnN0cnVjdF08
L2gzPgo8cHJlPjxjb2RlPjxpbnM+dGVtcGxhdGUgJmx0O2NsYXNzIFNUPgogIGJhc2ljX3JlZ2V4
KGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIFNUPiBzLAogICAgICAgICAgICAgIGZsYWdfdHlw
ZSBmID0gcmVnZXhfY29uc3RhbnRzOjpFQ01BU2NyaXB0KTs8L2lucz4KdGVtcGxhdGUgJmx0O2Ns
YXNzIFNULCBjbGFzcyBTQT4KYmFzaWNfcmVnZXgoY29uc3QgYmFzaWNfc3RyaW5nJmx0O2NoYXJU
LCBTVCwgU0E+JiBzLAogICAgICAgICAgICBmbGFnX3R5cGUgZiA9IHJlZ2V4X2NvbnN0YW50czo6
RUNNQVNjcmlwdCk7PC9jb2RlPjwvcHJlPgogICAgPGRpdiBjbGFzcz0iYXR0cmlidXRlcyI+CiAg
ICAgIDxwPjxpPlRocm93czwvaT46IHJlZ2V4X2Vycm9yIGlmIHMgaXMgbm90IGEgdmFsaWQgcmVn
dWxhciBleHByZXNzaW9uLjwvcD4KICAgICAgPHA+PGk+RWZmZWN0czwvaT46IENvbnN0cnVjdHMg
YW4gb2JqZWN0IG9mIGNsYXNzIGJhc2ljX3JlZ2V4OyB0aGUgb2JqZWN04oCZcyBpbnRlcm5hbCBm
aW5pdGUgc3RhdGUgbWFjaGluZSBpcyBjb24tIHN0cnVjdGVkIGZyb20gdGhlIHJlZ3VsYXIgZXhw
cmVzc2lvbiBjb250YWluZWQgaW4gdGhlIHN0cmluZyBzLCBhbmQgaW50ZXJwcmV0ZWQgYWNjb3Jk
aW5nIHRvIHRoZSBmbGFncyBzcGVjaWZpZWQgaW4gZi48L3A+CiAgICAgIDxwPjxpPlBvc3Rjb25k
aXRpb25zPC9pPjogZmxhZ3MoKSByZXR1cm5zIGYuIG1hcmtfY291bnQoKSByZXR1cm5zIHRoZSBu
dW1iZXIgb2YgbWFya2VkIHN1Yi1leHByZXNzaW9ucyB3aXRoaW4gdGhlIGV4cHJlc3Npb24uPC9w
PgogICAgPC9kaXY+CgoKICAgIDxoMz5Nb2RpZnkgW3JlLnJlZ2V4LmFzc2lnbl08L2gzPgo8cHJl
Pjxjb2RlPjxpbnM+dGVtcGxhdGUgJmx0O2NsYXNzIFNUPgogIGJhc2ljX3JlZ2V4JiBvcGVyYXRv
cj0oYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgU1Q+IHApOzwvaW5zPgp0ZW1wbGF0ZSAmbHQ7
Y2xhc3MgU1QsIGNsYXNzIFNBPgogIGJhc2ljX3JlZ2V4JiBvcGVyYXRvcj0oY29uc3QgYmFzaWNf
c3RyaW5nJmx0O2NoYXJULCBTVCwgU0E+JiBwKTs8L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0i
YXR0cmlidXRlIj48aT5FZmZlY3RzPC9pPjogcmV0dXJucyBhc3NpZ24ocCkuPC9wPgoKPHByZT48
Y29kZT48aW5zPnRlbXBsYXRlICZsdDtjbGFzcyBzdHJpbmdfdHJhaXRzPgogIGJhc2ljX3JlZ2V4
JiBhc3NpZ24oYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgc3RyaW5nX3RyYWl0cz4gcywKICAg
ICAgICAgICAgICAgICAgICAgIGZsYWdfdHlwZSBmID0gcmVnZXhfY29uc3RhbnRzOjpFQ01BU2Ny
aXB0KTs8L2lucz4KdGVtcGxhdGUgJmx0O2NsYXNzIHN0cmluZ190cmFpdHMsIGNsYXNzIEE+CiAg
YmFzaWNfcmVnZXgmIGFzc2lnbihjb25zdCBiYXNpY19zdHJpbmcmbHQ7Y2hhclQsIHN0cmluZ190
cmFpdHMsIEE+JiBzLAogICAgICAgICAgICAgICAgICAgICAgZmxhZ190eXBlIGYgPSByZWdleF9j
b25zdGFudHM6OkVDTUFTY3JpcHQpOzwvY29kZT48L3ByZT4KICAgIDxkaXYgY2xhc3M9ImF0dHJp
YnV0ZXMiPgogICAgICA8cD48aT5UaHJvd3M8L2k+OiByZWdleF9lcnJvciBpZiBzIGlzIG5vdCBh
IHZhbGlkIHJlZ3VsYXIgZXhwcmVzc2lvbi48L3A+CiAgICAgIDxwPjxpPlJldHVybnM8L2k+OiAq
dGhpcy48L3A+CiAgICAgIDxwPjxpPkVmZmVjdHM8L2k+OiBBc3NpZ25zIHRoZSByZWd1bGFyIGV4
cHJlc3Npb24gY29udGFpbmVkIGluIHRoZSBzdHJpbmcgcywgaW50ZXJwcmV0ZWQgYWNjb3JkaW5n
IHRoZSBmbGFncyBzcGVjaWZpZWQgaW4gZi4gSWYgYW4gZXhjZXB0aW9uIGlzIHRocm93biwgKnRo
aXMgaXMgdW5jaGFuZ2VkLjwvcD4KICAgICAgPHA+PGk+UG9zdGNvbmRpdGlvbnM8L2k+OiBJZiBu
byBleGNlcHRpb24gaXMgdGhyb3duLCBmbGFncygpIHJldHVybnMgZiBhbmQgbWFya19jb3VudCgp
IHJldHVybnMgdGhlIG51bWJlciBvZiBtYXJrZWQgc3ViLWV4cHJlc3Npb25zIHdpdGhpbiB0aGUg
ZXhwcmVzc2lvbi48L3A+CiAgICA8L2Rpdj4KCgogICAgPGgzPkFkZCB0byBbcmUuc3VibWF0Y2hd
PC9oMz4KICAgIDxwcmU+PGNvZGU+aW50IGNvbXBhcmUoYmFzaWNfc3RyaW5nX3JlZiZsdDt2YWx1
ZV90eXBlPiBzKSBjb25zdDs8L2NvZGU+PC9wcmU+CgoKICAgIDxoMz5BZGQgdG8gW3JlLnN1Ym1h
dGNoLm1lbWJlcnNdPC9oMz4KICAgIDxwcmU+PGNvZGU+aW50IGNvbXBhcmUoYmFzaWNfc3RyaW5n
X3JlZiZsdDt2YWx1ZV90eXBlPiBzKSBjb25zdDs8L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0i
YXR0cmlidXRlIj48aT5SZXR1cm5zPC9pPjogc3RyKCkuY29tcGFyZShzKS48L3A+CgoKICAgIDxo
Mz5BZGQgdG8gW3JlLnN1Ym1hdGNoLm9wXTwvaDM+Cgo8cHJlPjxjb2RlPnRlbXBsYXRlICZsdDtj
bGFzcyBCaUl0ZXIsIGNsYXNzIFNUPgogIGJvb2wgb3BlcmF0b3I9PSgKICAgIGJhc2ljX3N0cmlu
Z19yZWYmbHQ7CiAgICAgIHR5cGVuYW1lIGl0ZXJhdG9yX3RyYWl0cyZsdDtCaUl0ZXI+Ojp2YWx1
ZV90eXBlLCBTVD4gbGhzLAogICAgY29uc3Qgc3ViX21hdGNoJmx0O0JpSXRlcj4mIHJocyk7PC9j
b2RlPjwvcHJlPgogICAgPHAgY2xhc3M9ImF0dHJpYnV0ZXMiPjxpPlJldHVybnM8L2k+OiByaHMu
Y29tcGFyZShiYXNpY19zdHJpbmdfcmVmJmx0O3R5cGVuYW1lIGl0ZXJhdG9yX3RyYWl0cyZsdDtC
aUl0ZXI+Ojp2YWx1ZV90eXBlPihsaHMuZGF0YSgpLCBsaHMuc2l6ZSgpKSkgPT0gMC48L3A+CiAg
ICA8cD5bIEZvb3Rub3RlOiBUaGlzIGFuZCB0aGUgb3RoZXIgY29tcGFyaXNvbiBvcGVyYXRvcnMg
aWdub3JlIHRoZSBiYXNpY19zdHJpbmdfcmVmJ3MgdHJhaXRzLiAtLSBlbmQgZm9vdG5vdGVdPC9w
PgoKPHByZT48Y29kZT50ZW1wbGF0ZSAmbHQ7Y2xhc3MgQmlJdGVyLCBjbGFzcyBTVD4KICBib29s
IG9wZXJhdG9yIT0oCmJhc2ljX3N0cmluZ19yZWYmbHQ7CiAgdHlwZW5hbWUgaXRlcmF0b3JfdHJh
aXRzJmx0O0JpSXRlcj46OnZhbHVlX3R5cGUsIFNUPiBsaHMsCmNvbnN0IHN1Yl9tYXRjaCZsdDtC
aUl0ZXI+JiByaHMpOzwvY29kZT48L3ByZT4KICAgIDxwIGNsYXNzPSJhdHRyaWJ1dGUiPjxpPlJl
dHVybnM8L2k+OiAhKGxocyA9PSByaHMpLjwvcD4KCjxwcmU+PGNvZGU+dGVtcGxhdGUgJmx0O2Ns
YXNzIEJpSXRlciwgY2xhc3MgU1Q+CiAgYm9vbCBvcGVyYXRvciZsdDsoCmJhc2ljX3N0cmluZ19y
ZWYmbHQ7CiAgdHlwZW5hbWUgaXRlcmF0b3JfdHJhaXRzJmx0O0JpSXRlcj46OnZhbHVlX3R5cGUs
IFNUPiBsaHMsCmNvbnN0IHN1Yl9tYXRjaCZsdDtCaUl0ZXI+JiByaHMpOzwvY29kZT48L3ByZT4K
ICAgIDxwIGNsYXNzPSJhdHRyaWJ1dGUiPjxpPlJldHVybnM8L2k+OiByaHMuY29tcGFyZShiYXNp
Y19zdHJpbmdfcmVmJmx0O3R5cGVuYW1lIGl0ZXJhdG9yX3RyYWl0cyZsdDtCaUl0ZXI+Ojp2YWx1
ZV90eXBlPihsaHMuZGF0YSgpLCBsaHMuc2l6ZSgpKSkgPiAwLjwvcD4KCjxwcmU+PGNvZGU+dGVt
cGxhdGUgJmx0O2NsYXNzIEJpSXRlciwgY2xhc3MgU1Q+CiAgYm9vbCBvcGVyYXRvcj4oCmJhc2lj
X3N0cmluZ19yZWYmbHQ7CiAgdHlwZW5hbWUgaXRlcmF0b3JfdHJhaXRzJmx0O0JpSXRlcj46OnZh
bHVlX3R5cGUsIFNUPiBsaHMsCmNvbnN0IHN1Yl9tYXRjaCZsdDtCaUl0ZXI+JiByaHMpOzwvY29k
ZT48L3ByZT4KICAgIDxwIGNsYXNzPSJhdHRyaWJ1dGUiPjxpPlJldHVybnM8L2k+OiByaHMgJmx0
OyBsaHMuPC9wPgoKPHByZT48Y29kZT50ZW1wbGF0ZSAmbHQ7Y2xhc3MgQmlJdGVyLCBjbGFzcyBT
VD4KICBib29sIG9wZXJhdG9yPj0oCmJhc2ljX3N0cmluZ19yZWYmbHQ7CiAgdHlwZW5hbWUgaXRl
cmF0b3JfdHJhaXRzJmx0O0JpSXRlcj46OnZhbHVlX3R5cGUsIFNUPiBsaHMsCmNvbnN0IHN1Yl9t
YXRjaCZsdDtCaUl0ZXI+JiByaHMpOzwvY29kZT48L3ByZT4KICAgIDxwIGNsYXNzPSJhdHRyaWJ1
dGUiPjxpPlJldHVybnM8L2k+OiAhKGxocyAmbHQ7IHJocykuPC9wPgoKPHByZT48Y29kZT50ZW1w
bGF0ZSAmbHQ7Y2xhc3MgQmlJdGVyLCBjbGFzcyBTVD4KICBib29sIG9wZXJhdG9yJmx0Oz0oCmJh
c2ljX3N0cmluZ19yZWYmbHQ7CiAgdHlwZW5hbWUgaXRlcmF0b3JfdHJhaXRzJmx0O0JpSXRlcj46
OnZhbHVlX3R5cGUsIFNUPiBsaHMsCmNvbnN0IHN1Yl9tYXRjaCZsdDtCaUl0ZXI+JiByaHMpOzwv
Y29kZT48L3ByZT4KICAgIDxwIGNsYXNzPSJhdHRyaWJ1dGUiPjxpPlJldHVybnM8L2k+OiAhKHJo
cyAmbHQ7IGxocykuPC9wPgoKPHByZT48Y29kZT50ZW1wbGF0ZSAmbHQ7Y2xhc3MgQmlJdGVyLCBj
bGFzcyBTVD4KICBib29sIG9wZXJhdG9yPT0oY29uc3Qgc3ViX21hdGNoJmx0O0JpSXRlcj4mIGxo
cywKICAgICAgICAgICAgIGJhc2ljX3N0cmluZ19yZWYmbHQ7CiAgICAgICAgICAgICAgIHR5cGVu
YW1lIGl0ZXJhdG9yX3RyYWl0cyZsdDtCaUl0ZXI+Ojp2YWx1ZV90eXBlLCBTVD4gcmhzKTs8L2Nv
ZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0iYXR0cmlidXRlIj48aT5SZXR1cm5zPC9pPjogbGhzLmNv
bXBhcmUoYmFzaWNfc3RyaW5nX3JlZiZsdDt0eXBlbmFtZSBpdGVyYXRvcl90cmFpdHMmbHQ7QmlJ
dGVyPjo6dmFsdWVfdHlwZT4ocmhzLmRhdGEoKSwgcmhzLnNpemUoKSkpID09IDAuPC9wPgoKPHBy
ZT48Y29kZT50ZW1wbGF0ZSAmbHQ7Y2xhc3MgQmlJdGVyLCBjbGFzcyBTVD4KICBib29sIG9wZXJh
dG9yIT0oY29uc3Qgc3ViX21hdGNoJmx0O0JpSXRlcj4mIGxocywKICAgICAgICAgICAgICAgICAg
YmFzaWNfc3RyaW5nX3JlZiZsdDsKICAgICAgICAgICAgICAgICAgICB0eXBlbmFtZSBpdGVyYXRv
cl90cmFpdHMmbHQ7QmlJdGVyPjo6dmFsdWVfdHlwZSwgU1Q+IHJocyk7PC9jb2RlPjwvcHJlPgog
ICAgPHAgY2xhc3M9ImF0dHJpYnV0ZSI+PGk+UmV0dXJuczwvaT46ICEobGhzID09IHJocykuPC9w
PgoKPHByZT48Y29kZT50ZW1wbGF0ZSAmbHQ7Y2xhc3MgQmlJdGVyLCBjbGFzcyBTVD4KICBib29s
IG9wZXJhdG9yJmx0Oyhjb25zdCBzdWJfbWF0Y2gmbHQ7QmlJdGVyPiYgbGhzLAogICAgICAgICAg
ICBiYXNpY19zdHJpbmdfcmVmJmx0OwogICAgICAgICAgICAgIHR5cGVuYW1lIGl0ZXJhdG9yX3Ry
YWl0cyZsdDtCaUl0ZXI+Ojp2YWx1ZV90eXBlLCBTVD4gcmhzKTs8L2NvZGU+PC9wcmU+CiAgICA8
cCBjbGFzcz0iYXR0cmlidXRlIj48aT5SZXR1cm5zPC9pPjogbGhzLmNvbXBhcmUoYmFzaWNfc3Ry
aW5nX3JlZiZsdDt0eXBlbmFtZSBpdGVyYXRvcl90cmFpdHMmbHQ7QmlJdGVyPjo6dmFsdWVfdHlw
ZT4ocmhzLmRhdGEoKSwgcmhzLnNpemUoKSkpICZsdDsgMC48L3A+Cgo8cHJlPjxjb2RlPnRlbXBs
YXRlICZsdDtjbGFzcyBCaUl0ZXIsIGNsYXNzIFNUPgogIGJvb2wgb3BlcmF0b3I+KGNvbnN0IHN1
Yl9tYXRjaCZsdDtCaUl0ZXI+JiBsaHMsCiAgICAgICAgICAgIGJhc2ljX3N0cmluZ19yZWYmbHQ7
CiAgICAgICAgICAgICAgdHlwZW5hbWUgaXRlcmF0b3JfdHJhaXRzJmx0O0JpSXRlcj46OnZhbHVl
X3R5cGUsIFNUPiByaHMpOzwvY29kZT48L3ByZT4KICAgIDxwIGNsYXNzPSJhdHRyaWJ1dGUiPjxp
PlJldHVybnM8L2k+OiByaHMgJmx0OyBsaHMuPC9wPgoKPHByZT48Y29kZT50ZW1wbGF0ZSAmbHQ7
Y2xhc3MgQmlJdGVyLCBjbGFzcyBTVD4KICBib29sIG9wZXJhdG9yPj0oY29uc3Qgc3ViX21hdGNo
Jmx0O0JpSXRlcj4mIGxocywKICAgICAgICAgICAgIGJhc2ljX3N0cmluZ19yZWYmbHQ7CiAgICAg
ICAgICAgICAgIHR5cGVuYW1lIGl0ZXJhdG9yX3RyYWl0cyZsdDtCaUl0ZXI+Ojp2YWx1ZV90eXBl
LCBTVD4gcmhzKTs8L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0iYXR0cmlidXRlIj48aT5SZXR1
cm5zPC9pPjogIShsaHMgJmx0OyByaHMpLjwvcD4KCjxwcmU+PGNvZGU+dGVtcGxhdGUgJmx0O2Ns
YXNzIEJpSXRlciwgY2xhc3MgU1Q+CiAgYm9vbCBvcGVyYXRvciZsdDs9KGNvbnN0IHN1Yl9tYXRj
aCZsdDtCaUl0ZXI+JiBsaHMsCiAgICAgICAgICAgICBiYXNpY19zdHJpbmdfcmVmJmx0OwogICAg
ICAgICAgICAgICB0eXBlbmFtZSBpdGVyYXRvcl90cmFpdHMmbHQ7QmlJdGVyPjo6dmFsdWVfdHlw
ZSwgU1Q+IHJocyk7PC9jb2RlPjwvcHJlPgogICAgPHAgY2xhc3M9ImF0dHJpYnV0ZSI+PGk+UmV0
dXJuczwvaT46ICEocmhzICZsdDsgbGhzKS48L3A+CgoKICAgIDxoMz5BZGQgdG8gdGhlIGFwcHJv
cHJpYXRlIHBsYWNlcyB3aXRoaW4gW3JlLnJlc3VsdHNdPC9oMz4KPHByZT48Y29kZT50ZW1wbGF0
ZSAmbHQ7Y2xhc3MgT3V0cHV0SXRlciwgY2xhc3MgU1Q+CiAgICAgICBPdXRwdXRJdGVyCiAgICAg
ICBmb3JtYXQoT3V0cHV0SXRlciBvdXQsCiAgICAgICAgICAgICAgYmFzaWNfc3RyaW5nX3JlZiZs
dDtjaGFyX3R5cGUsIFNUPiBmbXQsCiAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRj
aF9mbGFnX3R5cGUgZmxhZ3MgPQogICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjpmb3Jt
YXRfZGVmYXVsdCkgY29uc3Q7CnRlbXBsYXRlICZsdDtjbGFzcyBTVD4KICAgICAgYmFzaWNfc3Ry
aW5nJmx0O2NoYXJfdHlwZSwgU1Q+CiAgICAgIGZvcm1hdChiYXNpY19zdHJpbmdfcmVmJmx0O2No
YXJfdHlwZSwgU1Q+IGZtdCwKICAgICAgICAgICAgIHJlZ2V4X2NvbnN0YW50czo6bWF0Y2hfZmxh
Z190eXBlIGZsYWdzID0KICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjpmb3JtYXRfZGVm
YXVsdCkgY29uc3Q7PC9jb2RlPjwvcHJlPgoKCiAgICA8aDM+TW9kaWZ5IFtyZS5yZXN1bHRzLmZv
cm1dPC9oMz4KPHByZT48Y29kZT48aW5zPnRlbXBsYXRlICZsdDtjbGFzcyBPdXRwdXRJdGVyLCBj
bGFzcyBTVD4KICBPdXRwdXRJdGVyIGZvcm1hdChPdXRwdXRJdGVyIG91dCwKICAgICAgICAgICAg
ICAgICAgICBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJfdHlwZSwgU1Q+IGZtdCwKICAgICAgICAg
ICAgICAgICAgICByZWdleF9jb25zdGFudHM6Om1hdGNoX2ZsYWdfdHlwZSBmbGFncyA9CiAgICAg
ICAgICAgICAgICAgICAgICByZWdleF9jb25zdGFudHM6OmZvcm1hdF9kZWZhdWx0KSBjb25zdDs8
L2lucz4KdGVtcGxhdGUgJmx0O2NsYXNzIE91dHB1dEl0ZXIsIGNsYXNzIFNULCBjbGFzcyBTQT4K
ICBPdXRwdXRJdGVyIGZvcm1hdChPdXRwdXRJdGVyIG91dCwKICAgICAgICAgICAgICAgICAgICBj
b25zdCBiYXNpY19zdHJpbmcmbHQ7Y2hhcl90eXBlLCBTVCwgU0E+JiBmbXQsCiAgICAgICAgICAg
ICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9mbGFnX3R5cGUgZmxhZ3MgPQogICAgICAg
ICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjpmb3JtYXRfZGVmYXVsdCkgY29uc3Q7PC9j
b2RlPjwvcHJlPgogICAgPHAgY2xhc3M9ImF0dHJpYnV0ZSI+PGk+RWZmZWN0czwvaT46IEVxdWl2
YWxlbnQgdG8gPGNvZGU+cmV0dXJuIGZvcm1hdCg8d2JyLz5vdXQsPHdici8+IGZtdC5kYXRhKCks
PHdici8+IGZtdC5kYXRhKCkgKyBmbXQuc2l6ZSgpLDx3YnIvPiBmbGFncyk8L2NvZGU+LjwvcD4K
CjxwcmU+PGNvZGU+PGlucz50ZW1wbGF0ZSAmbHQ7Y2xhc3MgU1Q+CiAgYmFzaWNfc3RyaW5nJmx0
O2NoYXJfdHlwZSwgU1Q+CiAgZm9ybWF0KGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhcl90eXBlLCBT
VD4mIGZtdCwKICAgIHJlZ2V4X2NvbnN0YW50czo6bWF0Y2hfZmxhZ190eXBlIGZsYWdzID0KICAg
ICAgcmVnZXhfY29uc3RhbnRzOjpmb3JtYXRfZGVmYXVsdCkgY29uc3Q7PC9pbnM+PC9jb2RlPjwv
cHJlPgogICAgPGRpdiBjbGFzcz0iYXR0cmlidXRlcyI+CiAgICAgIDxwPjxpbnM+PGk+UmVxdWly
ZXM8L2k+OiA8Y29kZT5yZWFkeSgpID09IHRydWU8L2NvZGU+LjwvaW5zPjwvcD4KICAgICAgPHA+
PGlucz48aT5FZmZlY3RzPC9pPjogQ29uc3RydWN0cyBhbiBlbXB0eSBzdHJpbmcgPGNvZGU+cmVz
dWx0PC9jb2RlPiBvZgogICAgICB0eXBlIDxjb2RlPmJhc2ljX3N0cmluZyZsdDtjaGFyX3R5cGUs
IFNUPjwvY29kZT4gYW5kIGNhbGxzCiAgICAgIDxjb2RlPmZvcm1hdChiYWNrX2luc2VydGVyKHJl
c3VsdCksIGZtdCwgZmxhZ3MpPC9jb2RlPi48L2lucz48L3A+CiAgICAgIDxwPjxpbnM+PGk+UmV0
dXJuczwvaT46IDxjb2RlPnJlc3VsdDwvY29kZT4uPC9pbnM+PC9wPgogICAgPC9kaXY+CgoKICAg
IDxoMz5Nb2RpZnkgW3JlLmFsZy5tYXRjaF08L2gzPgo8cHJlPjxjb2RlPjxpbnM+dGVtcGxhdGUg
Jmx0O2NsYXNzIFNULCBjbGFzcyBBbGxvY2F0b3IsIGNsYXNzIGNoYXJULCBjbGFzcyB0cmFpdHM+
CiAgYm9vbCByZWdleF9tYXRjaChiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCBTVD4gcywKICAg
ICAgICAgICAgICAgICAgIG1hdGNoX3Jlc3VsdHMmbHQ7CiAgICAgICAgICAgICAgICAgICAgIHR5
cGVuYW1lIGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIFNUPjo6Y29uc3RfaXRlcmF0b3IsCiAg
ICAgICAgICAgICAgICAgICAgIEFsbG9jYXRvcj4mIG0sCiAgICAgICAgICAgICAgICAgICBjb25z
dCBiYXNpY19yZWdleCZsdDtjaGFyVCwgdHJhaXRzPiYgZSwKICAgICAgICAgICAgICAgICAgIHJl
Z2V4X2NvbnN0YW50czo6bWF0Y2hfZmxhZ190eXBlIGZsYWdzID0KICAgICAgICAgICAgICAgICAg
ICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9kZWZhdWx0KTs8L2lucz4KdGVtcGxhdGUgJmx0O2Ns
YXNzIFNULCBjbGFzcyBTQSwgY2xhc3MgQWxsb2NhdG9yLCBjbGFzcyBjaGFyVCwgY2xhc3MgdHJh
aXRzPgogIGJvb2wgcmVnZXhfbWF0Y2goY29uc3QgYmFzaWNfc3RyaW5nJmx0O2NoYXJULCBTVCwg
U0E+JiBzLAogICAgICAgICAgICAgICAgICAgbWF0Y2hfcmVzdWx0cyZsdDsKICAgICAgICAgICAg
ICAgICAgICAgdHlwZW5hbWUgYmFzaWNfc3RyaW5nJmx0O2NoYXJULCBTVCwgU0E+Ojpjb25zdF9p
dGVyYXRvciwKICAgICAgICAgICAgICAgICAgICAgQWxsb2NhdG9yPiYgbSwKICAgICAgICAgICAg
ICAgICAgIGNvbnN0IGJhc2ljX3JlZ2V4Jmx0O2NoYXJULCB0cmFpdHM+JiBlLAogICAgICAgICAg
ICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9mbGFnX3R5cGUgZmxhZ3MgPQogICAgICAg
ICAgICAgICAgICAgICByZWdleF9jb25zdGFudHM6Om1hdGNoX2RlZmF1bHQpOzwvY29kZT48L3By
ZT4KICAgIDxwIGNsYXNzPSJhdHRyaWJ1dGUiPjxpPlJldHVybnM8L2k+OiByZWdleF9tYXRjaChz
LmJlZ2luKCksIHMuZW5kKCksIG0sIGUsIGZsYWdzKS48L3A+CgoKPHByZT48Y29kZT48aW5zPnRl
bXBsYXRlICZsdDtjbGFzcyBTVCwgY2xhc3MgY2hhclQsIGNsYXNzIHRyYWl0cz4KICBib29sIHJl
Z2V4X21hdGNoKGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIFNUPiBzLAogICAgICAgICAgICAg
ICAgICAgY29uc3QgYmFzaWNfcmVnZXgmbHQ7Y2hhclQsIHRyYWl0cz4mIGUsCiAgICAgICAgICAg
ICAgICAgICByZWdleF9jb25zdGFudHM6Om1hdGNoX2ZsYWdfdHlwZSBmbGFncyA9CiAgICAgICAg
ICAgICAgICAgICAgIHJlZ2V4X2NvbnN0YW50czo6bWF0Y2hfZGVmYXVsdCk7PC9pbnM+CnRlbXBs
YXRlICZsdDtjbGFzcyBTVCwgY2xhc3MgU0EsIGNsYXNzIGNoYXJULCBjbGFzcyB0cmFpdHM+CiAg
Ym9vbCByZWdleF9tYXRjaChjb25zdCBiYXNpY19zdHJpbmcmbHQ7Y2hhclQsIFNULCBTQT4mIHMs
CiAgICAgICAgICAgICAgICAgICBjb25zdCBiYXNpY19yZWdleCZsdDtjaGFyVCwgdHJhaXRzPiYg
ZSwKICAgICAgICAgICAgICAgICAgIHJlZ2V4X2NvbnN0YW50czo6bWF0Y2hfZmxhZ190eXBlIGZs
YWdzID0KICAgICAgICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9kZWZhdWx0
KTs8L2NvZGU+PC9wcmU+CgogICAgPHAgY2xhc3M9ImF0dHJpYnV0ZSI+PGk+UmV0dXJuczwvaT46
IHJlZ2V4X21hdGNoKHMuYmVnaW4oKSwgcy5lbmQoKSwgZSwgZmxhZ3MpLjwvcD4KCiAgICA8aDM+
TW9kaWZ5IFtyZS5hbGcuc2VhcmNoXTwvaDM+CjxwcmU+PGNvZGU+PGlucz50ZW1wbGF0ZSAmbHQ7
Y2xhc3MgU1QsIGNsYXNzIEFsbG9jYXRvciwgY2xhc3MgY2hhclQsIGNsYXNzIHRyYWl0cz4KICBi
b29sIHJlZ2V4X3NlYXJjaChiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCBTVD4gcywKICAgICAg
ICAgICAgICAgICAgICBtYXRjaF9yZXN1bHRzJmx0OwogICAgICAgICAgICAgICAgICAgICAgdHlw
ZW5hbWUgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgU1Q+Ojpjb25zdF9pdGVyYXRvciwKICAg
ICAgICAgICAgICAgICAgICAgIEFsbG9jYXRvcj4mIG0sCiAgICAgICAgICAgICAgICAgICAgY29u
c3QgYmFzaWNfcmVnZXgmbHQ7Y2hhclQsIHRyYWl0cz4mIGUsCiAgICAgICAgICAgICAgICAgICAg
cmVnZXhfY29uc3RhbnRzOjptYXRjaF9mbGFnX3R5cGUgZmxhZ3MgPQogICAgICAgICAgICAgICAg
ICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9kZWZhdWx0KTs8L2lucz4KdGVtcGxhdGUgJmx0
O2NsYXNzIFNULCBjbGFzcyBTQSwgY2xhc3MgQWxsb2NhdG9yLCBjbGFzcyBjaGFyVCwgY2xhc3Mg
dHJhaXRzPgogIGJvb2wgcmVnZXhfc2VhcmNoKGNvbnN0IGJhc2ljX3N0cmluZyZsdDtjaGFyVCwg
U1QsIFNBPiYgcywKICAgICAgICAgICAgICAgICAgICBtYXRjaF9yZXN1bHRzJmx0OwogICAgICAg
ICAgICAgICAgICAgICAgdHlwZW5hbWUgYmFzaWNfc3RyaW5nJmx0O2NoYXJULCBTVCwgU0E+Ojpj
b25zdF9pdGVyYXRvciwKICAgICAgICAgICAgICAgICAgICAgIEFsbG9jYXRvcj4mIG0sCiAgICAg
ICAgICAgICAgICAgICAgY29uc3QgYmFzaWNfcmVnZXgmbHQ7Y2hhclQsIHRyYWl0cz4mIGUsCiAg
ICAgICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9mbGFnX3R5cGUgZmxhZ3Mg
PQogICAgICAgICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9kZWZhdWx0KTs8
L2NvZGU+PC9wcmU+CiAgICA8cCBjbGFzcz0iYXR0cmlidXRlIj48aT5SZXR1cm5zPC9pPjogVGhl
IHJlc3VsdCBvZiA8Y29kZT5yZWdleF9zZWFyY2gocy5iZWdpbigpLCBzLmVuZCgpLCBtLCBlLCBm
bGFncyk8L2NvZGU+LjwvcD4KCjxwcmU+PGNvZGU+PGlucz50ZW1wbGF0ZSAmbHQ7Y2xhc3MgU1Qs
IGNsYXNzIFNBLCBjbGFzcyBjaGFyVCwgY2xhc3MgdHJhaXRzPgogIGJvb2wgcmVnZXhfc2VhcmNo
KGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIFNUPiYgcywKICAgICAgICAgICAgICAgICAgICBj
b25zdCBiYXNpY19yZWdleCZsdDtjaGFyVCwgdHJhaXRzPiYgZSwKICAgICAgICAgICAgICAgICAg
ICByZWdleF9jb25zdGFudHM6Om1hdGNoX2ZsYWdfdHlwZSBmbGFncyA9CiAgICAgICAgICAgICAg
ICAgICAgICByZWdleF9jb25zdGFudHM6Om1hdGNoX2RlZmF1bHQpOzwvaW5zPgp0ZW1wbGF0ZSAm
bHQ7Y2xhc3MgU1QsIGNsYXNzIFNBLCBjbGFzcyBjaGFyVCwgY2xhc3MgdHJhaXRzPgogIGJvb2wg
cmVnZXhfc2VhcmNoKGNvbnN0IGJhc2ljX3N0cmluZyZsdDtjaGFyVCwgU1QsIFNBPiYgcywKICAg
ICAgICAgICAgICAgICAgICBjb25zdCBiYXNpY19yZWdleCZsdDtjaGFyVCwgdHJhaXRzPiYgZSwK
ICAgICAgICAgICAgICAgICAgICByZWdleF9jb25zdGFudHM6Om1hdGNoX2ZsYWdfdHlwZSBmbGFn
cyA9CiAgICAgICAgICAgICAgICAgICAgICByZWdleF9jb25zdGFudHM6Om1hdGNoX2RlZmF1bHQp
OzwvY29kZT48L3ByZT4KICAgIDxwIGNsYXNzPSJhdHRyaWJ1dGUiPjxpPlJldHVybnM8L2k+OiA8
Y29kZT5yZWdleF9zZWFyY2gocy5iZWdpbigpLCBzLmVuZCgpLCBlLCBmbGFncyk8L2NvZGU+Ljwv
cD4KCiAgICA8aDM+TW9kaWZ5IFtyZS5hbGcucmVwbGFjZV08L2gzPgo8cHJlPjxjb2RlPnRlbXBs
YXRlICZsdDtjbGFzcyBPdXRwdXRJdGVyYXRvciwgY2xhc3MgQmlkaXJlY3Rpb25hbEl0ZXJhdG9y
LAogICAgY2xhc3MgdHJhaXRzLCBjbGFzcyBjaGFyVCwgY2xhc3MgU1QsIGNsYXNzIFNBPgogIE91
dHB1dEl0ZXJhdG9yCiAgcmVnZXhfcmVwbGFjZShPdXRwdXRJdGVyYXRvciBvdXQsCiAgICAgICAg
ICAgICAgICBCaWRpcmVjdGlvbmFsSXRlcmF0b3IgZmlyc3QsIEJpZGlyZWN0aW9uYWxJdGVyYXRv
ciBsYXN0LAogICAgICAgICAgICAgICAgY29uc3QgYmFzaWNfcmVnZXgmbHQ7Y2hhclQsIHRyYWl0
cz4mIGUsCiAgICAgICAgICAgICAgICBjb25zdCBiYXNpY19zdHJpbmcmbHQ7Y2hhclQsIFNULCBT
QT4mIGZtdCwKICAgICAgICAgICAgICAgIHJlZ2V4X2NvbnN0YW50czo6bWF0Y2hfZmxhZ190eXBl
IGZsYWdzID0KICAgICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9kZWZhdWx0
KTsKPGlucz50ZW1wbGF0ZSAmbHQ7Y2xhc3MgT3V0cHV0SXRlcmF0b3IsIGNsYXNzIEJpZGlyZWN0
aW9uYWxJdGVyYXRvciwKICAgIGNsYXNzIHRyYWl0cywgY2xhc3MgY2hhclQsIGNsYXNzIFNUPgog
IE91dHB1dEl0ZXJhdG9yCiAgcmVnZXhfcmVwbGFjZShPdXRwdXRJdGVyYXRvciBvdXQsCiAgICAg
ICAgICAgICAgICBCaWRpcmVjdGlvbmFsSXRlcmF0b3IgZmlyc3QsIEJpZGlyZWN0aW9uYWxJdGVy
YXRvciBsYXN0LAogICAgICAgICAgICAgICAgY29uc3QgYmFzaWNfcmVnZXgmbHQ7Y2hhclQsIHRy
YWl0cz4mIGUsCiAgICAgICAgICAgICAgICBiYXNpY19zdHJpbmdfcmVmJmx0O2NoYXJULCBTVD4g
Zm10LAogICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9mbGFnX3R5cGUgZmxh
Z3MgPQogICAgICAgICAgICAgICAgICByZWdleF9jb25zdGFudHM6Om1hdGNoX2RlZmF1bHQpOzwv
aW5zPgp0ZW1wbGF0ZSAmbHQ7Y2xhc3MgT3V0cHV0SXRlcmF0b3IsIGNsYXNzIEJpZGlyZWN0aW9u
YWxJdGVyYXRvciwKICAgIGNsYXNzIHRyYWl0cywgY2xhc3MgY2hhclQ+CiAgT3V0cHV0SXRlcmF0
b3IKICByZWdleF9yZXBsYWNlKE91dHB1dEl0ZXJhdG9yIG91dCwKICAgICAgICAgICAgICAgIEJp
ZGlyZWN0aW9uYWxJdGVyYXRvciBmaXJzdCwgQmlkaXJlY3Rpb25hbEl0ZXJhdG9yIGxhc3QsCiAg
ICAgICAgICAgICAgICBjb25zdCBiYXNpY19yZWdleCZsdDtjaGFyVCwgdHJhaXRzPiYgZSwKICAg
ICAgICAgICAgICAgIGNvbnN0IGNoYXJUKiBmbXQsCiAgICAgICAgICAgICAgICByZWdleF9jb25z
dGFudHM6Om1hdGNoX2ZsYWdfdHlwZSBmbGFncyA9CiAgICAgICAgICAgICAgICAgIHJlZ2V4X2Nv
bnN0YW50czo6bWF0Y2hfZGVmYXVsdCk7PC9jb2RlPjwvcHJlPgogICAgPGRpdiBjbGFzcz0iYXR0
cmlidXRlcyI+CiAgICAgIDxwPjxpPkVmZmVjdHM8L2k+OiBDb25zdHJ1Y3RzIGEgcmVnZXhfaXRl
cmF0b3Igb2JqZWN0IGkgYXMgaWYgYnkgcmVnZXhfaXRlcmF0b3ImbHQ7QmlkaXJlY3Rpb25hbEl0
ZXJhdG9yLCBjaGFyVCwgdHJhaXRzPiBpKGZpcnN0LCBsYXN0LCBlLCBmbGFncyksIGFuZCB1c2Vz
IGkgdG8gZW51bWVyYXRlIHRocm91Z2ggYWxsIG9mIHRoZSBtYXRjaGVzIG0gb2YgdHlwZSBtYXRj
aF9yZXN1bHRzJmx0O0JpZGlyZWN0aW9uYWxJdGVyYXRvcj4gdGhhdCBvY2N1ciB3aXRoaW4gdGhl
IHNlcXVlbmNlIFtmaXJzdCxsYXN0ICkuIElmIG5vIHN1Y2ggbWF0Y2hlcyBhcmUgZm91bmQgYW5k
ICEoZmxhZ3MgJiByZWdleF9jb25zdGFudHMgOjpmb3JtYXRfbm9fY29weSkgdGhlbiBjYWxscyBz
dGQ6OmNvcHkoZmlyc3QsIGxhc3QsIG91dCkuIElmIGFueSBtYXRjaGVzIGFyZSBmb3VuZCB0aGVu
LCBmb3IgZWFjaCBzdWNoIG1hdGNoLCBpZiAhKGZsYWdzICYgcmVnZXhfY29uc3RhbnRzOjpmb3Jt
YXRfbm9fY29weSksIGNhbGxzIHN0ZDo6Y29weShtLnByZWZpeCgpLmZpcnN0LCBtLnByZWZpeCgp
LnNlY29uZCwgb3V0KSwgYW5kIHRoZW4gY2FsbHMgbS5mb3JtYXQob3V0LCBmbXQsIGZsYWdzKSBm
b3IgdGhlIGZpcnN0IDxkZWw+Zm9ybSA8L2RlbD48aW5zPmFuZCBzZWNvbmQgZm9ybXMgPC9pbnM+
b2YgdGhlIGZ1bmN0aW9uIGFuZCBtLmZvcm1hdChvdXQsIGZtdCwgZm10ICsgY2hhcl90cmFpdHMm
bHQ7Y2hhclQ+OjpsZW5ndGgoZm10KSwgZmxhZ3MpIGZvciB0aGUgPGRlbD4gc2Vjb25kPC9kZWw+
PGlucz4gdGhpcmQ8L2lucz4uIEZpbmFsbHksIGlmIHN1Y2ggYSBtYXRjaCBpcyBmb3VuZCBhbmQg
IShmbGFncyAmIHJlZ2V4X2NvbnN0YW50cyA6OmZvcm1hdF9ub19jb3B5KSwgY2FsbHMgc3RkOjog
Y29weShsYXN0X20uc3VmZml4KCkuZmlyc3QsIGxhc3RfbS5zdWZmaXgoKS5zZWNvbmQsIG91dCkg
d2hlcmUgbGFzdF9tIGlzIGEgY29weSBvZiB0aGUgbGFzdCBtYXRjaCBmb3VuZC4gSWYgZmxhZ3Mg
JiByZWdleF9jb25zdGFudHM6OmZvcm1hdF9maXJzdF9vbmx5IGlzIG5vbi16ZXJvIHRoZW4gb25s
eSB0aGUgZmlyc3QgbWF0Y2ggZm91bmQgaXMgcmVwbGFjZWQuPC9wPgogICAgICA8cD48aT5SZXR1
cm5zPC9pPjogb3V0LjwvcD4KICAgIDwvZGl2PgoKPHByZT48Y29kZT48aW5zPnRlbXBsYXRlICZs
dDtjbGFzcyB0cmFpdHMsIGNsYXNzIGNoYXJULCBjbGFzcyBTVCwgY2xhc3MgRlNULCBjbGFzcyBG
U0E+CiAgYmFzaWNfc3RyaW5nJmx0O2NoYXJULCBTVD4KICByZWdleF9yZXBsYWNlKGJhc2ljX3N0
cmluZ19yZWYmbHQ7Y2hhclQsIFNUPiBzLAogICAgICAgICAgICAgICAgY29uc3QgYmFzaWNfcmVn
ZXgmbHQ7Y2hhclQsIHRyYWl0cz4mIGUsCiAgICAgICAgICAgICAgICBjb25zdCBiYXNpY19zdHJp
bmcmbHQ7Y2hhclQsIEZTVCwgRlNBPiYgZm10LAogICAgICAgICAgICAgICAgcmVnZXhfY29uc3Rh
bnRzOjptYXRjaF9mbGFnX3R5cGUgZmxhZ3MgPQogICAgICAgICAgICAgICAgICByZWdleF9jb25z
dGFudHM6Om1hdGNoX2RlZmF1bHQpOwp0ZW1wbGF0ZSAmbHQ7Y2xhc3MgdHJhaXRzLCBjbGFzcyBj
aGFyVCwgY2xhc3MgU1QsIGNsYXNzIEZTVD4KICBiYXNpY19zdHJpbmcmbHQ7Y2hhclQsIFNUPgog
IHJlZ2V4X3JlcGxhY2UoYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwgU1Q+IHMsCiAgICAgICAg
ICAgICAgICBjb25zdCBiYXNpY19yZWdleCZsdDtjaGFyVCwgdHJhaXRzPiYgZSwKICAgICAgICAg
ICAgICAgIGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIEZTVD4gZm10LAogICAgICAgICAgICAg
ICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9mbGFnX3R5cGUgZmxhZ3MgPQogICAgICAgICAgICAg
ICAgICByZWdleF9jb25zdGFudHM6Om1hdGNoX2RlZmF1bHQpOwp0ZW1wbGF0ZSAmbHQ7Y2xhc3Mg
dHJhaXRzLCBjbGFzcyBjaGFyVCwgY2xhc3MgU1Q+CiAgYmFzaWNfc3RyaW5nJmx0O2NoYXJULCBT
VD4KICByZWdleF9yZXBsYWNlKGJhc2ljX3N0cmluZ19yZWYmbHQ7Y2hhclQsIFNUPiBzLAogIGNv
bnN0IGJhc2ljX3JlZ2V4Jmx0O2NoYXJULCB0cmFpdHM+JiBlLAogICAgICAgICAgICAgICAgY29u
c3QgY2hhclQqIGZtdCwKICAgICAgICAgICAgICAgIHJlZ2V4X2NvbnN0YW50czo6bWF0Y2hfZmxh
Z190eXBlIGZsYWdzID0KICAgICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9k
ZWZhdWx0KTs8L2lucz48L2NvZGU+PC9wcmU+CiAgICA8ZGl2IGNsYXNzPSJhdHRyaWJ1dGVzIj4K
ICAgICAgPHA+PGlucz48aT5FZmZlY3RzPC9pPjogQ29uc3RydWN0cyBhbiBlbXB0eSBzdHJpbmcg
cmVzdWx0IG9mIHR5cGUgYmFzaWNfc3RyaW5nJmx0O2NoYXJULCBTVD4gYW5kIGNhbGxzIHJlZ2V4
X3JlcGxhY2UoYmFja19pbnNlcnRlcihyZXN1bHQpLCBzLmJlZ2luKCksIHMuZW5kKCksIGUsIGZt
dCwgZmxhZ3MpLjwvaW5zPjwvcD4KICAgICAgPHA+PGlucz48aT5SZXR1cm5zPC9pPjogcmVzdWx0
LjwvaW5zPjwvcD4KICAgIDwvZGl2PgoKPHByZT48Y29kZT50ZW1wbGF0ZSAmbHQ7Y2xhc3MgdHJh
aXRzLCBjbGFzcyBjaGFyVCwgY2xhc3MgU1QsIGNsYXNzIFNBLCBjbGFzcyBGU1QsIGNsYXNzIEZT
QT4KICBiYXNpY19zdHJpbmcmbHQ7Y2hhclQsIFNULCBTQT4KICByZWdleF9yZXBsYWNlKGNvbnN0
IGJhc2ljX3N0cmluZyZsdDtjaGFyVCwgU1QsIFNBPiYgcywKICAgICAgICAgICAgICAgIGNvbnN0
IGJhc2ljX3JlZ2V4Jmx0O2NoYXJULCB0cmFpdHM+JiBlLAogICAgICAgICAgICAgICAgY29uc3Qg
YmFzaWNfc3RyaW5nJmx0O2NoYXJULCBGU1QsIEZTQT4mIGZtdCwKICAgICAgICAgICAgICAgIHJl
Z2V4X2NvbnN0YW50czo6bWF0Y2hfZmxhZ190eXBlIGZsYWdzID0KICAgICAgICAgICAgICAgICAg
cmVnZXhfY29uc3RhbnRzOjptYXRjaF9kZWZhdWx0KTsKPGlucz50ZW1wbGF0ZSAmbHQ7Y2xhc3Mg
dHJhaXRzLCBjbGFzcyBjaGFyVCwgY2xhc3MgU1QsIGNsYXNzIFNBLCBjbGFzcyBGU1Q+CiAgYmFz
aWNfc3RyaW5nJmx0O2NoYXJULCBTVCwgU0E+CiAgcmVnZXhfcmVwbGFjZShjb25zdCBiYXNpY19z
dHJpbmcmbHQ7Y2hhclQsIFNULCBTQT4mIHMsCiAgICAgICAgICAgICAgICBjb25zdCBiYXNpY19y
ZWdleCZsdDtjaGFyVCwgdHJhaXRzPiYgZSwKICAgICAgICAgICAgICAgIGJhc2ljX3N0cmluZ19y
ZWYmbHQ7Y2hhclQsIEZTVD4gZm10LAogICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjpt
YXRjaF9mbGFnX3R5cGUgZmxhZ3MgPQogICAgICAgICAgICAgICAgICByZWdleF9jb25zdGFudHM6
Om1hdGNoX2RlZmF1bHQpOzwvaW5zPgp0ZW1wbGF0ZSAmbHQ7Y2xhc3MgdHJhaXRzLCBjbGFzcyBj
aGFyVCwgY2xhc3MgU1QsIGNsYXNzIFNBPgpiYXNpY19zdHJpbmcmbHQ7Y2hhclQsIFNULCBTQT4K
cmVnZXhfcmVwbGFjZShjb25zdCBiYXNpY19zdHJpbmcmbHQ7Y2hhclQsIFNULCBTQT4mIHMsCiAg
ICAgICAgICAgICAgY29uc3QgYmFzaWNfcmVnZXgmbHQ7Y2hhclQsIHRyYWl0cz4mIGUsCiAgICAg
ICAgICAgICAgY29uc3QgY2hhclQqIGZtdCwKICAgICAgICAgICAgICByZWdleF9jb25zdGFudHM6
Om1hdGNoX2ZsYWdfdHlwZSBmbGFncyA9CiAgICAgICAgICAgICAgICByZWdleF9jb25zdGFudHM6
Om1hdGNoX2RlZmF1bHQpOzwvY29kZT48L3ByZT4KICAgIDxkaXYgY2xhc3M9ImF0dHJpYnV0ZXMi
PgogICAgICA8cD48aT5FZmZlY3RzPC9pPjogQ29uc3RydWN0cyBhbiBlbXB0eSBzdHJpbmcgcmVz
dWx0IG9mIHR5cGUgYmFzaWNfc3RyaW5nJmx0O2NoYXJULCBTVCwgU0E+IGFuZCBjYWxscyByZWdl
eF9yZXBsYWNlKGJhY2tfaW5zZXJ0ZXIocmVzdWx0KSwgcy5iZWdpbigpLCBzLmVuZCgpLCBlLCBm
bXQsIGZsYWdzKS48L3A+CiAgICAgIDxwPjxpPlJldHVybnM8L2k+OiByZXN1bHQuPC9wPgogICAg
PC9kaXY+Cgo8cHJlPjxjb2RlPnRlbXBsYXRlICZsdDtjbGFzcyB0cmFpdHMsIGNsYXNzIGNoYXJU
LCBjbGFzcyBTVCwgY2xhc3MgU0E+CiAgYmFzaWNfc3RyaW5nJmx0O2NoYXJUPgogIHJlZ2V4X3Jl
cGxhY2UoY29uc3QgY2hhclQqIHMsCiAgICAgICAgICAgICAgICBjb25zdCBiYXNpY19yZWdleCZs
dDtjaGFyVCwgdHJhaXRzPiYgZSwKICAgICAgICAgICAgICAgIGNvbnN0IGJhc2ljX3N0cmluZyZs
dDtjaGFyVCwgU1QsIFNBPiYgZm10LAogICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjpt
YXRjaF9mbGFnX3R5cGUgZmxhZ3MgPQogICAgICAgICAgICAgICAgICByZWdleF9jb25zdGFudHM6
Om1hdGNoX2RlZmF1bHQpOwo8aW5zPnRlbXBsYXRlICZsdDtjbGFzcyB0cmFpdHMsIGNsYXNzIGNo
YXJULCBjbGFzcyBTVD4KICBiYXNpY19zdHJpbmcmbHQ7Y2hhclQ+CiAgcmVnZXhfcmVwbGFjZShj
b25zdCBjaGFyVCogcywKICAgICAgICAgICAgICAgIGNvbnN0IGJhc2ljX3JlZ2V4Jmx0O2NoYXJU
LCB0cmFpdHM+JiBlLAogICAgICAgICAgICAgICAgYmFzaWNfc3RyaW5nX3JlZiZsdDtjaGFyVCwg
U1Q+IGZtdCwKICAgICAgICAgICAgICAgICAgIHJlZ2V4X2NvbnN0YW50czo6bWF0Y2hfZmxhZ190
eXBlIGZsYWdzID0KICAgICAgICAgICAgICAgICAgICAgcmVnZXhfY29uc3RhbnRzOjptYXRjaF9k
ZWZhdWx0KTs8L2lucz4KdGVtcGxhdGUgJmx0O2NsYXNzIHRyYWl0cywgY2xhc3MgY2hhclQ+CiAg
YmFzaWNfc3RyaW5nJmx0O2NoYXJUPgogIHJlZ2V4X3JlcGxhY2UoY29uc3QgY2hhclQqIHMsCiAg
ICAgICAgICAgICAgICBjb25zdCBiYXNpY19yZWdleCZsdDtjaGFyVCwgdHJhaXRzPiYgZSwKICAg
ICAgICAgICAgICAgIGNvbnN0IGNoYXJUKiBmbXQsCiAgICAgICAgICAgICAgICByZWdleF9jb25z
dGFudHM6Om1hdGNoX2ZsYWdfdHlwZSBmbGFncyA9CiAgICAgICAgICAgICAgICAgIHJlZ2V4X2Nv
bnN0YW50czo6bWF0Y2hfZGVmYXVsdCk7PC9jb2RlPjwvcHJlPgogICAgPGRpdiBjbGFzcz0iYXR0
cmlidXRlcyI+CiAgICAgIDxwPjxpPkVmZmVjdHM8L2k+OiBDb25zdHJ1Y3RzIGFuIGVtcHR5IHN0
cmluZyByZXN1bHQgb2YgdHlwZSBiYXNpY19zdHJpbmcmbHQ7Y2hhclQ+IGFuZCBjYWxscyByZWdl
eF9yZXBsYWNlKCBiYWNrX2luc2VydGVyKHJlc3VsdCksIHMsIHMgKyBjaGFyX3RyYWl0cyZsdDtj
aGFyVD46Omxlbmd0aChzKSwgZSwgZm10LCBmbGFncykuPC9wPgogICAgICA8cD48aT5SZXR1cm5z
PC9pPjogcmVzdWx0LjwvcD4KICAgIDwvZGl2PgogIDwvc2VjdGlvbj4KCiAgPHNlY3Rpb24+CiAg
ICA8aDIgaWQ9ImFja25vd2xlZGdlbWVudHMiPkFja25vd2xlZGdlbWVudHM8L2gyPgoKICAgIDxw
PkknZCBsaWtlIHRvIHRoYW5rIENoYW5kbGVyIENhcnJ1dGgsIE1hcnNoYWxsIENsb3csIHRoZSBC
b29zdCBhbmQKICAgIHN0ZC1wcm9wb3NhbHMgbWFpbGluZyBsaXN0cywgQmVtYW4gRGF3ZXMsIERh
bmllbCBLcsO8Z2xlciwgYW5kIEFsaXNkYWlyCiAgICBNZXJlZGl0aCBmb3IgaGVscCwgYWR2aWNl
LCBhbmQgd29yZGluZyBpbiB0aGlzIHBhcGVyLjwvcD4KICA8L3NlY3Rpb24+CjwvYm9keT4KPC9o
dG1sPgo=
--e89a8fb1f846aae6ea04d1ca048c--

.

Hi,

> An alternate way to get compile-time string_refs would be to define a use=
r-defined literal operator a'la N3468. Arguably, basic_string_ref is a bett=
er candidate for the ""s suffix thanbasic_string since basic_string isn't a=
 literal type.

as author of N3468 I can understand your wish to have a constexpr literal s=
uffix operator for string_ref, however, I propose that you do not insist on=
 operator"" s() to only be useful to create basic_string_ref.

it is a matter of teachability (string_ref will be "new") and also of the n=
eed that you actually may want a std::string variable when doing:=20

auto hi=3D"hello"s;
hi.append(", world!"s);

which is one of my major reasons for contributing operator"" s().

We have two options:

provide

constexpr std::string_ref operator"" s(char const *, size_t);

in a separate namespace std::literals::string_ref, which makes mixing std::=
string operator"" s(char const *, size_t) in the same scope impossible, or =
chose a different name for the suffix, e.g., sr:

constexpr std::string_ref operator"" sr(char const *, size_t);

or, if that seems to much to type,=20

constexpr std::string_ref operator"" r(char const *, size_t);

Otherwise, keep on with the good work.

Regards
Peter.

On 27.12.2012, at 00:44, Jeffrey Yasskin wrote:

> Hi folks,
>=20
> I finally have an update for the string_ref proposal, converting it to
> a set of changes against the C++14 draft. The most recent version
> lives at https://github.com/google/cxx-std-draft/blob/string-ref-paper/st=
ring_ref.html,
> and I've attached a snapshot.
>=20
> The LWG is still deciding whether this should aim for a TS or C++14
> (or both?), and feedback from here will help inform that decision.
> This paper currently assumes C++14.
>=20
> Let me know what you think,
> Jeffrey Yasskin
>=20
> --=20
>=20
>=20
>=20
> <string_ref.html>

--=20
Prof. Peter Sommerlad

Institut f=FCr Software: Bessere Software - Einfach, Schneller!
HSR Hochschule f=FCr Technik Rapperswil
Oberseestr 10, Postfach 1475, CH-8640 Rapperswil

http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includa=
tor.com
tel:+41 55 222 49 84 =3D=3D mobile:+41 79 432 23 32
fax:+41 55 222 46 29 =3D=3D mailto:peter.sommerlad@hsr.ch





--=20




.

------=_Part_554_26450745.1356699894940
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, December 27, 2012 12:44:38 AM UTC+1, Jeffrey Yasskin wrote:

> I finally have an update for the string_ref proposal, converting it to
> a set of changes against the C++14 draft. The most recent version
> lives at
> https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
>
> and I've attached a snapshot.
>
> The LWG is still deciding whether this should aim for a TS or C++14
> (or both?), and feedback from here will help inform that decision.
>
> What are the pros and cons?

std::string, vector and boost::iterator_range have pop_front() and
pop_back(). String_ref isn't a container but pop_front() and pop_back()
would still be useful. Could they be added?
Maybe pop_front(size_t n) could also be added (instead of remove_prefix)?

Is there still time for bike shedding? str_ref is ever so slightly shorter.
:p

String_ref obviously can't be null-terminated, but C strings aren't going
anywhere any time soon unfortunately. Maybe a future zstr_ref proposal
could address this.

--




------=_Part_554_26450745.1356699894940
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, December 27, 2012 12:44:38 AM UTC+1, Jeffrey Yasskin wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">I finally have an update for =
the string_ref proposal, converting it to
<br>a set of changes against the C++14 draft. The most recent version
<br>lives at <a href=3D"https://github.com/google/cxx-std-draft/blob/string=
-ref-paper/string_ref.html" target=3D"_blank">https://github.com/google/cxx=
-<wbr>std-draft/blob/string-ref-<wbr>paper/string_ref.html</a>,
<br>and I've attached a snapshot.
<br>
<br>The LWG is still deciding whether this should aim for a TS or C++14
<br>(or both?), and feedback from here will help inform that decision.
<br><br></blockquote><div>What are the pros and cons?</div><div><br></div><=
div>std::string, vector and boost::iterator_range have pop_front() and pop_=
back(). String_ref isn't a container but pop_front() and pop_back() would s=
till be useful. Could they be added?</div><div>Maybe pop_front(size_t n) co=
uld also be added (instead of remove_prefix)?</div><div><br></div><div>Is t=
here still time for bike shedding?&nbsp;str_ref is ever so slightly shorter=
.. :p</div><div><br></div><div>String_ref obviously can't be null-terminated=
, but C strings aren't going anywhere any time soon unfortunately. Maybe a =
future zstr_ref proposal could address this.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_554_26450745.1356699894940--

.

On Fri, Dec 28, 2012 at 8:04 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thursday, December 27, 2012 12:44:38 AM UTC+1, Jeffrey Yasskin wrote:
>>
>> I finally have an update for the string_ref proposal, converting it to
>> a set of changes against the C++14 draft. The most recent version
>> lives at
>> https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
>> and I've attached a snapshot.

> Is there still time for bike shedding? str_ref is ever so slightly shorter.

Names are important, and I've planning to start such a discussion next
week when more people will be reading this list. But if you want to
start such a discussion now, feel free to do so. However, please start
a separate message thread, with a subject line like "[string-ref] Name
suggestion" so that (1) those that don't care can skip reading the
thread and (2) other technical comments don't get lost in the noise.

Thanks,

--Beman

--




.

On Sat, Dec 29, 2012 at 2:42 PM, Beman Dawes <bdawes@acm.org> wrote:
>> Is there still time for bike shedding? str_ref is ever so slightly shorter.
>
> Names are important, and I've planning to start such a discussion next
> week when more people will be reading this list. But if you want to
> start such a discussion now, feel free to do so. However, please start
> a separate message thread, with a subject line like "[string-ref] Name
> suggestion" so that (1) those that don't care can skip reading the
> thread and (2) other technical comments don't get lost in the noise.

I'll let you have the honor.

BTW, you've got mail.

--
Olaf

--




.

On Wed, Dec 26, 2012 at 6:44 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> Hi folks,
>
> I finally have an update for the string_ref proposal, converting it to
> a set of changes against the C++14 draft. The most recent version
> lives at https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
> and I've attached a snapshot.

From the note in basic.string.ref:

"... User-defined types should define their own implicit conversions
to std::basic_string_ref in order to interoperate with these
functions."

The concern is that this requires an invasive change to the UDT.
That's a particular problem for 3rd party UDT's or UDT's the developer
has no control over.

Have you considered a generic constructor instead? For example,

    template <class String>
    basic_string_ref(const String& s)
      : _beg(::std::string_ref_begin(s)), _end(::std::string_ref_end(s)) {}

Where _beg and _end are the private data members.

The user is granted permission to provide the two adapter functions in
namespace std.

For a TS, helper functions could be provided (in std) for std::basic_string:

  // basic_string_ref helpers
  template <class charT, class traits, class Allocator>
  inline
  const charT* string_ref_begin(const basic_string<charT, traits, Allocator>& s)
  {
    return s.c_str();
  }
  template <class charT, class traits, class Allocator>
  inline
  const charT* string_ref_end(const basic_string<charT, traits, Allocator>& s)
  {
    return s.c_str() + s.size();
  }

A quick test of this is available at https://github.com/Beman/string_ref_ex.

--Beman

--




.

On Mon, Dec 31, 2012 at 5:55 AM, Beman Dawes <bdawes@acm.org> wrote:
> On Wed, Dec 26, 2012 at 6:44 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>> Hi folks,
>>
>> I finally have an update for the string_ref proposal, converting it to
>> a set of changes against the C++14 draft. The most recent version
>> lives at https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
>> and I've attached a snapshot.
>
> From the note in basic.string.ref:
>
> "... User-defined types should define their own implicit conversions
> to std::basic_string_ref in order to interoperate with these
> functions."
>
> The concern is that this requires an invasive change to the UDT.
> That's a particular problem for 3rd party UDT's or UDT's the developer
> has no control over.
>
> Have you considered a generic constructor instead? For example,
>
>     template <class String>
>     basic_string_ref(const String& s)
>       : _beg(::std::string_ref_begin(s)), _end(::std::string_ref_end(s)) {}
>
> Where _beg and _end are the private data members.
>
> The user is granted permission to provide the two adapter functions in
> namespace std.
>

Why not just rely on ADL?

--
Dean Michael Berris
Google

--




.

On Fri, Dec 28, 2012 at 8:04 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thursday, December 27, 2012 12:44:38 AM UTC+1, Jeffrey Yasskin wrote:
>>
>> I finally have an update for the string_ref proposal, converting it to
>> a set of changes against the C++14 draft. The most recent version
>> lives at
>> https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
>> and I've attached a snapshot.
>>
>> The LWG is still deciding whether this should aim for a TS or C++14
>> (or both?), and feedback from here will help inform that decision.
>>
> What are the pros and cons?

Overall, we want string_ref in an official document of some sort as
soon as possible so that other TS'en can depend on it.

The bar for including string_ref in a TS is lower, so it's more likely
string_ref would get into the next one. It would also serve as initial
content for the "utility" TS, which may make it easier to add new
things. Putting it in a TS will allow us to change the class in
incompatible ways if we discover problems. However, a TS will be
explicitly beta and may require user code that adopts string_ref to
change the namespace of the class it uses when string_ref is
incorporated into a future C++ standard, even if we don't make any
changes to the class.

C++14 is more official and is a firmer basis for other TS'en. If we
have consensus that string_ref is the right thing to do, we shouldn't
delay it artificially by including an unnecessary TS step. Putting it
directly into the draft standard would let us stop discussing the
whole proposal repeatedly and just discuss changes. (It's possible
putting it in a TS would have the same effect, but I'm less confident
of that.)

Beman may have other tradeoffs to add.

> std::string, vector and boost::iterator_range have pop_front() and
> pop_back(). String_ref isn't a container but pop_front() and pop_back()
> would still be useful. Could they be added?
> Maybe pop_front(size_t n) could also be added (instead of remove_prefix)?

When we discussed N3350
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html#classstd_1_1range_1a3c743e4e4b85290682234af4c2d7e50f),
there was an argument that pop_front is expected to destroy the
elements it pops, since it does so everywhere in the standard that it
currently exists. The committee seemed to prefer another name. Clearly
pop_front()==remove_prefix(1), so I don't see an urgent need to add
another method for this purpose. If I get clear direction from the
committee that they want to overload pop_front to have this meaning,
I'd be happy to change it back, but I don't expect to get that
direction.

> Is there still time for bike shedding? str_ref is ever so slightly shorter.
> :p

+1 for Beman's suggestion of starting a new thread for this. I don't
intend to participate much on that thread if at all, but I'm happy to
change the proposal if the discussion leans toward a particular other
option.

> String_ref obviously can't be null-terminated, but C strings aren't going
> anywhere any time soon unfortunately. Maybe a future zstr_ref proposal could
> address this.

Definitely a future proposal. I'll add a note to the paper mentioning this.

Also, sorry for forgetting your .data()/.size() constructor
suggestion. I've added a TODO to my local copy of the paper so I won't
forget it again.

Jeffrey

--




.

On Sun, Dec 30, 2012 at 1:55 PM, Beman Dawes <bdawes@acm.org> wrote:
> On Wed, Dec 26, 2012 at 6:44 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>> Hi folks,
>>
>> I finally have an update for the string_ref proposal, converting it to
>> a set of changes against the C++14 draft. The most recent version
>> lives at https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
>> and I've attached a snapshot.
>
> From the note in basic.string.ref:
>
> "... User-defined types should define their own implicit conversions
> to std::basic_string_ref in order to interoperate with these
> functions."
>
> The concern is that this requires an invasive change to the UDT.
> That's a particular problem for 3rd party UDT's or UDT's the developer
> has no control over.
>
> Have you considered a generic constructor instead? For example,
>
>     template <class String>
>     basic_string_ref(const String& s)
>       : _beg(::std::string_ref_begin(s)), _end(::std::string_ref_end(s)) {}
>
> Where _beg and _end are the private data members.
>
> The user is granted permission to provide the two adapter functions in
> namespace std.

I've had bad luck with this kind of adaptation function causing ODR
violations in the past. That is:

Library A provides an adaptation point. Library B defines a type that
could logically be used with library A but doesn't define the
adaptation point.
Libraries C and D want to use B with A and both define the adaptation point.
Binary E wants to use both libraries C and D. ODR violation: Boom,
either at link time (good but hard to recover from if you can't modify
libraries C or D, and if you can modify them, why can't you modify
library B?) or run time (very bad).

That said, the standard's style is generally to allow this kind of
extension, so I'll give in if you think I should add it.

> For a TS, helper functions could be provided (in std) for std::basic_string:

For basic_string, it's easy enough just to define the conversion
constructor. The difference would be in the implicit conversions
allowed with "string_ref sr(non_string_type)", where going through a
string_ref_{begin,end} template would allow fewer and would thereby
allow fewer accidental dangling pointers, which is a plus.

Jeffrey

--




.

On Wed, Jan 2, 2013 at 6:08 AM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> C++14 is more official and is a firmer basis for other TS'en. If we
> have consensus that string_ref is the right thing to do, we shouldn't
> delay it artificially by including an unnecessary TS step. Putting it
> directly into the draft standard would let us stop discussing the
> whole proposal repeatedly and just discuss changes. (It's possible
> putting it in a TS would have the same effect, but I'm less confident
> of that.)

Your list of open questions is short (mine is a bit longer ;), what's
stopping string_ref from getting into C++14?
AFAIK the concept is good, it's just some details that need to be worked out.
It's a shame a reference implementation isn't available yet (in Boost).

> Beman may have other tradeoffs to add.
>
>> std::string, vector and boost::iterator_range have pop_front() and
>> pop_back(). String_ref isn't a container but pop_front() and pop_back()
>> would still be useful. Could they be added?
>> Maybe pop_front(size_t n) could also be added (instead of remove_prefix)?
>
> When we discussed N3350
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html#classstd_1_1range_1a3c743e4e4b85290682234af4c2d7e50f),
> there was an argument that pop_front is expected to destroy the
> elements it pops, since it does so everywhere in the standard that it
> currently exists. The committee seemed to prefer another name. Clearly
> pop_front()==remove_prefix(1), so I don't see an urgent need to add

Not really, semantics are different if range is empty. Remove_prefix
and remove_suffix aren't symmetric in that case either.
I like pop_back() much better, it's not a problem in
boost::iterator_range (AFAIK) and I've no idea what destroying a char
would imply.
The difference with an owning container is already indicated by the type name.

Wouldn't clear() have to be removed too?

> another method for this purpose. If I get clear direction from the
> committee that they want to overload pop_front to have this meaning,
> I'd be happy to change it back, but I don't expect to get that
> direction.

> Also, sorry for forgetting your .data()/.size() constructor
> suggestion. I've added a TODO to my local copy of the paper so I won't
> forget it again.

Using data() and size() probably isn't right, it should be begin() and
end(). The point is being able to construct a string_ref from other
string-like types.

> starts_with(), ends_with()

Is a non-member variant being provided too? Otherwise it's not easily
usable on std::string and other string-like types.

BTW, don't forget my comments at
https://groups.google.com/a/isocpp.org/forum/?hl=en&fromgroups=#!topic/std-proposals/ZUnktXzj0RE
--
Olaf

--




.

On Thu, Jan 3, 2013 at 6:51 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> starts_with(), ends_with()
>
> Is a non-member variant being provided too? Otherwise it's not easily
> usable on std::string and other string-like types.

The proposal added them on basic.string for an appropriate English
reading.

BTW, just curious, can I use

string_ref("prefixtree").starts_with(string("prefix"));

?

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--




.

On Thu, Jan 3, 2013 at 6:58 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Thu, Jan 3, 2013 at 6:51 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> starts_with(), ends_with()
>>
>> Is a non-member variant being provided too? Otherwise it's not easily
>> usable on std::string and other string-like types.
>
> The proposal added them on basic.string for an appropriate English
> reading.

What about other string-like types?

> BTW, just curious, can I use
>
> string_ref("prefixtree").starts_with(string("prefix"));

Why not this?

string_ref("prefixtree").starts_with("prefix")

This is even shorter but requires non-member functions:

starts_with("prefixtree", "prefix")

Olaf

--




.

On Tue, Jan 1, 2013 at 8:15 PM, Dean Michael Berris
<dberris@googlers.com> wrote:
> On Mon, Dec 31, 2012 at 5:55 AM, Beman Dawes <bdawes@acm.org> wrote:
....
>> Have you considered a generic constructor instead? For example,
>>
>>     template <class String>
>>     basic_string_ref(const String& s)
>>       : _beg(::std::string_ref_begin(s)), _end(::std::string_ref_end(s)) {}
>>
>> Where _beg and _end are the private data members.
>>
>> The user is granted permission to provide the two adapter functions in
>> namespace std.
>>
>
> Why not just rely on ADL?

No good reason, and that's what the little prototype did initially.
But I don't understand ADL pitfalls very well,  so avoid using it when
there is an alternative.

I'd defer to library experts if they have a strong opinion, and also
to Jeffery since it is his proposal.

--Beman

--




.

On Thu, Jan 3, 2013 at 12:51 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Wed, Jan 2, 2013 at 6:08 AM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>> C++14 is more official and is a firmer basis for other TS'en. If we
>> have consensus that string_ref is the right thing to do, we shouldn't
>> delay it artificially by including an unnecessary TS step. Putting it
>> directly into the draft standard would let us stop discussing the
>> whole proposal repeatedly and just discuss changes. (It's possible
>> putting it in a TS would have the same effect, but I'm less confident
>> of that.)
>
> Your list of open questions is short (mine is a bit longer ;), what's
> stopping string_ref from getting into C++14?
> AFAIK the concept is good, it's just some details that need to be worked out.
> It's a shame a reference implementation isn't available yet (in Boost).

I think the details are what people are worried about. Personally, I
think we can get them worked out by Bristol and get string_ref into
C++14, but there's enough doubt in the minds of more experienced
committee members that I'm not certain.

Note that the feedback we need from this list is not "which target
should we aim for". It's "which pieces are right and wrong".

>> Beman may have other tradeoffs to add.
>>
>>> std::string, vector and boost::iterator_range have pop_front() and
>>> pop_back(). String_ref isn't a container but pop_front() and pop_back()
>>> would still be useful. Could they be added?
>>> Maybe pop_front(size_t n) could also be added (instead of remove_prefix)?
>>
>> When we discussed N3350
>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html#classstd_1_1range_1a3c743e4e4b85290682234af4c2d7e50f),
>> there was an argument that pop_front is expected to destroy the
>> elements it pops, since it does so everywhere in the standard that it
>> currently exists. The committee seemed to prefer another name. Clearly
>> pop_front()==remove_prefix(1), so I don't see an urgent need to add
>
> Not really, semantics are different if range is empty. Remove_prefix
> and remove_suffix aren't symmetric in that case either.

Now that I'm looking at them again, I think I gave
remove_{prefix,suffix} the wrong semantics. If n>size(), remove_prefix
throws out_of_range, while remove_suffix returns the whole string.
That can't be right. Should they be:

remove_prefix(n) is equivalent to "*this = substr(min(n, size()), npos)"
remove_suffix(n) is equivalent to "*this = substr(0, size() - min(n, size()))"

Or should they Require that n <= size()?

> I like pop_back() much better, it's not a problem in
> boost::iterator_range (AFAIK) and I've no idea what destroying a char
> would imply.
> The difference with an owning container is already indicated by the type name.

I thought pop_back was fine, but the committee disagreed, so it's
changed. You seem to like assuming away programmer mistakes, while I
and the committee want to catch as many as possible within the bounds
of C++, so we're likely to disagree on things like this.

> Wouldn't clear() have to be removed too?

Apparently not. Nobody objected to it.

>> another method for this purpose. If I get clear direction from the
>> committee that they want to overload pop_front to have this meaning,
>> I'd be happy to change it back, but I don't expect to get that
>> direction.
>
>> Also, sorry for forgetting your .data()/.size() constructor
>> suggestion. I've added a TODO to my local copy of the paper so I won't
>> forget it again.
>
> Using data() and size() probably isn't right, it should be begin() and
> end(). The point is being able to construct a string_ref from other
> string-like types.

We'll have to wait for contiguous_iterator_tag then, or take Beman's
suggestion for string_ref_begin() (contiguous_begin()? ew, wart.). I'm
happy with leaving that constructor out of string_ref for the
initially standardized version and adding it later. string_ref doesn't
have to be complete the first time, it just has to be better than what
we have.

>> starts_with(), ends_with()
>
> Is a non-member variant being provided too? Otherwise it's not easily
> usable on std::string and other string-like types.

No, the paper includes, "The non-member equivalents produce calls that
are somewhat ambiguous between starts_with(haystack, needle) vs
starts_with(needle, haystack), while haystack.starts_with(needle) is
the only English reading of the member version. These queries apply
equally well to basic_string, so I've added them there too."

Zhihao and you got the syntax I expect for non-string_ref types:
string_ref("prefixtree").starts_with("prefix")

> BTW, don't forget my comments at
> https://groups.google.com/a/isocpp.org/forum/?hl=en&fromgroups=#!topic/std-proposals/ZUnktXzj0RE

I think I've answered all of them now. What have I missed?

--




.

On Fri, Jan 4, 2013 at 7:59 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> Note that the feedback we need from this list is not "which target
> should we aim for". It's "which pieces are right and wrong".

Ah, ok

>>> Beman may have other tradeoffs to add.
>>>
>>>> std::string, vector and boost::iterator_range have pop_front() and
>>>> pop_back(). String_ref isn't a container but pop_front() and pop_back()
>>>> would still be useful. Could they be added?
>>>> Maybe pop_front(size_t n) could also be added (instead of remove_prefix)?
>>>
>>> When we discussed N3350
>>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html#classstd_1_1range_1a3c743e4e4b85290682234af4c2d7e50f),
>>> there was an argument that pop_front is expected to destroy the
>>> elements it pops, since it does so everywhere in the standard that it
>>> currently exists. The committee seemed to prefer another name. Clearly
>>> pop_front()==remove_prefix(1), so I don't see an urgent need to add
>>
>> Not really, semantics are different if range is empty. Remove_prefix
>> and remove_suffix aren't symmetric in that case either.
>
> Now that I'm looking at them again, I think I gave
> remove_{prefix,suffix} the wrong semantics. If n>size(), remove_prefix
> throws out_of_range, while remove_suffix returns the whole string.
> That can't be right. Should they be:
>
> remove_prefix(n) is equivalent to "*this = substr(min(n, size()), npos)"
> remove_suffix(n) is equivalent to "*this = substr(0, size() - min(n, size()))"
>
> Or should they Require that n <= size()?

I'd go for the latter. Those functions are defined as noexcept.

>> I like pop_back() much better, it's not a problem in
>> boost::iterator_range (AFAIK) and I've no idea what destroying a char
>> would imply.
>> The difference with an owning container is already indicated by the type name.
>
> I thought pop_back was fine, but the committee disagreed, so it's
> changed. You seem to like assuming away programmer mistakes, while I
> and the committee want to catch as many as possible within the bounds
> of C++, so we're likely to disagree on things like this.

I'm not sure that's it.
pop_back() is existing practice in both Boost and D (and the idea was
to standardize existing practice wasn't it?)
Textually pop_back and remove_suffix seem equivalent (to me), nothing
tells me their behaviour is (kinda) different.
Would remove_suffix(1) really avoid mistakes?

http://dlang.org/phobos/std_range.html

>> Wouldn't clear() have to be removed too?
>
> Apparently not. Nobody objected to it.

Seems inconsistent.

> We'll have to wait for contiguous_iterator_tag then, or take Beman's
> suggestion for string_ref_begin() (contiguous_begin()? ew, wart.). I'm
> happy with leaving that constructor out of string_ref for the
> initially standardized version and adding it later. string_ref doesn't
> have to be complete the first time, it just has to be better than what
> we have.

That's easy :p
Waiting for contiguous_iterator_tag or explicit charT* seems fine.

>>> starts_with(), ends_with()
>>
>> Is a non-member variant being provided too? Otherwise it's not easily
>> usable on std::string and other string-like types.
>
> No, the paper includes, "The non-member equivalents produce calls that
> are somewhat ambiguous between starts_with(haystack, needle) vs
> starts_with(needle, haystack), while haystack.starts_with(needle) is
> the only English reading of the member version. These queries apply
> equally well to basic_string, so I've added them there too."
>
> Zhihao and you got the syntax I expect for non-string_ref types:
> string_ref("prefixtree").starts_with("prefix")

Having to include "string_ref" there doesn't seem entirely right.

>> BTW, don't forget my comments at
>> https://groups.google.com/a/isocpp.org/forum/?hl=en&fromgroups=#!topic/std-proposals/ZUnktXzj0RE
>
> I think I've answered all of them now. What have I missed?

The 3 stoi overloads, they look unclean. Wouldn't adding an overload
also have the potential to break code die to ambiguity?


--
Olaf

--




.

On Fri, Jan 4, 2013 at 12:54 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Fri, Jan 4, 2013 at 7:59 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>> Now that I'm looking at them again, I think I gave
>> remove_{prefix,suffix} the wrong semantics. If n>size(), remove_prefix
>> throws out_of_range, while remove_suffix returns the whole string.
>> That can't be right. Should they be:
>>
>> remove_prefix(n) is equivalent to "*this = substr(min(n, size()), npos)"
>> remove_suffix(n) is equivalent to "*this = substr(0, size() - min(n, size()))"
>>
>> Or should they Require that n <= size()?
>
> I'd go for the latter. Those functions are defined as noexcept.

noexcept would imply the first, I think. We don't generally have
noexcept functions with Requires clauses. (I'm sure there are some,
but for example string::front() isn't noexcept.) Google's and LLVM's
versions of this, though, assert(size()>=n).

>>> I like pop_back() much better, it's not a problem in
>>> boost::iterator_range (AFAIK) and I've no idea what destroying a char
>>> would imply.
>>> The difference with an owning container is already indicated by the type name.
>>
>> I thought pop_back was fine, but the committee disagreed, so it's
>> changed. You seem to like assuming away programmer mistakes, while I
>> and the committee want to catch as many as possible within the bounds
>> of C++, so we're likely to disagree on things like this.
>
> I'm not sure that's it.
> pop_back() is existing practice in both Boost and D (and the idea was
> to standardize existing practice wasn't it?)

remove_back is existing practice in Google's version of this. LLVM's
version uses drop_back. Bloomberg doesn't define it. So I don't think
existing practice decides this.

> Textually pop_back and remove_suffix seem equivalent (to me), nothing
> tells me their behaviour is (kinda) different.
> Would remove_suffix(1) really avoid mistakes?
>
> http://dlang.org/phobos/std_range.html
>
>>> BTW, don't forget my comments at
>>> https://groups.google.com/a/isocpp.org/forum/?hl=en&fromgroups=#!topic/std-proposals/ZUnktXzj0RE
>>
>> I think I've answered all of them now. What have I missed?
>
> The 3 stoi overloads, they look unclean. Wouldn't adding an overload
> also have the potential to break code die to ambiguity?

If a class has an implicit conversion to both const char* and
std::string (or has a template conversion operator), and is being
passed directly to stoi(), that could break. This seems less likely
than either that const char* is being passed to stoi() or that a class
with only an implicit conversion to std::string is being passed.

It's definitely annoying to have to deal with backwards compatibility
like this, but string_ref exists primarily for the convenience of
people using C++, and only secondarily to clean up the standard.

Jeffrey

--




.

On Fri, Jan 4, 2013 at 10:58 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>>> Or should they Require that n <= size()?
>>
>> I'd go for the latter. Those functions are defined as noexcept.
>
> noexcept would imply the first, I think. We don't generally have
> noexcept functions with Requires clauses. (I'm sure there are some,
> but for example string::front() isn't noexcept.) Google's and LLVM's
> versions of this, though, assert(size()>=n).

I assumed require would be the precondition and breaking it would be UB.

>>>> I like pop_back() much better, it's not a problem in
>>>> boost::iterator_range (AFAIK) and I've no idea what destroying a char
>>>> would imply.
>>>> The difference with an owning container is already indicated by the type name.
>>>
>>> I thought pop_back was fine, but the committee disagreed, so it's
>>> changed. You seem to like assuming away programmer mistakes, while I
>>> and the committee want to catch as many as possible within the bounds
>>> of C++, so we're likely to disagree on things like this.
>>
>> I'm not sure that's it.
>> pop_back() is existing practice in both Boost and D (and the idea was
>> to standardize existing practice wasn't it?)
>
> remove_back is existing practice in Google's version of this. LLVM's
> version uses drop_back. Bloomberg doesn't define it. So I don't think
> existing practice decides this.

All use back instead of suffix.
LLVM's defaults N to 1. Is Google's version public?

>> Textually pop_back and remove_suffix seem equivalent (to me), nothing
>> tells me their behaviour is (kinda) different.
>> Would remove_suffix(1) really avoid mistakes?
>>
>> http://dlang.org/phobos/std_range.html



--
Olaf

--




.

On Fri, Jan 4, 2013 at 2:11 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Fri, Jan 4, 2013 at 10:58 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>> remove_back is existing practice in Google's version of this. LLVM's
>> version uses drop_back. Bloomberg doesn't define it. So I don't think
>> existing practice decides this.
>
> All use back instead of suffix.
> LLVM's defaults N to 1. Is Google's version public?

https://code.google.com/p/re2/source/browse/re2/stringpiece.h,
http://www.icu-project.org/apiref/icu4c/classicu_1_1StringPiece.html,
and https://code.google.com/searchframe#OAMlx_jo-ck/src/base/string_piece.h&type=cs&l=102
(Chrome) all look derived from Google's version. I typo'ed
remove_back, it's actually remove_suffix.

--




.

Olaf van der Spek <olafvdspek@gmail.com> writes:

[...]

| > I thought pop_back was fine, but the committee disagreed, so it's
| > changed. You seem to like assuming away programmer mistakes, while I
| > and the committee want to catch as many as possible within the bounds
| > of C++, so we're likely to disagree on things like this.
|
| I'm not sure that's it.
| pop_back() is existing practice in both Boost and D (and the idea was
| to standardize existing practice wasn't it?)

No, we are not required to standardize "existing practice" if in
hindsight it is not such a bright idea.

--




.

On Wed, Jan 2, 2013 at 12:08 AM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> On Fri, Dec 28, 2012 at 8:04 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> On Thursday, December 27, 2012 12:44:38 AM UTC+1, Jeffrey Yasskin wrote:
>>>
.....
>>> The LWG is still deciding whether this should aim for a TS or C++14
>>> (or both?), and feedback from here will help inform that decision.
>>>
>> What are the pros and cons?
>
> Overall, we want string_ref in an official document of some sort as
> soon as possible so that other TS'en can depend on it.

Agreed.

> The bar for including string_ref in a TS is lower, so it's more likely
> string_ref would get into the next one. It would also serve as initial
> content for the "utility" TS, which may make it easier to add new
> things. Putting it in a TS will allow us to change the class in
> incompatible ways if we discover problems. However, a TS will be
> explicitly beta and may require user code that adopts string_ref to
> change the namespace of the class it uses when string_ref is
> incorporated into a future C++ standard, even if we don't make any
> changes to the class.

That's a nice summary of the TS target.

> C++14 is more official and is a firmer basis for other TS'en. If we
> have consensus that string_ref is the right thing to do, we shouldn't
> delay it artificially by including an unnecessary TS step. Putting it
> directly into the draft standard would let us stop discussing the
> whole proposal repeatedly and just discuss changes. (It's possible
> putting it in a TS would have the same effect, but I'm less confident
> of that.)

Having "consensus that string_ref is the right thing to do" with
reasonably correct proposed wording is good enough for a TS, but for
the standard itself there are a lot of additional hurdles.  Some
committee members may want more real-world experience, others may be
concerned about the volume of changes to existing components, the
impact on books about C++, possible ABI breakage, maturity of wording,
impact on teaching, etc. These concerns often come from folks who do
not follow the doings of the LWG closely, so only arise late in the
process and tend to delay progress. Whether any of these concerns will
arise for string_ref is hard to predict, but I'd would not be
surprised if at least a few of them surface.

> Beman may have other tradeoffs to add.

I rate the probability of finishing technical work on a Library
Utility TS in 2013 as 70% or better, and by 2014 as 95%. I rate the
probability of finishing technical work on C++14 in 2013 as 25%, by
2014 as 65%, and by 2015 as 95%.

Remember too that if other TS's are gated on string_ref, and
string_ref is part of C++14, we would have to hold the other TS's
waiting for a delayed C++14.

--Beman

--




.

I've uploaded a new version to
http://jeffrey.yasskin.info/cxx/2012/string_ref.html with updates from
this thread. I'm planning to send this off to Clark tomorrow, although
if https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5sW8yp5i8mo/discussion
keeps agreeing on string_view, I may switch to that name first.

On Wed, Dec 26, 2012 at 3:44 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> Hi folks,
>
> I finally have an update for the string_ref proposal, converting it to
> a set of changes against the C++14 draft. The most recent version
> lives at https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
> and I've attached a snapshot.
>
> The LWG is still deciding whether this should aim for a TS or C++14
> (or both?), and feedback from here will help inform that decision.
> This paper currently assumes C++14.
>
> Let me know what you think,
> Jeffrey Yasskin

--




.

------=_Part_361_31299157.1357868889998
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, January 10, 2013 4:54:08 PM UTC-8, Jeffrey Yasskin wrote:
>
> I've uploaded a new version to
> http://jeffrey.yasskin.info/cxx/2012/string_ref.html with updates from
> this thread. I'm planning to send this off to Clark tomorrow, although
> if
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5sW8yp5i8mo/discussion
> keeps agreeing on string_view, I may switch to that name first.
>

In the section on user-defined conversion, you said:

Ultimately, I think we want to allow this conversion based on detecting
> contiguous ranges. Any constructor we add to work around that is going to
> look like a wart in a couple years. I think we'll be better off making
> users explicitly convert when they can't add an appropriate conversion
> operator, and then we can add the optimal constructor when contiguous
> iterators make it into the library.
>

This assumes that every string type out there can be detected as a
"contiguous range", which is a concept that doesn't exist even in
Boost.Range. It's hard to know what users would have to provide or if such
things can be provided without modifying the type.

Also, it seems to put on a significant short-term problem over a long-term
goal, when it's not entirely clear how long term this goal will be. Or if
the eventual contiguous iterator and contiguous range proposals will even
fit into the needs for basic_string_ref. Current discussions on the Range
mailing list are starting to talk about things like ranges as primitive
types with *no iterators*. If they go that route, I'm not sure if that's
going to be a viable solution for basic_string_ref going forward.

I don't like the idea of making a proposal somewhat incomplete (you do
recognize the need for user-defined conversions) on the assumption that in
a year or two someone will come along with a fix. I say we give the user
the ability to provide something that will work and be extensible now. If
the eventual Range proposal comes along that can't handle things this way,
then we already have our solution. If another solution appears, we can use
that. It may leave a wart, but it will be a very small and harmless one.
And it's not like anyone will really notice one more wart in our string
classes...

--




------=_Part_361_31299157.1357868889998
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, January 10, 2013 4:54:08 PM UTC-8, Jeffrey Yasskin wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">I've uploaded a new version=
 to
<br><a href=3D"http://jeffrey.yasskin.info/cxx/2012/string_ref.html" target=
=3D"_blank">http://jeffrey.yasskin.info/<wbr>cxx/2012/string_ref.html</a> w=
ith updates from
<br>this thread. I'm planning to send this off to Clark tomorrow, although
<br>if <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-propos=
als/5sW8yp5i8mo/discussion" target=3D"_blank">https://groups.google.com/a/<=
wbr>isocpp.org/d/topic/std-<wbr>proposals/5sW8yp5i8mo/<wbr>discussion</a>
<br>keeps agreeing on string_view, I may switch to that name first.
<br></blockquote><div><br>In the section on user-defined conversion, you sa=
id:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px=
 solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">Ultima=
tely, I think we want to allow this conversion based on detecting
contiguous ranges. Any constructor we add to work around that is going to
look like a wart in a couple years. I think we'll be better off making
users explicitly convert when they can't add an appropriate conversion
operator, and then we can add the optimal constructor when contiguous
iterators make it into the library.<br></blockquote><br>This assumes that e=
very string type out there can be detected as a "contiguous range", which i=
s a concept that doesn't exist even in Boost.Range. It's hard to know what =
users would have to provide or if such things can be provided without modif=
ying the type.<br><br>Also, it seems to put on a significant short-term pro=
blem over a long-term goal, when it's not entirely clear how long term this=
 goal will be. Or if the eventual contiguous iterator and contiguous range =
proposals will even fit into the needs for basic_string_ref. Current discus=
sions on the Range mailing list are starting to talk about things like rang=
es as primitive types with <i>no iterators</i>. If they go that route, I'm =
not sure if that's going to be a viable solution for basic_string_ref going=
 forward.<br><br>I don't like the idea of making a proposal somewhat incomp=
lete (you do recognize the need for user-defined conversions) on the assump=
tion that in a year or two someone will come along with a fix. I say we giv=
e the user the ability to provide something that will work and be extensibl=
e now. If the eventual Range proposal comes along that can't handle things =
this way, then we already have our solution. If another solution appears, w=
e can use that. It may leave a wart, but it will be a very small and harmle=
ss one. And it's not like anyone will really notice one more wart in our st=
ring classes...<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_361_31299157.1357868889998--

.

On Fri, Jan 11, 2013 at 2:48 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> I don't like the idea of making a proposal somewhat incomplete (you do
> recognize the need for user-defined conversions) on the assumption that in a
> year or two someone will come along with a fix. I say we give the user the
> ability to provide something that will work and be extensible now. If the
> eventual Range proposal comes along that can't handle things this way, then
> we already have our solution. If another solution appears, we can use that.
> It may leave a wart, but it will be a very small and harmless one. And it's
> not like anyone will really notice one more wart in our string classes...

We don't have to wait a year or two, we could write a proposal to fix
the contiguous range detection issue tomorrow.
Iterators aren't going away any time soon (I expect), so basing a
solution on them seems ok.

I'd go for the addition of an explicit conversion to pointer on
contiguous iterators, such that this works:

std::array<char, 10> v;
char* b(v.begin());
char* e(v.end());

Seems simple and useful in other situations too.
--
Olaf

--




.

------=_Part_483_20621667.1357897435908
Content-Type: text/plain; charset=ISO-8859-1



On Friday, January 11, 2013 12:52:06 AM UTC-8, Olaf van der Spek wrote:
>
> On Fri, Jan 11, 2013 at 2:48 AM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > I don't like the idea of making a proposal somewhat incomplete (you do
> > recognize the need for user-defined conversions) on the assumption that
> in a
> > year or two someone will come along with a fix. I say we give the user
> the
> > ability to provide something that will work and be extensible now. If
> the
> > eventual Range proposal comes along that can't handle things this way,
> then
> > we already have our solution. If another solution appears, we can use
> that.
> > It may leave a wart, but it will be a very small and harmless one. And
> it's
> > not like anyone will really notice one more wart in our string
> classes...
>
> We don't have to wait a year or two, we could write a proposal to fix
> the contiguous range detection issue tomorrow.
>

True. But if we put basic_string_ref/view into a TS, it won't necessarily
have the contiguous range fix as part of the TS. So there will be no
extensibility mechanism. Also, if that proposal doesn't make it for C++14
and this one does, then again, we won't have an extensibility mechanism.

This is one of those "system integration" problems that comes with having
multiple proposals in parallel, all with dependencies on each other. A
proposal that has progessed farther handwaves some of its features by
saying, "well, that proposal will take care of that case," rather than
dealing with the problem internally and being functionally complete.

At the very least, there should be some fall-back mechanism in this
proposal which can be used if the real fix isn't available by the time the
final paper, whether a TS or C++14, is released. At least that way, we can
be sure that this proposal will stand on its own.

Oh, and one of the nice things about TS's is that you can change them when
you pull them into the standard. So we don't have to stick to an
extensibility mechanism we don't like when we move the class to C++14
standard.

--




------=_Part_483_20621667.1357897435908
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, January 11, 2013 12:52:06 AM UTC-8, Olaf van der Spek wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Jan 11, 2013 at 2:=
48 AM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"UGfzw6u2ssYJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; I don't like the idea of making a proposal somewhat incomplete (yo=
u do
<br>&gt; recognize the need for user-defined conversions) on the assumption=
 that in a
<br>&gt; year or two someone will come along with a fix. I say we give the =
user the
<br>&gt; ability to provide something that will work and be extensible now.=
 If the
<br>&gt; eventual Range proposal comes along that can't handle things this =
way, then
<br>&gt; we already have our solution. If another solution appears, we can =
use that.
<br>&gt; It may leave a wart, but it will be a very small and harmless one.=
 And it's
<br>&gt; not like anyone will really notice one more wart in our string cla=
sses...
<br>
<br>We don't have to wait a year or two, we could write a proposal to fix
<br>the contiguous range detection issue tomorrow.
<br></blockquote><div><br>True. But if we put basic_string_ref/view into a =
TS, it won't necessarily have the contiguous range fix as part of the TS. S=
o there will be no extensibility mechanism. Also, if that proposal doesn't =
make it for C++14 and this one does, then again, we won't have an extensibi=
lity mechanism.<br><br>This is one of those "system integration" problems t=
hat comes with having multiple proposals in parallel, all with dependencies=
 on each other. A proposal that has progessed farther handwaves some of its=
 features by saying, "well, that proposal will take care of that case," rat=
her than dealing with the problem internally and being functionally complet=
e.<br><br>At the very least, there should be some fall-back mechanism in th=
is proposal which can be used if the real fix isn't available by the time t=
he final paper, whether a TS or C++14, is released. At least that way, we c=
an be sure that this proposal will stand on its own.<br><br>Oh, and one of =
the nice things about TS's is that you can change them when you pull them i=
nto the standard. So we don't have to stick to an extensibility mechanism w=
e don't like when we move the class to C++14 standard.</div><br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_483_20621667.1357897435908--

.

On Fri, Jan 11, 2013 at 10:43 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> We don't have to wait a year or two, we could write a proposal to fix
>> the contiguous range detection issue tomorrow.
>
>
> True. But if we put basic_string_ref/view into a TS, it won't necessarily
> have the contiguous range fix as part of the TS. So there will be no
> extensibility mechanism. Also, if that proposal doesn't make it for C++14
> and this one does, then again, we won't have an extensibility mechanism.

Actually can't we just define operator string_ref() on other classes?

> Oh, and one of the nice things about TS's is that you can change them when
> you pull them into the standard. So we don't have to stick to an
> extensibility mechanism we don't like when we move the class to C++14
> standard.

You can, but breaking compatibility still isn't nice.


--
Olaf

--




.

--001517475cb0124dc804d304d184
Content-Type: text/plain; charset=ISO-8859-1

On 11 January 2013 02:52, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> We don't have to wait a year or two, we could write a proposal to fix
> the contiguous range detection issue tomorrow.
>

FYI:  I'm working on a contiguous_iterator_tag proposal for Bristol (but it
probably won't be done before the mailing deadline next week).
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




--001517475cb0124dc804d304d184
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11 January 2013 02:52, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=
=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>=
&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">

<div class=3D"im">We don&#39;t have to wait a year or two, we could write a=
 proposal to fix</div>
the contiguous range detection issue tomorrow.<br></blockquote><div><br></d=
iv><div>FYI: =A0I&#39;m working on a contiguous_iterator_tag proposal for B=
ristol (but it probably won&#39;t be done before the mailing deadline next =
week).</div>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--001517475cb0124dc804d304d184--

.

On Fri, Jan 11, 2013 at 4:18 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 11 January 2013 02:52, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>
>> We don't have to wait a year or two, we could write a proposal to fix
>> the contiguous range detection issue tomorrow.
>
>
> FYI:  I'm working on a contiguous_iterator_tag proposal for Bristol (but it
> probably won't be done before the mailing deadline next week).

Great!
Isn't that deadline today though?

Could you also consider a conversion operator to T* for such iterators?

--
Olaf

--




.

--0015174c0bfcab120f04d3056d71
Content-Type: text/plain; charset=ISO-8859-1

On 11 January 2013 09:35, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> On Fri, Jan 11, 2013 at 4:18 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
> > On 11 January 2013 02:52, Olaf van der Spek <olafvdspek@gmail.com>
> wrote:
> >>
> >> We don't have to wait a year or two, we could write a proposal to fix
> >> the contiguous range detection issue tomorrow.
> >
> >
> > FYI:  I'm working on a contiguous_iterator_tag proposal for Bristol (but
> it
> > probably won't be done before the mailing deadline next week).
>
> Great!
> Isn't that deadline today though?
>

It could be, in which case it still won't be done by this mailing..


> Could you also consider a conversion operator to T* for such iterators?


Yes, I am putting that in there (leaning against requiring a conversion
from T* to iterator, though).
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




--0015174c0bfcab120f04d3056d71
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11 January 2013 09:35, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=
=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>=
&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">

<div class=3D"im">On Fri, Jan 11, 2013 at 4:18 PM, Nevin Liber &lt;<a href=
=3D"mailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br=
>
&gt; On 11 January 2013 02:52, Olaf van der Spek &lt;<a href=3D"mailto:olaf=
vdspek@gmail.com">olafvdspek@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; We don&#39;t have to wait a year or two, we could write a proposal=
 to fix<br>
&gt;&gt; the contiguous range detection issue tomorrow.<br>
&gt;<br>
&gt;<br>
&gt; FYI: =A0I&#39;m working on a contiguous_iterator_tag proposal for Bris=
tol (but it<br>
&gt; probably won&#39;t be done before the mailing deadline next week).<br>
<br>
</div>Great!<br>
Isn&#39;t that deadline today though?<br></blockquote><div><br></div><div>I=
t could be, in which case it still won&#39;t be done by this mailing..</div=
><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">

Could you also consider a conversion operator to T* for such iterators?</bl=
ockquote><div><br></div><div>Yes, I am putting that in there (leaning again=
st requiring a conversion from T* to iterator, though).=A0</div></div>-- <b=
r>

=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1=
404

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--0015174c0bfcab120f04d3056d71--

.

------=_Part_885_9256226.1357921030997
Content-Type: text/plain; charset=ISO-8859-1



On Friday, January 11, 2013 2:15:05 AM UTC-8, Olaf van der Spek wrote:
>
> On Fri, Jan 11, 2013 at 10:43 AM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> >> We don't have to wait a year or two, we could write a proposal to fix
> >> the contiguous range detection issue tomorrow.
> >
> >
> > True. But if we put basic_string_ref/view into a TS, it won't
> necessarily
> > have the contiguous range fix as part of the TS. So there will be no
> > extensibility mechanism. Also, if that proposal doesn't make it for
> C++14
> > and this one does, then again, we won't have an extensibility mechanism.
>
> Actually can't we just define operator string_ref() on other classes?
>

The point would be for code we don't own. Like CString and the myriad of
other string classes used by the multitude of C++ libraries out there.

--




------=_Part_885_9256226.1357921030997
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, January 11, 2013 2:15:05 AM UTC-8, Olaf van der Spek wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Jan 11, 2013 at 10:=
43 AM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"2l1xFndYWGMJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; We don't have to wait a year or two, we could write a proposal=
 to fix
<br>&gt;&gt; the contiguous range detection issue tomorrow.
<br>&gt;
<br>&gt;
<br>&gt; True. But if we put basic_string_ref/view into a TS, it won't nece=
ssarily
<br>&gt; have the contiguous range fix as part of the TS. So there will be =
no
<br>&gt; extensibility mechanism. Also, if that proposal doesn't make it fo=
r C++14
<br>&gt; and this one does, then again, we won't have an extensibility mech=
anism.
<br>
<br>Actually can't we just define operator string_ref() on other classes?<b=
r></blockquote><div><br>The point would be for code we don't own. Like CStr=
ing and the myriad of other string classes used by the multitude of C++ lib=
raries out there.</div><br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_885_9256226.1357921030997--

.

On Fri, Jan 11, 2013 at 5:17 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> The point would be for code we don't own. Like CString and the myriad of
> other string classes used by the multitude of C++ libraries out there.

I hope the owners of these libs include support themselves.


--
Olaf

--




.

------=_Part_476_25061080.1357924086518
Content-Type: text/plain; charset=ISO-8859-1



On Friday, January 11, 2013 8:30:44 AM UTC-8, Olaf van der Spek wrote:
>
> On Fri, Jan 11, 2013 at 5:17 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > The point would be for code we don't own. Like CString and the myriad of
> > other string classes used by the multitude of C++ libraries out there.
>
> I hope the owners of these libs include support themselves.
>

Reality always ensues. That's why we like customization points to be free
functions, so that they can be implemented without modifying the class.

--




------=_Part_476_25061080.1357924086518
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, January 11, 2013 8:30:44 AM UTC-8, Olaf van der Spek wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Jan 11, 2013 at 5:1=
7 PM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"JZCiA7j1hBQJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; The point would be for code we don't own. Like CString and the myr=
iad of
<br>&gt; other string classes used by the multitude of C++ libraries out th=
ere.
<br>
<br>I hope the owners of these libs include support themselves.
<br></blockquote><div><br>Reality always ensues. That's why we like customi=
zation points to be free functions, so that they can be implemented without=
 modifying the class.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_476_25061080.1357924086518--

.

On Fri, Jan 11, 2013 at 9:08 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Friday, January 11, 2013 8:30:44 AM UTC-8, Olaf van der Spek wrote:
>>
>> On Fri, Jan 11, 2013 at 5:17 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>> > The point would be for code we don't own. Like CString and the myriad of
>> > other string classes used by the multitude of C++ libraries out there.
>>
>> I hope the owners of these libs include support themselves.
>
>
> Reality always ensues. That's why we like customization points to be free
> functions, so that they can be implemented without modifying the class.

See also https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8t5EFJfLn0I/26ihRCq8N2sJ.
I'm unconvinced that there's enough benefit from making up an external
adaptation mechanism to outweigh the fact that we know it's going to
be obsolete "soon", so it won't be in this mailing's paper. If there's
an outcry from more people, I can always add it to the pre-Bristol
mailing.

Thanks,
Jeffrey

--




.

------=_Part_397_23289814.1357927736274
Content-Type: text/plain; charset=ISO-8859-1



On Friday, January 11, 2013 9:46:54 AM UTC-8, Jeffrey Yasskin wrote:
>
> On Fri, Jan 11, 2013 at 9:08 AM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> >
> >
> > On Friday, January 11, 2013 8:30:44 AM UTC-8, Olaf van der Spek wrote:
> >>
> >> On Fri, Jan 11, 2013 at 5:17 PM, Nicol Bolas <jmck...@gmail.com>
> wrote:
> >> > The point would be for code we don't own. Like CString and the myriad
> of
> >> > other string classes used by the multitude of C++ libraries out
> there.
> >>
> >> I hope the owners of these libs include support themselves.
> >
> >
> > Reality always ensues. That's why we like customization points to be
> free
> > functions, so that they can be implemented without modifying the class.
>
> See also
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8t5EFJfLn0I/26ihRCq8N2sJ.
>
>

That's going to be no less of a problem than the eventual solution with
contiguous iterators/ranges, because they'll still have to use existing
customization points to expose them (std::begin/end). And those can still
conflict between libraries. So I don't see how the eventual solution fixes
this problem.

Also, I'm not sure I see the logic in not providing this for that reason.
Given users of libraries A and users of libraries B, the only people who
will encounter that problem are the intersection of those users. You are
suggesting that we inconvenience the *union* of the users of libraries A
and B. That's hurting a lot more people, which seems to me to not be a good
thing.

--




------=_Part_397_23289814.1357927736274
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, January 11, 2013 9:46:54 AM UTC-8, Jeffrey Yasskin wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Jan 11, 2013 at 9:08 =
AM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"U5E65XnkK_IJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Friday, January 11, 2013 8:30:44 AM UTC-8, Olaf van der Spek wr=
ote:
<br>&gt;&gt;
<br>&gt;&gt; On Fri, Jan 11, 2013 at 5:17 PM, Nicol Bolas &lt;<a>jmck...@gm=
ail.com</a>&gt; wrote:
<br>&gt;&gt; &gt; The point would be for code we don't own. Like CString an=
d the myriad of
<br>&gt;&gt; &gt; other string classes used by the multitude of C++ librari=
es out there.
<br>&gt;&gt;
<br>&gt;&gt; I hope the owners of these libs include support themselves.
<br>&gt;
<br>&gt;
<br>&gt; Reality always ensues. That's why we like customization points to =
be free
<br>&gt; functions, so that they can be implemented without modifying the c=
lass.
<br>
<br>See also <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-pr=
oposals/8t5EFJfLn0I/26ihRCq8N2sJ" target=3D"_blank">https://groups.google.c=
om/a/<wbr>isocpp.org/d/msg/std-<wbr>proposals/8t5EFJfLn0I/<wbr>26ihRCq8N2sJ=
</a>.
<br></blockquote><div><br>That's going to be no less of a problem than the =
eventual solution with contiguous iterators/ranges, because they'll still h=
ave to use existing customization points to expose them (std::begin/end). A=
nd those can still conflict between libraries. So I don't see how the event=
ual solution fixes this problem.<br><br>Also, I'm not sure I see the logic =
in not providing this for that reason. Given users of libraries A and users=
 of libraries B, the only people who will encounter that problem are the in=
tersection of those users. You are suggesting that we inconvenience the <i>=
union</i> of the users of libraries A and B. That's hurting a lot more peop=
le, which seems to me to not be a good thing.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_397_23289814.1357927736274--

.

On 11 January 2013 20:08, Nicol Bolas <jmckesson@gmail.com> wrote:
> Also, I'm not sure I see the logic in not providing this for that reason.
> Given users of libraries A and users of libraries B, the only people who
> will encounter that problem are the intersection of those users. You are
> suggesting that we inconvenience the union of the users of libraries A and
> B. That's hurting a lot more people, which seems to me to not be a good
> thing.

I fail to see what this storm in a teacup is about. I can use the
(const char*, size) constructor
to construct a string_view from most existing library strings.

--




.

<head></head><body data-blackberry-caret-color=3D"#00a8df" style=3D"backgro=
und-color: rgb(255, 255, 255);"><div id=3D"BB10_response_div" style=3D"widt=
h:100%;background:#ffffff; font-size: initial;font-family:&quot;Calibri&quo=
t;,&quot;Slate Pro&quot;,&quot;sans-serif&quot;;color:#1f497d">I think the =
issue is auto conversion.&nbsp;</div><div id=3D"BB10_response_div" style=3D=
"width:100%;background:#ffffff; font-size: initial;font-family:&quot;Calibr=
i&quot;,&quot;Slate Pro&quot;,&quot;sans-serif&quot;;color:#1f497d"><br></d=
iv><div id=3D"BB10_response_div" style=3D"width:100%;background:#ffffff; fo=
nt-size: initial;font-family:&quot;Calibri&quot;,&quot;Slate Pro&quot;,&quo=
t;sans-serif&quot;;color:#1f497d">Can a function that takes a string_view a=
utomatically take a CString, or do I need to call a conversion.&nbsp;</div>=
<div id=3D"BB10_response_div" style=3D"width:100%;background:#ffffff; font-=
size: initial;font-family:&quot;Calibri&quot;,&quot;Slate Pro&quot;,&quot;s=
ans-serif&quot;;color:#1f497d"><br></div><div id=3D"BB10_response_div" styl=
e=3D"width:100%;background:#ffffff; font-size: initial;font-family:&quot;Ca=
libri&quot;,&quot;Slate Pro&quot;,&quot;sans-serif&quot;;color:#1f497d">Sor=
ry for topposting.</div><div id=3D"BB10_response_div" style=3D"width:100%;b=
ackground:#ffffff; font-size: initial;font-family:&quot;Calibri&quot;,&quot=
;Slate Pro&quot;,&quot;sans-serif&quot;;color:#1f497d"><br></div><div id=3D=
"BB10_response_div" style=3D"width:100%;background:#ffffff; font-size: init=
ial;font-family:&quot;Calibri&quot;,&quot;Slate Pro&quot;,&quot;sans-serif&=
quot;;color:#1f497d">Tony</div><div id=3D"BB10_response_div" style=3D"width=
:100%;background:#ffffff; font-size: initial;font-family:&quot;Calibri&quot=
;,&quot;Slate Pro&quot;,&quot;sans-serif&quot;;color:#1f497d"><br></div><p =
id=3D"_signaturePlaceholder" style=3D"marginTop:2px; font-size: initial;fon=
t-family:&quot;Calibri&quot;,&quot;Slate Pro&quot;,&quot;sans-serif&quot;;c=
olor:#1f497d;">Sent from my BlackBerry 10 smartphone.</p><table width=3D"10=
0%" style=3D"border-spacing:0px;"> <tbody><tr><td colspan=3D"2"><div id=3D"=
_persistentHeader" style=3D"border-style: solid none none; border-top-color=
: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-fam=
ily: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"><div><b>From: =
</b>Ville Voutilainen</div><div><b>Sent: </b>Friday, January 11, 2013 1:12 =
PM</div><div><b>To: </b>std-proposals@isocpp.org</div><div><b>Reply To: </b=
>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: [std-proposals] Re:=
 Update to string_ref proposal</div></div></td></tr></tbody></table><div id=
=3D"_persistentHeaderEnd" style=3D"border:none;border-top:solid #babcd1 1pt=
;"></div><br><div id=3D"_originalContent" style=3D""><p>On 11 January 2013 =
20:08, Nicol Bolas <jmckesson@gmail.com> wrote:<br>&gt; Also, I'm not sure =
I see the logic in not providing this for that reason.<br>&gt; Given users =
of libraries A and users of libraries B, the only people who<br>&gt; will e=
ncounter that problem are the intersection of those users. You are<br>&gt; =
suggesting that we inconvenience the union of the users of libraries A and<=
br>&gt; B. That's hurting a lot more people, which seems to me to not be a =
good<br>&gt; thing.<br><br>I fail to see what this storm in a teacup is abo=
ut. I can use the<br>(const char*, size) constructor<br>to construct a stri=
ng_view from most existing library strings.<br><br>-- <br><br><br><br></jmc=
kesson@gmail.com></p></div></body>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

.

--f46d0447f3dc3c663504d3081582
Content-Type: text/plain; charset=ISO-8859-1

On 11 January 2013 21:04, <tvaneerd@gmail.com> wrote:

> I think the issue is auto conversion.
>
> Can a function that takes a string_view automatically take a CString, or
> do I need to call a conversion.
>

How many people does it help if string_view can do the automatic
conversion, but string can't? Or do we plan
to allow string to perform such conversions too?

--




--f46d0447f3dc3c663504d3081582
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On 11 January 2013 21:04,  <span dir=3D"=
ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@g=
mail.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 style><div style=3D"width:100%;background:#ffffff;font-size:initial;fo=
nt-family:&quot;Calibri&quot;,&quot;Slate Pro&quot;,&quot;sans-serif&quot;;=
color:#1f497d">I think the issue is auto conversion.=A0</div><div style=3D"=
width:100%;background:#ffffff;font-size:initial;font-family:&quot;Calibri&q=
uot;,&quot;Slate Pro&quot;,&quot;sans-serif&quot;;color:#1f497d">
<br></div><div style=3D"width:100%;background:#ffffff;font-size:initial;fon=
t-family:&quot;Calibri&quot;,&quot;Slate Pro&quot;,&quot;sans-serif&quot;;c=
olor:#1f497d">Can a function that takes a string_view automatically take a =
CString, or do I need to call a conversion.=A0</div>
</div></blockquote><div><br>How many people does it help if string_view can=
 do the automatic conversion, but string can&#39;t? Or do we plan<br>to all=
ow string to perform such conversions too? <br></div></div><br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--f46d0447f3dc3c663504d3081582--

.

Le 11/01/13 01:54, Jeffrey Yasskin a =E9crit :
> I've uploaded a new version to
> http://jeffrey.yasskin.info/cxx/2012/string_ref.html with updates from
> this thread. I'm planning to send this off to Clark tomorrow, although
> if https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5sW8yp5i8=
mo/discussion
> keeps agreeing on string_view, I may switch to that name first.
>
> On Wed, Dec 26, 2012 at 3:44 PM, Jeffrey Yasskin <jyasskin@googlers.com> =
wrote:
>> Hi folks,
>>
>> I finally have an update for the string_ref proposal, converting it to
>> a set of changes against the C++14 draft. The most recent version
>> lives at https://github.com/google/cxx-std-draft/blob/string-ref-paper/s=
tring_ref.html,
>> and I've attached a snapshot.
>>
>> The LWG is still deciding whether this should aim for a TS or C++14
>> (or both?), and feedback from here will help inform that decision.
>> This paper currently assumes C++14.
>>
>>
Hi,

I remember that someone suggested to remove the clear() member function=20
as the behavior doesn't corresponds to string::clear(). I don't remember=20
the outcome of this remark.

Vicente

--=20




.

On Fri, Jan 11, 2013 at 12:06 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 11/01/13 01:54, Jeffrey Yasskin a =E9crit :
>
>> I've uploaded a new version to
>> http://jeffrey.yasskin.info/cxx/2012/string_ref.html with updates from
>> this thread. I'm planning to send this off to Clark tomorrow, although
>> if
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5sW8yp5i8mo=
/discussion
>> keeps agreeing on string_view, I may switch to that name first.
>>
>> On Wed, Dec 26, 2012 at 3:44 PM, Jeffrey Yasskin <jyasskin@googlers.com>
>> wrote:
>>>
>>> Hi folks,
>>>
>>> I finally have an update for the string_ref proposal, converting it to
>>> a set of changes against the C++14 draft. The most recent version
>>> lives at
>>> https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_re=
f.html,
>>> and I've attached a snapshot.
>>>
>>> The LWG is still deciding whether this should aim for a TS or C++14
>>> (or both?), and feedback from here will help inform that decision.
>>> This paper currently assumes C++14.
>>>
>>>
> Hi,
>
> I remember that someone suggested to remove the clear() member function a=
s
> the behavior doesn't corresponds to string::clear(). I don't remember the
> outcome of this remark.

IIRC, Olaf suggested it (because I didn't take his suggestion to
rename remove_prefix to pop_front), and I decided not to take the
suggestion unless I hear wider agreement.

--=20




.

------=_Part_1171_4498126.1357936843761
Content-Type: text/plain; charset=ISO-8859-1



On Friday, January 11, 2013 11:12:56 AM UTC-8, Ville Voutilainen wrote:
>
>
>
> On 11 January 2013 21:04, <tvan...@gmail.com <javascript:>> wrote:
>
>> I think the issue is auto conversion.
>>
>> Can a function that takes a string_view automatically take a CString, or
>> do I need to call a conversion.
>>
>
> How many people does it help if string_view can do the automatic
> conversion, but string can't? Or do we plan
> to allow string to perform such conversions too?
>

We shouldn't limit new classes just because of limitations on old ones.
Making the same mistake over and over again isn't helping anyone.
Consistency isn't as important as correctness and useful functionality.

Furthermore, that CString->std::wstring conversion would have to be a *copy*,
whereas the conversion to std::wstring_ref/view would not be. That's why
it's far more useful to have this implicit conversion because it takes no
real time or performance. Whereas a conversion to basic_string would be
something significant.

--




------=_Part_1171_4498126.1357936843761
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, January 11, 2013 11:12:56 AM UTC-8, Ville Voutilainen wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br><div class=3D"gmai=
l_quote">On 11 January 2013 21:04,  <span dir=3D"ltr">&lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"mqHaN8nD3tAJ">tvan...@gma=
il.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><div style=3D"width:100%;background:#ffffff;font-size:initial;font-fam=
ily:&quot;Calibri&quot;,&quot;Slate Pro&quot;,&quot;sans-serif&quot;;color:=
#1f497d">I think the issue is auto conversion.&nbsp;</div><div style=3D"wid=
th:100%;background:#ffffff;font-size:initial;font-family:&quot;Calibri&quot=
;,&quot;Slate Pro&quot;,&quot;sans-serif&quot;;color:#1f497d">
<br></div><div style=3D"width:100%;background:#ffffff;font-size:initial;fon=
t-family:&quot;Calibri&quot;,&quot;Slate Pro&quot;,&quot;sans-serif&quot;;c=
olor:#1f497d">Can a function that takes a string_view automatically take a =
CString, or do I need to call a conversion.&nbsp;</div>
</div></blockquote><div><br>How many people does it help if string_view can=
 do the automatic conversion, but string can't? Or do we plan<br>to allow s=
tring to perform such conversions too? </div></div></blockquote><div><br>We=
 shouldn't limit new classes just because of limitations on old ones. Makin=
g the same mistake over and over again isn't helping anyone. Consistency is=
n't as important as correctness and useful functionality.<br><br>Furthermor=
e, that CString-&gt;std::wstring conversion would have to be a <i>copy</i>,=
 whereas the conversion to std::wstring_ref/view would not be. That's why i=
t's far more useful to have this implicit conversion because it takes no re=
al time or performance. Whereas a conversion to basic_string would be somet=
hing significant.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1171_4498126.1357936843761--

.

On 11 January 2013 22:40, Nicol Bolas <jmckesson@gmail.com> wrote:
>> How many people does it help if string_view can do the automatic
>> conversion, but string can't? Or do we plan
>> to allow string to perform such conversions too?
> We shouldn't limit new classes just because of limitations on old ones.
> Making the same mistake over and over again isn't helping anyone.
> Consistency isn't as important as correctness and useful functionality.

Well consistency and convenience would be the argument for having such
conversions
for string as well...

> Furthermore, that CString->std::wstring conversion would have to be a copy,
> whereas the conversion to std::wstring_ref/view would not be. That's why
> it's far more useful to have this implicit conversion because it takes no
> real time or performance. Whereas a conversion to basic_string would be
> something significant.

....but this is a reasonable argument against it.

--




.

Le 11/01/13 21:25, Jeffrey Yasskin a =E9crit :
> On Fri, Jan 11, 2013 at 12:06 PM, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr>  wrote:
>> Le 11/01/13 01:54, Jeffrey Yasskin a =E9crit :
>>
>>> I've uploaded a new version to
>>> http://jeffrey.yasskin.info/cxx/2012/string_ref.html  with updates from
>>> this thread. I'm planning to send this off to Clark tomorrow, although
>>> if
>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5sW8yp5i8m=
o/discussion
>>> keeps agreeing on string_view, I may switch to that name first.
>>>
>>> On Wed, Dec 26, 2012 at 3:44 PM, Jeffrey Yasskin<jyasskin@googlers.com>
>>> wrote:
>>>> Hi folks,
>>>>
>>>> I finally have an update for the string_ref proposal, converting it to
>>>> a set of changes against the C++14 draft. The most recent version
>>>> lives at
>>>> https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_r=
ef.html,
>>>> and I've attached a snapshot.
>>>>
>>>> The LWG is still deciding whether this should aim for a TS or C++14
>>>> (or both?), and feedback from here will help inform that decision.
>>>> This paper currently assumes C++14.
>>>>
>>>>
>> Hi,
>>
>> I remember that someone suggested to remove the clear() member function =
as
>> the behavior doesn't corresponds to string::clear(). I don't remember th=
e
>> outcome of this remark.
> IIRC, Olaf suggested it (because I didn't take his suggestion to
> rename remove_prefix to pop_front), and I decided not to take the
> suggestion unless I hear wider agreement.
>
The same argument that renamed pop_front to remove_prefix should apply,=20
the clear function doesn't has the same behavior on string_ref and=20
string, so either the function is removed or a different name is used.

Vicente


--=20




.

On Fri, Jan 11, 2013 at 9:25 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>> I remember that someone suggested to remove the clear() member function as
>> the behavior doesn't corresponds to string::clear(). I don't remember the
>> outcome of this remark.
>
> IIRC, Olaf suggested it (because I didn't take his suggestion to
> rename remove_prefix to pop_front), and I decided not to take the
> suggestion unless I hear wider agreement.

You make me sound like a bad guy. :p
I was merely surprised with the inconsistency. I don't want clear() to
be renamed.


On Fri, Jan 11, 2013 at 8:12 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> How many people does it help if string_view can do the automatic conversion,
> but string can't? Or do we plan

Lots

> to allow string to perform such conversions too?

I assume we do.

--
Olaf

--




.

Just a comment on the string_ref proposal regarding one of the
comments to the "why not change ... ?" questions:

> Make basic_string_ref<char> mutable
> =85 and use basic_string_ref<const char> for the constant case. The
> constant case is enough more common than the mutable case that it
> needs to be the default. Making the mutable case the default would
> prevent passing string literals into string_ref parameters, [...]
> We could use typedef basic_string_ref<const char> string_ref to
> make the immutable case the default while still supporting the
> mutable case using the same template. I haven't gone this way
> because it would complicate the template's definition without
> significantly helping users.

I think that in any case -- whether mutability will be included or not
-- the name of the pseudo string reference type to a constant string
should reflect the constness: string_cref. So, with mutability support
we could simply define the type aliases like this:

   using string_cref =3D basic_string_ref<const char>;
   using string_ref =3D basic_string_ref<char>;

and without mutability support I would prefer adding 'c' also to
basic_string_ref as well:

   using string_cref =3D basic_string_cref<char>;

just my two cents,
Sebastian

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

------=_Part_32_29730052.1358865471288
Content-Type: text/plain; charset=ISO-8859-1

When one of the stated goals of the proposal is:

Note: The library provides implicit conversions from const charT* and
> std::basic_string<charT, ...> to std::basic_string_ref<charT, ...> so that
> user code can accept just std::basic_string_ref<charT> as a parameter
> wherever a sequence of characters is expected


it seems like a failure to me that many of the string operations are
declared with a pair of const charT* and basic_string_ref overloads. E.g.,

constexpr int compare(basic_string_ref s) const noexcept;
> constexpr int compare(const charT* s) const noexcept;


If a single overload on basic_string_ref isn't good enough for
basic_string_ref members, why should it be acceptable for "user code"?


Add a sub-subclause "x.y.2 basic_string_ref iterator support
> [string.ref.iterators]"
> typedef implementation-defined const_iterator;
> A random-access, contiguous iterator type.


Where is the notion of a contiguous iterator defined?



In the declaration of the interface, const charT& basic_string_ref::at( size_t pos ) const


   1. Is declared with a parameter of type size_t instead of size_type
   2. is not declared constexpr

which is inconsistent with the detailed description later on: constexpr const_reference at( size_type pos ) const.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_32_29730052.1358865471288
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>When one of the stated goals of the proposal is:&nbsp;</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-=
style: solid; padding-left: 1ex;">Note: The library provides implicit conve=
rsions from const charT* and std::basic_string&lt;charT, ...&gt; to std::ba=
sic_string_ref&lt;charT, ...&gt; so that user code can accept just std::bas=
ic_string_ref&lt;charT&gt; as a parameter wherever a sequence of characters=
 is expected</blockquote><div><br></div><div>it seems like a failure to me =
that many of the string operations are declared with a pair of const charT*=
 and basic_string_ref overloads. E.g.,</div><div><br></div><div><pre><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left=
-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: soli=
d; padding-left: 1ex;"><font face=3D"courier new, monospace">constexpr int =
compare(basic_string_ref s) const noexcept;<br>constexpr int compare(const =
charT* s) const noexcept;</font></blockquote><font face=3D"arial, sans-seri=
f"><pre><font face=3D"arial, sans-serif"><br></font></pre>If a single overl=
oad on basic_string_ref isn't good enough for basic_string_ref members, why=
 should it be acceptable for "user code"?<br><br><br></font><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1=
px; border-left-color: rgb(204, 204, 204); border-left-style: solid; paddin=
g-left: 1ex;"><font face=3D"arial, sans-serif">Add a sub-subclause "x.y.2 b=
asic_string_ref iterator support [string.ref.iterators]"<br></font><font fa=
ce=3D"courier new, monospace">typedef implementation-defined const_iterator=
;<br></font><font face=3D"arial, sans-serif">A random-access, contiguous it=
erator type.</font></blockquote><font face=3D"arial, sans-serif"><pre><font=
 face=3D"arial, sans-serif"><br></font></pre>Where is the notion of a conti=
guous iterator defined?</font></pre><pre><font face=3D"arial, sans-serif"><=
br></font></pre><pre><font face=3D"arial, sans-serif"><br></font></pre><pre=
><font face=3D"arial, sans-serif">In the declaration of the interface, </fo=
nt><font face=3D"courier new, monospace">const charT&amp; <span style=3D"fo=
nt-size: 16px; line-height: 24px;">basic_string_ref::at( size_t pos ) const=
</span></font><span style=3D"font-size: 16px; line-height: 24px; font-famil=
y: 'Times New Roman';">&nbsp;</span></pre><pre><ol><li><span style=3D"font-=
family: 'Times New Roman'; font-size: 16px; line-height: 24px;">Is declared=
 with a parameter of type size_t instead of size_type</span></li><li><span =
style=3D"font-family: 'Times New Roman'; font-size: 16px; line-height: 24px=
;">is not declared constexpr</span></li></ol><span style=3D"font-family: 'T=
imes New Roman'; font-size: 16px; line-height: 24px;">which is inconsistent=
 with the detailed description later on: </span><span style=3D"font-family:=
 'courier new', monospace;">constexpr const_reference </span><span style=3D=
"font-family: 'courier new', monospace; font-size: 16px; line-height: 24px;=
">at( size_type pos ) const</span><span style=3D"font-family: 'Times New Ro=
man'; font-size: 16px; line-height: 24px;">.</span></pre><pre><div class=3D=
"attributes" style=3D"margin-left: 2em; white-space: normal; font-size: med=
ium; font-family: 'Times New Roman'; color: rgb(0, 0, 0);"><br></div></pre>=
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_32_29730052.1358865471288--

.

On Tue, Jan 22, 2013 at 4:21 AM, Sebastian Gesemann
<s.gesemann@gmail.com> wrote:
> Just a comment on the string_ref proposal regarding one of the
> comments to the "why not change ... ?" questions:
>
>> Make basic_string_ref<char> mutable
>> =85 and use basic_string_ref<const char> for the constant case. The
>> constant case is enough more common than the mutable case that it
>> needs to be the default. Making the mutable case the default would
>> prevent passing string literals into string_ref parameters, [...]
>> We could use typedef basic_string_ref<const char> string_ref to
>> make the immutable case the default while still supporting the
>> mutable case using the same template. I haven't gone this way
>> because it would complicate the template's definition without
>> significantly helping users.
>
> I think that in any case -- whether mutability will be included or not
> -- the name of the pseudo string reference type to a constant string
> should reflect the constness: string_cref. So, with mutability support
> we could simply define the type aliases like this:
>
>    using string_cref =3D basic_string_ref<const char>;
>    using string_ref =3D basic_string_ref<char>;
>
> and without mutability support I would prefer adding 'c' also to
> basic_string_ref as well:
>
>    using string_cref =3D basic_string_cref<char>;
>
> just my two cents,

The thread you want is
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5sW8yp5i8mo/di=
scussion.
I'm going to ignore naming discussions on this thread.

Thanks,
Jeffrey

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

------=_Part_105_20303454.1359296106220
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, December 27, 2012 12:44:38 AM UTC+1, Jeffrey Yasskin wrote:

> I finally have an update for the string_ref proposal, converting it to
> a set of changes against the C++14 draft. The most recent version
> lives at
> https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
>
> and I've attached a snapshot.
>

> explicit basic_string(basic_string_ref<charT, traits> str, const
Allocator& a = Allocator());

Why is this string constructor explicit?

I expect a lot of code to be like:

string_ref f();

string a = f(); // construction
a = f(); // assignment

I've heard the cost argument, but string construction is known to be
expensive and construction from const char* or const string& is as
expensive but implicit.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_105_20303454.1359296106220
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<span style=3D"font-size: 13px;">On Thursday, December 27, 2012 12:44:38 AM=
 UTC+1, Jeffrey Yasskin wrote:</span><br><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">I finally have an update for the string_ref proposal, converting=
 it to
<br>a set of changes against the C++14 draft. The most recent version
<br>lives at <a href=3D"https://github.com/google/cxx-std-draft/blob/string=
-ref-paper/string_ref.html" target=3D"_blank">https://github.com/google/cxx=
-<wbr>std-draft/blob/string-ref-<wbr>paper/string_ref.html</a>,
<br>and I've attached a snapshot.
<br></blockquote><div><br></div><div>&gt;&nbsp;<span style=3D"white-space: =
inherit; color: rgb(0, 0, 0); font-size: 13px;">explicit basic_string(basic=
_string_ref&lt;charT, traits&gt; str, const Allocator&amp; a =3D Allocator(=
));</span><span style=3D"font-size: 13px;">&nbsp;</span></div><div><span st=
yle=3D"font-size: 13px;"><br></span></div><div><span style=3D"font-size: 13=
px;">Why is this string constructor explicit?&nbsp;</span></div><div><br></=
div><div>I expect a lot of code to be like:</div><div><br></div><div>string=
_ref f();</div><div><br></div><div>string a =3D f(); // construction</div><=
div>a =3D f(); // assignment</div><div><br></div><div>I've heard the cost a=
rgument, but string construction is known to be expensive and construction =
from const char* or const string&amp; is as expensive but implicit.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_105_20303454.1359296106220--

.

On Tue, Jan 22, 2013 at 6:37 AM,  <cartec69@gmail.com> wrote:
> When one of the stated goals of the proposal is:
>
>> Note: The library provides implicit conversions from const charT* and
>> std::basic_string<charT, ...> to std::basic_string_ref<charT, ...> so that
>> user code can accept just std::basic_string_ref<charT> as a parameter
>> wherever a sequence of characters is expected
>
>
> it seems like a failure to me that many of the string operations are
> declared with a pair of const charT* and basic_string_ref overloads. E.g.,
>
>> constexpr int compare(basic_string_ref s) const noexcept;
>> constexpr int compare(const charT* s) const noexcept;
>
>
> If a single overload on basic_string_ref isn't good enough for
> basic_string_ref members, why should it be acceptable for "user code"?

The standard has to be much more careful about allowing optimization
than user code does. That is, if I don't add the charT* overload, then
implementations aren't allowed to optimize the case of a very long
charT* string for which it could bail out of compare() before
calculating the whole length. This was requested in the LWG discussion
in Portland.

In the codebases I've seen that actually use string_ref (LLVM, Google,
and Chromium), the worry about long charT* strings has never been an
actual problem, and functions are just declared with a single
string_ref overload. The worry about backward-compatibility that
forced all the non-basic_string_ref members to also include a
basic_string overload has also never been a problem with these
codebases.

>> Add a sub-subclause "x.y.2 basic_string_ref iterator support
>> [string.ref.iterators]"
>> typedef implementation-defined const_iterator;
>> A random-access, contiguous iterator type.
>
>
> Where is the notion of a contiguous iterator defined?

It wasn't. Is now. Thanks. :)

> In the declaration of the interface, const charT& basic_string_ref::at(
> size_t pos ) const
>
> Is declared with a parameter of type size_t instead of size_type
> is not declared constexpr
>
> which is inconsistent with the detailed description later on: constexpr
> const_reference at( size_type pos ) const.

Also fixed. Thanks. Sorry for the long delay in getting back to you.

http://htmlpreview.github.com/?https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_view.html

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_1038_1075920302.1412969624220
Content-Type: text/plain; charset=UTF-8



On Sunday, January 27, 2013 3:15:06 PM UTC+1, Olaf van der Spek wrote:
>
> On Thursday, December 27, 2012 12:44:38 AM UTC+1, Jeffrey Yasskin wrote:
>
>> I finally have an update for the string_ref proposal, converting it to
>> a set of changes against the C++14 draft. The most recent version
>> lives at
>> https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
>>
>> and I've attached a snapshot.
>>
>
> > explicit basic_string(basic_string_ref<charT, traits> str, const
> Allocator& a = Allocator());
>
> Why is this string constructor explicit?
>
> I expect a lot of code to be like:
>
> string_ref f();
>
> string a = f(); // construction
> a = f(); // assignment
>
> I've heard the cost argument, but string construction is known to be
> expensive and construction from const char* or const string& is as
> expensive but implicit.
>

Somebody?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Sunday, January 27, 2013 3:15:06 PM UTC+1, Olaf=
 van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><span styl=
e=3D"font-size:13px">On Thursday, December 27, 2012 12:44:38 AM UTC+1, Jeff=
rey Yasskin wrote:</span><br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I fina=
lly have an update for the string_ref proposal, converting it to
<br>a set of changes against the C++14 draft. The most recent version
<br>lives at <a href=3D"https://github.com/google/cxx-std-draft/blob/string=
-ref-paper/string_ref.html" target=3D"_blank" onmousedown=3D"this.href=3D'h=
ttps://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgoogle%2Fcxx-std-d=
raft%2Fblob%2Fstring-ref-paper%2Fstring_ref.html\46sa\75D\46sntz\0751\46usg=
\75AFQjCNGtRPU_iLcHkqfZ_4A5rIXBNy2gyA';return true;" onclick=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgoogle%2Fcxx-=
std-draft%2Fblob%2Fstring-ref-paper%2Fstring_ref.html\46sa\75D\46sntz\0751\=
46usg\75AFQjCNGtRPU_iLcHkqfZ_4A5rIXBNy2gyA';return true;">https://github.co=
m/google/cxx-<wbr>std-draft/blob/string-ref-<wbr>paper/string_ref.html</a>,
<br>and I've attached a snapshot.
<br></blockquote><div><br></div><div>&gt;&nbsp;<span style=3D"white-space:i=
nherit;color:rgb(0,0,0);font-size:13px">explicit basic_string(basic_string_=
ref&lt;<wbr>charT, traits&gt; str, const Allocator&amp; a =3D Allocator());=
</span><span style=3D"font-size:13px">&nbsp;</span></div><div><span style=
=3D"font-size:13px"><br></span></div><div><span style=3D"font-size:13px">Wh=
y is this string constructor explicit?&nbsp;</span></div><div><br></div><di=
v>I expect a lot of code to be like:</div><div><br></div><div>string_ref f(=
);</div><div><br></div><div>string a =3D f(); // construction</div><div>a =
=3D f(); // assignment</div><div><br></div><div>I've heard the cost argumen=
t, but string construction is known to be expensive and construction from c=
onst char* or const string&amp; is as expensive but implicit.</div></blockq=
uote><div><br></div><div>Somebody?&nbsp;</div></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1038_1075920302.1412969624220--

.

On 10 October 2014 22:33, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>
>
> On Sunday, January 27, 2013 3:15:06 PM UTC+1, Olaf van der Spek wrote:
>>
>> On Thursday, December 27, 2012 12:44:38 AM UTC+1, Jeffrey Yasskin wrote:
>>>
>>> I finally have an update for the string_ref proposal, converting it to
>>> a set of changes against the C++14 draft. The most recent version
>>> lives at
>>> https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
>>> and I've attached a snapshot.
>>
>>
>> > explicit basic_string(basic_string_ref<charT, traits> str, const
>> > Allocator& a = Allocator());
>>
>> Why is this string constructor explicit?
>>
>> I expect a lot of code to be like:
>>
>> string_ref f();
>>
>> string a = f(); // construction
>> a = f(); // assignment
>>
>> I've heard the cost argument, but string construction is known to be
>> expensive and construction from const char* or const string& is as expensive
>> but implicit.
>
>
> Somebody?

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4081.html#string.view.ops
"This conversion is explicit to avoid accidental O(N) operations on
type mismatches."

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Fri, Oct 10, 2014 at 10:41 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>>> Why is this string constructor explicit?
>>>
>>> I expect a lot of code to be like:
>>>
>>> string_ref f();
>>>
>>> string a = f(); // construction
>>> a = f(); // assignment
>>>
>>> I've heard the cost argument, but string construction is known to be
>>> expensive and construction from const char* or const string& is as expensive
>>> but implicit.
>>
>>
>> Somebody?
>
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4081.html#string.view.ops
> "This conversion is explicit to avoid accidental O(N) operations on
> type mismatches."

That's what I said. Just to be clear, this is inconsistant with the
string constructor from char* isn't it?


--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 11 October 2014 15:31, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>>> I've heard the cost argument, but string construction is known to be
>>>> expensive and construction from const char* or const string& is as expensive
>>>> but implicit.
>>>
>>>
>>> Somebody?
>>
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4081.html#string.view.ops
>> "This conversion is explicit to avoid accidental O(N) operations on
>> type mismatches."
>
> That's what I said. Just to be clear, this is inconsistant with the
> string constructor from char* isn't it?

Oh, pardon me, I misread that signature to be capable of converting to a string
with a different character type. Yes, it's inconsistent with the
string constructor
from char*, apparently string_view is trying to be more protective. Do remember
that string constructor from char* was made non-explicit because it was thought
very common to invoke a
void foo(const std::string&);
with
foo("literal");
Apparently the same kind of commonality hasn't been convincing for string_view.
I'll dig through some committee discussions to see what, if any, has been said
about this point.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1409_1638260789.1414123019907
Content-Type: text/plain; charset=UTF-8



On Friday, October 10, 2014 4:41:35 PM UTC-4, Ville Voutilainen wrote:
>
>
>
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4081.html#string.view.ops
> "This conversion is explicit to avoid accidental O(N) operations on
> type mismatches."
>

I'm not sure I agree with this decision. In my view (pun not intended),
string_view should become the default way to pass around const references
to string. That is passing around const std::string& and const char* will
disappear in favor of std::string_view (by value). Similarly we won't pass
around const std::vector<T>& anymore but instead std::array_view<T>. Not
only are the views more efficient (one less indirection), but they also
make interfaces much more flexible by accepting a range like concept
instead of hard container type. Having to say foo(std::string_view("abc"))
is very clumsy.

The most common use of the const char* constructor is for string literals.
Constructing a string_view with a string literal will not be O(N) because
the compiler will be able to inline the call. Constructing a string_view
with an arbitrary const char* will require an O(N) strlen() but that's
already the reality of dealing with null terminated strings. You call
strlen() over and over again at each level of the call stack. This is one
reason why this proposal is so important and why null terminated strings
need to go away. Once string_view becomes the standard, const char* will
start to go away except for C compatibility and other edge cases and the
O(N) issue will be a corner case, not a real problem.


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Friday, October 10, 2014 4:41:35 PM UTC-4, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><a hre=
f=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4081.html#string.=
view.ops" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.c=
om/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2=
F2014%2Fn4081.html%23string.view.ops\46sa\75D\46sntz\0751\46usg\75AFQjCNEGM=
Kpi4uxofx38wndLMotH_fRvZg';return true;" onclick=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2=
Fpapers%2F2014%2Fn4081.html%23string.view.ops\46sa\75D\46sntz\0751\46usg\75=
AFQjCNEGMKpi4uxofx38wndLMotH_fRvZg';return true;">http://open-std.org/JTC1/=
SC22/<wbr>WG21/docs/papers/2014/n4081.<wbr>html#string.view.ops</a>
<br>"This conversion is explicit to avoid accidental O(N) operations on
<br>type mismatches."
<br></blockquote><div><br></div><div>I'm not sure I agree with this decisio=
n. In my view (pun not intended), string_view should become the default way=
 to pass around const references to string. That is passing around const st=
d::string&amp; and const char* will disappear in favor of std::string_view =
(by value). Similarly we won't pass around const std::vector&lt;T&gt;&amp; =
anymore but instead std::array_view&lt;T&gt;. Not only are the views more e=
fficient (one less indirection), but they also make interfaces much more fl=
exible by accepting a range like concept instead of hard container type. Ha=
ving to say foo(std::string_view("abc")) is very clumsy.</div><div><br></di=
v><div>The most common use of the const char* constructor is for string lit=
erals. Constructing a string_view with a string literal will not be O(N) be=
cause the compiler will be able to inline the call. Constructing a string_v=
iew with an arbitrary const char* will require an O(N) strlen() but that's =
already the reality of dealing with null terminated strings. You call strle=
n() over and over again at each level of the call stack. This is one reason=
 why this proposal is so important and why null terminated strings need to =
go away. Once string_view becomes the standard, const char* will start to g=
o away except for C compatibility and other edge cases and the O(N) issue w=
ill be a corner case, not a real problem.</div><div><br></div><div><br></di=
v></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1409_1638260789.1414123019907--

.

------=_Part_1339_356498802.1414124086399
Content-Type: text/plain; charset=UTF-8



On Saturday, October 11, 2014 8:42:38 AM UTC-4, Ville Voutilainen wrote:
>
> On 11 October 2014 15:31, Olaf van der Spek <olafv...@gmail.com
> <javascript:>> wrote:
> >>>> I've heard the cost argument, but string construction is known to be
> >>>> expensive and construction from const char* or const string& is as
> expensive
> >>>> but implicit.
> >>>
> >>>
> >>> Somebody?
> >>
> >>
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4081.html#string.view.ops
> >> "This conversion is explicit to avoid accidental O(N) operations on
> >> type mismatches."
> >
> > That's what I said. Just to be clear, this is inconsistant with the
> > string constructor from char* isn't it?
>
> Oh, pardon me, I misread that signature to be capable of converting to a
> string
> with a different character type. Yes, it's inconsistent with the
> string constructor
> from char*, apparently string_view is trying to be more protective. Do
> remember
> that string constructor from char* was made non-explicit because it was
> thought
> very common to invoke a
> void foo(const std::string&);
> with
> foo("literal");
> Apparently the same kind of commonality hasn't been convincing for
> string_view.
> I'll dig through some committee discussions to see what, if any, has been
> said
> about this point.
>

By value string_view should become the defacto way to pass around read only
strings and const string& and const char* will go away. Similarly, we won't
pass around const vector<T>& anymore in favor of array_view<T> (by value).

Passing the views by value is more efficient because there is one less
indirection. Its the same as directly passing the raw pointer to the
character array + the length instead of passing a pointer to the pointer to
the character array (const string&). More importantly, it also makes our
interfaces much more flexible because the string data can be sourced from
anything (string, char[], char*, user defined string class, etc..).

The most common use case of a char* constructor is for string literals. In
this use case, the call strlen() will trivially be optimized out. When
string_view becomes standard practice, const char* will show up less often
(for legacy code / C compatibility) and thus the potential to have sneaky
O(N) strlen() calls hidden in your code will be reduced.

Finally, when users really do want to construct from an arbitrary const
char*, they should know already that they have to worry about strlen()
calls because that's the nature of null terminated strings. You have to
call strlen() over and over again at each level of the call stack.

In order to make string_view the defacto string type, it must be easy to
use. If we cannot say foo("abc") but instead have to say
foo(string_view("abc")), its going to be a big impediment to string_view. I
believe in this case, ease of use should win out over potential performance
bugs due to hidden strlen() calls, which will go away when string_view is
used to be the normal way to represent read only strings.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Saturday, October 11, 2014 8:42:38 AM UTC-4, Vi=
lle Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 11 Oc=
tober 2014 15:31, Olaf van der Spek &lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"4l4FVvcDdPsJ" onmousedown=3D"this.href=3D'j=
avascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;=
">olafv...@gmail.com</a>&gt; wrote:
<br>&gt;&gt;&gt;&gt; I've heard the cost argument, but string construction =
is known to be
<br>&gt;&gt;&gt;&gt; expensive and construction from const char* or const s=
tring&amp; is as expensive
<br>&gt;&gt;&gt;&gt; but implicit.
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; Somebody?
<br>&gt;&gt;
<br>&gt;&gt; <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014=
/n4081.html#string.view.ops" target=3D"_blank" onmousedown=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG2=
1%2Fdocs%2Fpapers%2F2014%2Fn4081.html%23string.view.ops\46sa\75D\46sntz\075=
1\46usg\75AFQjCNEGMKpi4uxofx38wndLMotH_fRvZg';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FS=
C22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4081.html%23string.view.ops\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNEGMKpi4uxofx38wndLMotH_fRvZg';return true;">http:/=
/open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2014/n4081.<wbr>html#string.v=
iew.ops</a>
<br>&gt;&gt; "This conversion is explicit to avoid accidental O(N) operatio=
ns on
<br>&gt;&gt; type mismatches."
<br>&gt;
<br>&gt; That's what I said. Just to be clear, this is inconsistant with th=
e
<br>&gt; string constructor from char* isn't it?
<br>
<br>Oh, pardon me, I misread that signature to be capable of converting to =
a string
<br>with a different character type. Yes, it's inconsistent with the
<br>string constructor
<br>from char*, apparently string_view is trying to be more protective. Do =
remember
<br>that string constructor from char* was made non-explicit because it was=
 thought
<br>very common to invoke a
<br>void foo(const std::string&amp;);
<br>with
<br>foo("literal");
<br>Apparently the same kind of commonality hasn't been convincing for stri=
ng_view.
<br>I'll dig through some committee discussions to see what, if any, has be=
en said
<br>about this point.
<br></blockquote><div><br></div><div>By value string_view should become the=
 defacto way to pass around read only strings and const string&amp; and con=
st char* will go away. Similarly, we won't pass around const vector&lt;T&gt=
;&amp; anymore in favor of array_view&lt;T&gt; (by value).&nbsp;</div><div>=
<br></div><div>Passing the views by value is more efficient because there i=
s one less indirection. Its the same as directly passing the raw pointer to=
 the character array + the length instead of passing a pointer to the point=
er to the character array (const string&amp;). More importantly, it also ma=
kes our interfaces much more flexible because the string data can be source=
d from anything (string, char[], char*, user defined string class, etc..).<=
/div><div><br></div><div><span style=3D"font-size: 13.1428575515747px;">The=
 most common use case of a char* constructor is for string literals. In thi=
s use case, the call strlen() will trivially be optimized out. When string_=
view becomes standard practice, const char* will show up less often (for le=
gacy code / C compatibility) and thus the potential to have sneaky O(N) str=
len() calls hidden in your code will be reduced.</span></div><div><span sty=
le=3D"font-size: 13.1428575515747px;"><br></span></div><div><span style=3D"=
font-size: 13.1428575515747px;">Finally, when users really do want to const=
ruct from an arbitrary const char*, they should know already that they have=
 to worry about strlen() calls because that's the nature of null terminated=
 strings. You have to call strlen() over and over again at each level of th=
e call stack.</span></div><div><span style=3D"font-size: 13.1428575515747px=
;"><br></span></div><div><span style=3D"font-size: 13.1428575515747px;">In =
order to make string_view the defacto string type, it must be easy to use. =
If we cannot say foo("abc") but instead have to say foo(string_view("abc"))=
, its going to be a big impediment to string_view. I believe in this case, =
ease of use should win out over potential performance bugs due to hidden st=
rlen() calls, which will go away when string_view is used to be the normal =
way to represent read only strings.</span></div></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1339_356498802.1414124086399--

.

On Fri, Oct 24, 2014 at 5:56 AM, Matthew Fioravante
<fmatthew5876@gmail.com> wrote:
> I'm not sure I agree with this decision. In my view (pun not intended),
> string_view should become the default way to pass around const references to
> string. That is passing around const std::string& and const char* will
> disappear in favor of std::string_view (by value). Similarly we won't pass
> around const std::vector<T>& anymore but instead std::array_view<T>. Not

std::array_view<const T> ;)

> only are the views more efficient (one less indirection), but they also make
> interfaces much more flexible by accepting a range like concept instead of
> hard container type. Having to say foo(std::string_view("abc")) is very
> clumsy.

foo("abc"sv) might work, but I think foo("abc") is a bit cleaner.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Il giorno 25/ott/2014, alle ore 16:43, Olaf van der Spek <olafvdspek@gmail.com> ha scritto:

> On Fri, Oct 24, 2014 at 5:56 AM, Matthew Fioravante
> <fmatthew5876@gmail.com> wrote:
>> I'm not sure I agree with this decision. In my view (pun not intended),
>> string_view should become the default way to pass around const references to
>> string. That is passing around const std::string& and const char* will
>> disappear in favor of std::string_view (by value). Similarly we won't pass
>> around const std::vector<T>& anymore but instead std::array_view<T>. Not
>
> std::array_view<const T> ;)
>
>> only are the views more efficient (one less indirection), but they also make
>> interfaces much more flexible by accepting a range like concept instead of
>> hard container type. Having to say foo(std::string_view("abc")) is very
>> clumsy.
>
> foo("abc"sv) might work, but I think foo("abc") is a bit cleaner.


Hi all,

In my opinion, the inability to call a function with a string literal without extra syntax
is going to kill the usage of string_view, especially in code written by novices or
not so expert programmers, who instead are the people who should be most
encouraged to use safe and high-level functionalities.

The O(n) strlen() call on string literal is already a false problem. Compilers inline
calls like that.

But even if we're worried by the cost of a non-inlined strlen() being overlooked,
why don't we provide a non-explicit constructor that specifically works only with
string literals? i.e.

template<size_t N>
basic_string_view(CharT literal[N]);

This way, conversions from string literals would be convenient and costly conversions
from unknown-length strings would be safely made explicit.

What are the negative aspects of this solution?

Bye,
Nicola

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Sat, Oct 25, 2014 at 5:03 PM, Nicola Gigante
<nicola.gigante@gmail.com> wrote:
> template<size_t N>
> basic_string_view(CharT literal[N]);
>
> This way, conversions from string literals would be convenient and costly conversions
> from unknown-length strings would be safely made explicit.
>
> What are the negative aspects of this solution?

It 'works' for arrays (buffers) too but doesn't use the right size
unless the string consumes the entire buffer.


--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Il giorno 25/ott/2014, alle ore 17:09, Olaf van der Spek <olafvdspek@gmail.com> ha scritto:

> On Sat, Oct 25, 2014 at 5:03 PM, Nicola Gigante
> <nicola.gigante@gmail.com> wrote:
>> template<size_t N>
>> basic_string_view(CharT literal[N]);
>>
>> This way, conversions from string literals would be convenient and costly conversions
>> from unknown-length strings would be safely made explicit.
>>
>> What are the negative aspects of this solution?
>
> It 'works' for arrays (buffers) too but doesn't use the right size
> unless the string consumes the entire buffer.
>

Good point!

Bye,
Nicola

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_3049_173014227.1414380287807
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Saturday, October 25, 2014 11:04:00 AM UTC-4, Nicola Gigante wrote:
>
>
> Il giorno 25/ott/2014, alle ore 16:43, Olaf van der Spek <
> olafv...@gmail.com <javascript:>> ha scritto:=20
>
> > On Fri, Oct 24, 2014 at 5:56 AM, Matthew Fioravante=20
> > <fmatth...@gmail.com <javascript:>> wrote:=20
> >> I'm not sure I agree with this decision. In my view (pun not intended)=
,=20
> >> string_view should become the default way to pass around const=20
> references to=20
> >> string. That is passing around const std::string& and const char* will=
=20
> >> disappear in favor of std::string_view (by value). Similarly we won't=
=20
> pass=20
> >> around const std::vector<T>& anymore but instead std::array_view<T>.=
=20
> Not=20
> >=20
> > std::array_view<const T> ;)=20
> >=20
> >> only are the views more efficient (one less indirection), but they als=
o=20
> make=20
> >> interfaces much more flexible by accepting a range like concept instea=
d=20
> of=20
> >> hard container type. Having to say foo(std::string_view("abc")) is ver=
y=20
> >> clumsy.=20
> >=20
> > foo("abc"sv) might work, but I think foo("abc") is a bit cleaner.=20
>
>
> Hi all,=20
>
> In my opinion, the inability to call a function with a string literal=20
> without extra syntax=20
> is going to kill the usage of string_view, especially in code written by=
=20
> novices or=20
> not so expert programmers, who instead are the people who should be most=
=20
> encouraged to use safe and high-level functionalities.=20
>
> The O(n) strlen() call on string literal is already a false problem.=20
> Compilers inline=20
> calls like that.=20
>
> But even if we=E2=80=99re worried by the cost of a non-inlined strlen() b=
eing=20
> overlooked,=20
> why don=E2=80=99t we provide a non-explicit constructor that specifically=
 works=20
> only with=20
> string literals? i.e.=20
>
> template<size_t N>=20
> basic_string_view(CharT literal[N]);=20
>
> This way, conversions from string literals would be convenient and costly=
=20
> conversions=20
> from unknown-length strings would be safely made explicit.=20
>
> What are the negative aspects of this solution?=20
>

CharT[N] objects can't be passed by value. You'd want:

template<size_t N>=20
basic_string_view(CharT const (&literal)[N]);=20

But then you still wouldn't have something "that specifically works only=20
with string literals". Below, g() calls the so-called "string literal"=20
constructor, but not with a string literal.

struct X { char buf[16]; };

void f(std::string_view s);
void g(const X& x) { f(x.buf); }   // x.buf: not a string literal

--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>On Saturday, October 25, 2014 11:04:00 AM UTC-4, N=
icola Gigante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Il giorno 25/ott/2014, alle ore 16:43, Olaf van der Spek &lt;<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"XHTkazOiwZQJ" onmo=
usedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;">olafv...@gmail.com</a>&gt; ha scritto:
<br>
<br>&gt; On Fri, Oct 24, 2014 at 5:56 AM, Matthew Fioravante
<br>&gt; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"XHTkazOiwZQJ" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">fmatth...@gmail.com</a>&g=
t; wrote:
<br>&gt;&gt; I'm not sure I agree with this decision. In my view (pun not i=
ntended),
<br>&gt;&gt; string_view should become the default way to pass around const=
 references to
<br>&gt;&gt; string. That is passing around const std::string&amp; and cons=
t char* will
<br>&gt;&gt; disappear in favor of std::string_view (by value). Similarly w=
e won't pass
<br>&gt;&gt; around const std::vector&lt;T&gt;&amp; anymore but instead std=
::array_view&lt;T&gt;. Not
<br>&gt;=20
<br>&gt; std::array_view&lt;const T&gt; ;)
<br>&gt;=20
<br>&gt;&gt; only are the views more efficient (one less indirection), but =
they also make
<br>&gt;&gt; interfaces much more flexible by accepting a range like concep=
t instead of
<br>&gt;&gt; hard container type. Having to say foo(std::string_view("abc")=
) is very
<br>&gt;&gt; clumsy.
<br>&gt;=20
<br>&gt; foo("abc"sv) might work, but I think foo("abc") is a bit cleaner.
<br>
<br>
<br>Hi all,=20
<br>
<br>In my opinion, the inability to call a function with a string literal w=
ithout extra syntax=20
<br>is going to kill the usage of string_view, especially in code written b=
y novices or
<br>not so expert programmers, who instead are the people who should be mos=
t=20
<br>encouraged to use safe and high-level functionalities.
<br>
<br>The O(n) strlen() call on string literal is already a false problem. Co=
mpilers inline
<br>calls like that.
<br>
<br>But even if we=E2=80=99re worried by the cost of a non-inlined strlen()=
 being overlooked,
<br>why don=E2=80=99t we provide a non-explicit constructor that specifical=
ly works only with=20
<br>string literals? i.e.
<br>
<br>template&lt;size_t N&gt;
<br>basic_string_view(CharT literal[N]);
<br>
<br>This way, conversions from string literals would be convenient and cost=
ly conversions
<br>from unknown-length strings would be safely made explicit.
<br>
<br>What are the negative aspects of this solution?
<br>
</blockquote><div><br></div><div>CharT[N] objects can't be passed by value.=
 You'd want:<br></div><div><br></div><div>template&lt;size_t N&gt;&nbsp;<br=
>basic_string_view(CharT const (&amp;literal)[N]);&nbsp;</div><div><br></di=
v><div>But then you still wouldn't have something "that specifically works =
only with string literals". Below, g() calls the so-called "string literal"=
 constructor, but not with a string literal.</div><div><br></div><div>struc=
t X { char buf[16]; };</div><div><br></div><div>void f(std::string_view s);=
<br></div><div>void g(const X&amp; x) { f(x.buf); } &nbsp; // x.buf: not a =
string literal</div><div><br></div></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3049_173014227.1414380287807--

.

------=_Part_1304_792908951.1414423266778
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Different semantics for const char[], and const char* seems like a bad idea=
=20
to me. Its very easy to substitute one for the other and get surprising=20
results. Taking the compile time length for const char[N] is also a mistake=
=20
because we don't know the intended semantics of the input array with=20
respect to null termination.
=20
Because C made the mistake of using char pointers/arrays to represent the 2=
=20
different concepts of "array of characters" and also "string" we=20
basically are forced to assume any character pointer or array used to=20
initialize a string_view is a null terminated string. It's very unfortunate=
=20
that the type of string_literals are C arrays and not some special=20
string_literal type.

On Sunday, October 26, 2014 11:24:47 PM UTC-4, Billy Donahue wrote:

>
>
> On Saturday, October 25, 2014 11:04:00 AM UTC-4, Nicola Gigante wrote:
>>
>>
>> Il giorno 25/ott/2014, alle ore 16:43, Olaf van der Spek <
>> olafv...@gmail.com> ha scritto:=20
>>
>> > On Fri, Oct 24, 2014 at 5:56 AM, Matthew Fioravante=20
>> > <fmatth...@gmail.com> wrote:=20
>> >> I'm not sure I agree with this decision. In my view (pun not=20
>> intended),=20
>> >> string_view should become the default way to pass around const=20
>> references to=20
>> >> string. That is passing around const std::string& and const char* wil=
l=20
>> >> disappear in favor of std::string_view (by value). Similarly we won't=
=20
>> pass=20
>> >> around const std::vector<T>& anymore but instead std::array_view<T>.=
=20
>> Not=20
>> >=20
>> > std::array_view<const T> ;)=20
>> >=20
>> >> only are the views more efficient (one less indirection), but they=20
>> also make=20
>> >> interfaces much more flexible by accepting a range like concept=20
>> instead of=20
>> >> hard container type. Having to say foo(std::string_view("abc")) is=20
>> very=20
>> >> clumsy.=20
>> >=20
>> > foo("abc"sv) might work, but I think foo("abc") is a bit cleaner.=20
>>
>>
>> Hi all,=20
>>
>> In my opinion, the inability to call a function with a string literal=20
>> without extra syntax=20
>> is going to kill the usage of string_view, especially in code written by=
=20
>> novices or=20
>> not so expert programmers, who instead are the people who should be most=
=20
>> encouraged to use safe and high-level functionalities.=20
>>
>> The O(n) strlen() call on string literal is already a false problem.=20
>> Compilers inline=20
>> calls like that.=20
>>
>> But even if we=E2=80=99re worried by the cost of a non-inlined strlen() =
being=20
>> overlooked,=20
>> why don=E2=80=99t we provide a non-explicit constructor that specificall=
y works=20
>> only with=20
>> string literals? i.e.=20
>>
>> template<size_t N>=20
>> basic_string_view(CharT literal[N]);=20
>>
>> This way, conversions from string literals would be convenient and costl=
y=20
>> conversions=20
>> from unknown-length strings would be safely made explicit.=20
>>
>> What are the negative aspects of this solution?=20
>>
>
> CharT[N] objects can't be passed by value. You'd want:
>
> template<size_t N>=20
> basic_string_view(CharT const (&literal)[N]);=20
>
> But then you still wouldn't have something "that specifically works only=
=20
> with string literals". Below, g() calls the so-called "string literal"=20
> constructor, but not with a string literal.
>
> struct X { char buf[16]; };
>
> void f(std::string_view s);
> void g(const X& x) { f(x.buf); }   // x.buf: not a string literal
>
>

--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><div>Different semantics for const char[], and const char*=
 seems like a bad idea to me. Its very easy to substitute one for the other=
 and get surprising results. Taking the compile time length for const char[=
N] is also a mistake because&nbsp;we don't know the intended semantics of t=
he input array with respect to null termination.</div><div>&nbsp;</div><div=
>Because C made the mistake of using char pointers/arrays to&nbsp;represent=
 the 2 different concepts of&nbsp;"array of characters" and also "string" w=
e basically&nbsp;are forced&nbsp;to assume any character pointer or array u=
sed to initialize a string_view is a null terminated string. It's very unfo=
rtunate that the type of string_literals are C arrays and not some special =
string_literal type.</div><div><br>On Sunday, October 26, 2014 11:24:47 PM =
UTC-4, Billy Donahue wrote:</div><blockquote style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;" class=3D"gmail_quote"><div dir=3D"l=
tr"><br><br>On Saturday, October 25, 2014 11:04:00 AM UTC-4, Nicola Gigante=
 wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; b=
order-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-s=
tyle: solid;" class=3D"gmail_quote">
<br>Il giorno 25/ott/2014, alle ore 16:43, Olaf van der Spek &lt;<a>olafv..=
..@gmail.com</a>&gt; ha scritto:
<br>
<br>&gt; On Fri, Oct 24, 2014 at 5:56 AM, Matthew Fioravante
<br>&gt; &lt;<a>fmatth...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; I'm not sure I agree with this decision. In my view (pun not i=
ntended),
<br>&gt;&gt; string_view should become the default way to pass around const=
 references to
<br>&gt;&gt; string. That is passing around const std::string&amp; and cons=
t char* will
<br>&gt;&gt; disappear in favor of std::string_view (by value). Similarly w=
e won't pass
<br>&gt;&gt; around const std::vector&lt;T&gt;&amp; anymore but instead std=
::array_view&lt;T&gt;. Not
<br>&gt;=20
<br>&gt; std::array_view&lt;const T&gt; ;)
<br>&gt;=20
<br>&gt;&gt; only are the views more efficient (one less indirection), but =
they also make
<br>&gt;&gt; interfaces much more flexible by accepting a range like concep=
t instead of
<br>&gt;&gt; hard container type. Having to say foo(std::string_view("abc")=
) is very
<br>&gt;&gt; clumsy.
<br>&gt;=20
<br>&gt; foo("abc"sv) might work, but I think foo("abc") is a bit cleaner.
<br>
<br>
<br>Hi all,=20
<br>
<br>In my opinion, the inability to call a function with a string literal w=
ithout extra syntax=20
<br>is going to kill the usage of string_view, especially in code written b=
y novices or
<br>not so expert programmers, who instead are the people who should be mos=
t=20
<br>encouraged to use safe and high-level functionalities.
<br>
<br>The O(n) strlen() call on string literal is already a false problem. Co=
mpilers inline
<br>calls like that.
<br>
<br>But even if we=E2=80=99re worried by the cost of a non-inlined strlen()=
 being overlooked,
<br>why don=E2=80=99t we provide a non-explicit constructor that specifical=
ly works only with=20
<br>string literals? i.e.
<br>
<br>template&lt;size_t N&gt;
<br>basic_string_view(CharT literal[N]);
<br>
<br>This way, conversions from string literals would be convenient and cost=
ly conversions
<br>from unknown-length strings would be safely made explicit.
<br>
<br>What are the negative aspects of this solution?
<br>
</blockquote><div><br></div><div>CharT[N] objects can't be passed by value.=
 You'd want:<br></div><div><br></div><div>template&lt;size_t N&gt;&nbsp;<br=
>basic_string_view(CharT const (&amp;literal)[N]);&nbsp;</div><div><br></di=
v><div>But then you still wouldn't have something "that specifically works =
only with string literals". Below, g() calls the so-called "string literal"=
 constructor, but not with a string literal.</div><div><br></div><div>struc=
t X { char buf[16]; };</div><div><br></div><div>void f(std::string_view s);=
<br></div><div>void g(const X&amp; x) { f(x.buf); } &nbsp; // x.buf: not a =
string literal</div><div><br></div></div></blockquote></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1304_792908951.1414423266778--

.

--Apple-Mail=_FCBDFE70-2897-442E-9F07-25517C0A9CFB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

On Oct 25, 2014, at 8:03 AM, Nicola Gigante <nicola.gigante@gmail.com> wrot=
e:

>=20
> Il giorno 25/ott/2014, alle ore 16:43, Olaf van der Spek <olafvdspek@gmai=
l.com> ha scritto:
>=20
>> On Fri, Oct 24, 2014 at 5:56 AM, Matthew Fioravante
>> <fmatthew5876@gmail.com> wrote:
>>> I'm not sure I agree with this decision. In my view (pun not intended),
>>> string_view should become the default way to pass around const referenc=
es to
>>> string. That is passing around const std::string& and const char* will
>>> disappear in favor of std::string_view (by value). Similarly we won't p=
ass
>>> around const std::vector<T>& anymore but instead std::array_view<T>. No=
t
>>=20
>> std::array_view<const T> ;)
>>=20
>>> only are the views more efficient (one less indirection), but they also=
 make
>>> interfaces much more flexible by accepting a range like concept instead=
 of
>>> hard container type. Having to say foo(std::string_view("abc")) is very
>>> clumsy.
>>=20
>> foo("abc"sv) might work, but I think foo("abc") is a bit cleaner.
>=20
>=20
> Hi all,=20
>=20
> In my opinion, the inability to call a function with a string literal wit=
hout extra syntax=20
> is going to kill the usage of string_view, especially in code written by =
novices or
> not so expert programmers, who instead are the people who should be most=
=20
> encouraged to use safe and high-level functionalities.
>=20
> The O(n) strlen() call on string literal is already a false problem. Comp=
ilers inline
> calls like that.
>=20
> But even if we're worried by the cost of a non-inlined strlen() being ove=
rlooked,
> why don't we provide a non-explicit constructor that specifically works o=
nly with=20
> string literals? i.e.
>=20
> template<size_t N>
> basic_string_view(CharT literal[N]);
>=20
> This way, conversions from string literals would be convenient and costly=
 conversions
> from unknown-length strings would be safely made explicit.
>=20
> What are the negative aspects of this solution?

We=E2=80=99ve been around this issue before.
Let=E2=80=99s see what I can remember:
 I remember embedded nulls being a problem.
 I remember including/not including a null being a problem.

Assume that we have a non-explicit constructor for a const char *

Consider
 void foo ( string_view sv ) {}

 foo ( =E2=80=9Cabcde=E2=80=9D );  // passes [ =E2=80=9Cabcde=E2=80=9D, 5 ]
 foo ( =E2=80=9Cabc\0de=E2=80=9D ); // passes [ =E2=80=9Cabc=E2=80=9D, 3 ]


Now, if we have something like this (I don=E2=80=99t think that this will w=
ork as written, but imagine it does):

 template<size_t N>
 basic_string_view(CharT literal[N]);

 const char arr [] =3D =E2=80=9Cabcde=E2=80=9D; // this is an array of size=
 6
 foo ( arr ); // would pass [ &arr[0], 6 ]

Note the length of 6 vs. 5 for the literal.

=E2=80=94 Marshall

--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_FCBDFE70-2897-442E-9F07-25517C0A9CFB
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=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;">On Oct 25, 2014, at 8:=
03 AM, Nicola Gigante &lt;<a href=3D"mailto:nicola.gigante@gmail.com">nicol=
a.gigante@gmail.com</a>&gt; wrote:<br><div><br class=3D"Apple-interchange-n=
ewline"><blockquote type=3D"cite"><div style=3D"font-size: 11px; font-style=
: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;=
 -webkit-text-stroke-width: 0px;"><br>Il giorno 25/ott/2014, alle ore 16:43=
, Olaf van der Spek &lt;<a href=3D"mailto:olafvdspek@gmail.com">olafvdspek@=
gmail.com</a>&gt; ha scritto:<br><br><blockquote type=3D"cite">On Fri, Oct =
24, 2014 at 5:56 AM, Matthew Fioravante<br>&lt;<a href=3D"mailto:fmatthew58=
76@gmail.com">fmatthew5876@gmail.com</a>&gt; wrote:<br><blockquote type=3D"=
cite">I'm not sure I agree with this decision. In my view (pun not intended=
),<br>string_view should become the default way to pass around const refere=
nces to<br>string. That is passing around const std::string&amp; and const =
char* will<br>disappear in favor of std::string_view (by value). Similarly =
we won't pass<br>around const std::vector&lt;T&gt;&amp; anymore but instead=
 std::array_view&lt;T&gt;. Not<br></blockquote><br>std::array_view&lt;const=
 T&gt; ;)<br><br><blockquote type=3D"cite">only are the views more efficien=
t (one less indirection), but they also make<br>interfaces much more flexib=
le by accepting a range like concept instead of<br>hard container type. Hav=
ing to say foo(std::string_view("abc")) is very<br>clumsy.<br></blockquote>=
<br>foo("abc"sv) might work, but I think foo("abc") is a bit cleaner.<br></=
blockquote><br><br>Hi all,<span class=3D"Apple-converted-space">&nbsp;</spa=
n><br><br>In my opinion, the inability to call a function with a string lit=
eral without extra syntax<span class=3D"Apple-converted-space">&nbsp;</span=
><br>is going to kill the usage of string_view, especially in code written =
by novices or<br>not so expert programmers, who instead are the people who =
should be most<span class=3D"Apple-converted-space">&nbsp;</span><br>encour=
aged to use safe and high-level functionalities.<br><br>The O(n) strlen() c=
all on string literal is already a false problem. Compilers inline<br>calls=
 like that.<br><br>But even if we're worried by the cost of a non-inlined s=
trlen() being overlooked,<br>why don't we provide a non-explicit constructo=
r that specifically works only with<span class=3D"Apple-converted-space">&n=
bsp;</span><br>string literals? i.e.<br><br>template&lt;size_t N&gt;<br>bas=
ic_string_view(CharT literal[N]);<br><br>This way, conversions from string =
literals would be convenient and costly conversions<br>from unknown-length =
strings would be safely made explicit.<br><br>What are the negative aspects=
 of this solution?</div></blockquote><br></div><div>We=E2=80=99ve been arou=
nd this issue before.</div><div>Let=E2=80=99s see what I can remember:</div=
><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>I re=
member embedded nulls being a problem.</div><div><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre"> </span>I remember including/not including a=
 null being a problem.</div><div><br></div><div>Assume that we have a non-e=
xplicit constructor for a const char *</div><div><br></div><div>Consider</d=
iv><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>vo=
id foo ( string_view sv ) {}</div><div><br></div><div><span class=3D"Apple-=
tab-span" style=3D"white-space:pre"> </span>foo ( =E2=80=9Cabcde=E2=80=9D )=
;<span class=3D"Apple-tab-span" style=3D"white-space:pre">  </span>// passe=
s [ =E2=80=9Cabcde=E2=80=9D, 5 ]</div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre"> </span>foo ( =E2=80=9Cabc\0de=E2=80=9D );<span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>// passes [ =E2=80=
=9Cabc=E2=80=9D, 3 ]</div><div></div><div></div><div><br></div><div><br></d=
iv><div>Now, if we have something like this (I don=E2=80=99t think that thi=
s will work as written, but imagine it does):</div><div><br></div><div><div=
><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>template&=
lt;size_t N&gt;<br><span class=3D"Apple-tab-span" style=3D"white-space:pre"=
> </span>basic_string_view(CharT literal[N]);<br></div><div><br></div><div>=
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>const char=
 arr [] =3D =E2=80=9Cabcde=E2=80=9D;<span class=3D"Apple-tab-span" style=3D=
"white-space:pre"> </span>// this is an array of size 6</div><div><span cla=
ss=3D"Apple-tab-span" style=3D"white-space:pre"> </span>foo ( arr ); // wou=
ld pass [ &amp;arr[0], 6 ]</div><div><br></div><div>Note the length of 6 vs=
.. 5 for the literal.</div><div><br></div><div>=E2=80=94 Marshall</div><div>=
<br></div></div></body></html>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_FCBDFE70-2897-442E-9F07-25517C0A9CFB--

.

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

On Thu, Oct 23, 2014 at 11:56 PM, Matthew Fioravante <fmatthew5876@gmail.com
> wrote:

>
>
> On Friday, October 10, 2014 4:41:35 PM UTC-4, Ville Voutilainen wrote:
>>
>>
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4081.
>> html#string.view.ops
>> "This conversion is explicit to avoid accidental O(N) operations on
>> type mismatches."
>>
>
> I'm not sure I agree with this decision. In my view (pun not intended),
> string_view should become the default way to pass around const references
> to string. That is passing around const std::string& and const char* will
> disappear in favor of std::string_view (by value). Similarly we won't pass
> around const std::vector<T>& anymore but instead std::array_view<T>. Not
> only are the views more efficient (one less indirection), but they also
> make interfaces much more flexible by accepting a range like concept
> instead of hard container type. Having to say foo(std::string_view("abc"))
> is very clumsy.
>
>
int foo(std::string_view sv);
int x = foo("abc");

will work.  string_view constructor is implicit.
as does

std::string s("abc");
int y = foo(s);

What is explicit is basic_string's constructor - ie going the other
direction.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Oct 23, 2014 at 11:56 PM, Matthew Fioravante <span dir=3D"ltr">=
&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew587=
6@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><span class=3D""><br><br>On Friday, October 10=
, 2014 4:41:35 PM UTC-4, Ville Voutilainen wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><br><a href=3D"http://open-std.org/JTC1/SC22/WG21/d=
ocs/papers/2014/n4081.html#string.view.ops" target=3D"_blank">http://open-s=
td.org/JTC1/SC22/<u></u>WG21/docs/papers/2014/n4081.<u></u>html#string.view=
..ops</a>
<br>&quot;This conversion is explicit to avoid accidental O(N) operations o=
n
<br>type mismatches.&quot;
<br></blockquote><div><br></div></span><div>I&#39;m not sure I agree with t=
his decision. In my view (pun not intended), string_view should become the =
default way to pass around const references to string. That is passing arou=
nd const std::string&amp; and const char* will disappear in favor of std::s=
tring_view (by value). Similarly we won&#39;t pass around const std::vector=
&lt;T&gt;&amp; anymore but instead std::array_view&lt;T&gt;. Not only are t=
he views more efficient (one less indirection), but they also make interfac=
es much more flexible by accepting a range like concept instead of hard con=
tainer type. Having to say foo(std::string_view(&quot;abc&quot;)) is very c=
lumsy.</div><div><br></div></div></blockquote><div><br></div><div>int foo(s=
td::string_view sv);<br></div><div>int x =3D foo(&quot;abc&quot;);<br><br><=
/div><div>will work.=C2=A0 string_view constructor is implicit.<br></div><d=
iv>as does<br><br></div><div>std::string s(&quot;abc&quot;);<br></div><div>=
int y =3D foo(s);<br></div><div><br></div><div>What is explicit is basic_st=
ring&#39;s constructor - ie going the other direction.<br><br></div></div><=
br></div></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c38e96a3193a05066a3037--

.

On Mon, Oct 27, 2014 at 5:40 PM, Tony V E <tvaneerd@gmail.com> wrote:
> What is explicit is basic_string's constructor - ie going the other
> direction.

But why?

> > I've heard the cost argument, but string construction is known to be expensive and construction from const char* or const string& is as expensive but implicit.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Tue, Oct 28, 2014 at 9:55 AM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:

> On Mon, Oct 27, 2014 at 5:40 PM, Tony V E <tvaneerd@gmail.com> wrote:
> > What is explicit is basic_string's constructor - ie going the other
> > direction.
>
> But why?
>
> > > I've heard the cost argument, but string construction is known to be
> expensive and construction from const char* or const string& is as
> expensive but implicit.
>
>

I don't recall the committee discussions in detail, but here are my
guesses/reasons:

- In general, the standard library is becoming more explicit, as is modern
code.  At least that's what I'm seeing - implicit conversions were "cool"
and magical, but now are seen as problematic.  (They are both, of course)

- before string_view existed your choice was char * or std::string.  So, by
being implicit, we "encouraged" conversion to std::string - it has a
runtime cost, but it has a coding benefit that is greater than that cost
(typically).  But string -> char * was not implicit, thus not encouraged.
We preferred you stay with string once you had a string.

Now with string_view, we have a 3rd choice.  Safer than char *, faster than
string, more general than either.  So we don't want to encourage the
conversion to string.  We'd prefer you fall into and stay in the
"string_view valley", and do extra work to get out of the valley in either
direction (toward string or char *).  ie instead of foo(someStringView)
working (implicitly), we subtly encourage you change foo() to take a
string_view.

Like I said, that is not directly from committee meetings.  It is more of
my guess of the committee "subconscious".  It is close to my own reasoning
at least (which frequently doesn't match the committee, but I _think_ it
does in this case).

Tony

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Oct 28, 2014 at 9:55 AM, Olaf van der Spek <span dir=3D"ltr">&l=
t;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On Mon, Oct 27, 2014 at 5:40 PM, Tony V E &lt;<a href=3D"mailto:tvane=
erd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt; What is explicit is basic_string&#39;s constructor - ie going the othe=
r<br>
&gt; direction.<br>
<br>
</span>But why?<br>
<span class=3D"im HOEnZb"><br>
&gt; &gt; I&#39;ve heard the cost argument, but string construction is know=
n to be expensive and construction from const char* or const string&amp; is=
 as expensive but implicit.<br>
<br></span></blockquote><div><br></div></div><br></div><div class=3D"gmail_=
extra">I don&#39;t recall the committee discussions in detail, but here are=
 my guesses/reasons:<br><br></div><div class=3D"gmail_extra">- In general, =
the standard library is becoming more explicit, as is modern code.=C2=A0 At=
 least that&#39;s what I&#39;m seeing - implicit conversions were &quot;coo=
l&quot; and magical, but now are seen as problematic.=C2=A0 (They are both,=
 of course)<br><br></div><div class=3D"gmail_extra">- before string_view ex=
isted your choice was char * or std::string.=C2=A0 So, by being implicit, w=
e &quot;encouraged&quot; conversion to std::string - it has a runtime cost,=
 but it has a coding benefit that is greater than that cost (typically).=C2=
=A0 But string -&gt; char * was not implicit, thus not encouraged.=C2=A0 We=
 preferred you stay with string once you had a string.<br><br></div><div cl=
ass=3D"gmail_extra">Now with string_view, we have a 3rd choice.=C2=A0 Safer=
 than char *, faster than string, more general than either.=C2=A0 So we don=
&#39;t want to encourage the conversion to string.=C2=A0 We&#39;d prefer yo=
u fall into and stay in the &quot;string_view valley&quot;, and do extra wo=
rk to get out of the valley in either direction (toward string or char *).=
=C2=A0 ie instead of foo(someStringView) working (implicitly), we subtly en=
courage you change foo() to take a string_view.<br><br></div><div class=3D"=
gmail_extra">Like I said, that is not directly from committee meetings.=C2=
=A0 It is more of my guess of the committee &quot;subconscious&quot;.=C2=A0=
 It is close to my own reasoning at least (which frequently doesn&#39;t mat=
ch the committee, but I _think_ it does in this case).<br><br></div><div cl=
ass=3D"gmail_extra">Tony<br><br><br></div></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0158b6be7b609a05067cfcd6--

.

On Tue, Oct 28, 2014 at 4:06 PM, Tony V E <tvaneerd@gmail.com> wrote:
> Now with string_view, we have a 3rd choice.  Safer than char *, faster than
> string, more general than either.  So we don't want to encourage the
> conversion to string.  We'd prefer you fall into and stay in the
> "string_view valley", and do extra work to get out of the valley in either
> direction (toward string or char *).  ie instead of foo(someStringView)
> working (implicitly), we subtly encourage you change foo() to take a
> string_view.

Are there no good reasons to have a string value / reference anymore?
What if I need c_str()?

IMO having an explicit constructor to encourage people to use
string_view as parameter type doesn't seem right.
What if it's a third-party lib that can't be easily updated?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 28 October 2014 17:31, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Tue, Oct 28, 2014 at 4:06 PM, Tony V E <tvaneerd@gmail.com> wrote:
>> Now with string_view, we have a 3rd choice.  Safer than char *, faster than
>> string, more general than either.  So we don't want to encourage the
>> conversion to string.  We'd prefer you fall into and stay in the
>> "string_view valley", and do extra work to get out of the valley in either
>> direction (toward string or char *).  ie instead of foo(someStringView)
>> working (implicitly), we subtly encourage you change foo() to take a
>> string_view.
>
> Are there no good reasons to have a string value / reference anymore?
> What if I need c_str()?
>
> IMO having an explicit constructor to encourage people to use
> string_view as parameter type doesn't seem right.
> What if it's a third-party lib that can't be easily updated?


What I can find from the committee discussions is that LEWG didn't want
void f(const string&);
string_view whatever = get_it();
f(whatever);
to be well-formed since it will allocate memory and copy the data if
the conversion from string_view
to string is implicit. That's what the "type mismatches" in the note means.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Tue, Oct 28, 2014 at 11:31 AM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:

> On Tue, Oct 28, 2014 at 4:06 PM, Tony V E <tvaneerd@gmail.com> wrote:
> > Now with string_view, we have a 3rd choice.  Safer than char *, faster
> than
> > string, more general than either.  So we don't want to encourage the
> > conversion to string.  We'd prefer you fall into and stay in the
> > "string_view valley", and do extra work to get out of the valley in
> either
> > direction (toward string or char *).  ie instead of foo(someStringView)
> > working (implicitly), we subtly encourage you change foo() to take a
> > string_view.
>
> Are there no good reasons to have a string value / reference anymore?
> What if I need c_str()?
>

Sure there are good reasons.  It is a trade-off.


>
> IMO having an explicit constructor to encourage people to use
> string_view as parameter type doesn't seem right.
> What if it's a third-party lib that can't be easily updated?
>

Then you call the explicit conversion.  That's the trade-off.  I agree
there are pros and cons on either side.

Maybe that trade-off wasn't adequately discussed by the committee (I don't
recall), and/or maybe it will be discussed (again?) next week.
But my guess is that it won't be changed, and is the right trade-off.

Tony

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Oct 28, 2014 at 11:31 AM, Olaf van der Spek <span dir=3D"ltr">&=
lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gma=
il.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"><span class=
=3D"">On Tue, Oct 28, 2014 at 4:06 PM, Tony V E &lt;<a href=3D"mailto:tvane=
erd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt; Now with string_view, we have a 3rd choice.=C2=A0 Safer than char *, f=
aster than<br>
&gt; string, more general than either.=C2=A0 So we don&#39;t want to encour=
age the<br>
&gt; conversion to string.=C2=A0 We&#39;d prefer you fall into and stay in =
the<br>
&gt; &quot;string_view valley&quot;, and do extra work to get out of the va=
lley in either<br>
&gt; direction (toward string or char *).=C2=A0 ie instead of foo(someStrin=
gView)<br>
&gt; working (implicitly), we subtly encourage you change foo() to take a<b=
r>
&gt; string_view.<br>
<br>
</span>Are there no good reasons to have a string value / reference anymore=
?<br>
What if I need c_str()?<br></blockquote><div><br></div><div>Sure there are =
good reasons.=C2=A0 It is a trade-off.<br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br>
IMO having an explicit constructor to encourage people to use<br>
string_view as parameter type doesn&#39;t seem right.<br>
What if it&#39;s a third-party lib that can&#39;t be easily updated?<br></b=
lockquote><div><br></div><div>Then you call the explicit conversion.=C2=A0 =
That&#39;s the trade-off.=C2=A0 I agree there are pros and cons on either s=
ide.<br>=C2=A0<br></div><div>Maybe that trade-off wasn&#39;t adequately dis=
cussed by the committee (I don&#39;t recall), and/or maybe it will be discu=
ssed (again?) next week.<br></div><div>But my guess is that it won&#39;t be=
 changed, and is the right trade-off.<br><br></div><div>Tony<br></div></div=
><br></div></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11346d50099aac05067ec536--

.

------=_Part_1955_772310022.1414539986379
Content-Type: text/plain; charset=UTF-8

Requiring explicit conversion from string_view to string seems like the
right idea to me. In general stronger concepts (string) should implicitly
convert to weaker concepts (string_view), but not the other way around.

On Tuesday, October 28, 2014 1:13:50 PM UTC-4, Tony V E wrote:
>
>
>
> On Tue, Oct 28, 2014 at 11:31 AM, Olaf van der Spek <olafv...@gmail.com
> <javascript:>> wrote:
>
>> On Tue, Oct 28, 2014 at 4:06 PM, Tony V E <tvan...@gmail.com
>> <javascript:>> wrote:
>> > Now with string_view, we have a 3rd choice.  Safer than char *, faster
>> than
>> > string, more general than either.  So we don't want to encourage the
>> > conversion to string.  We'd prefer you fall into and stay in the
>> > "string_view valley", and do extra work to get out of the valley in
>> either
>> > direction (toward string or char *).  ie instead of foo(someStringView)
>> > working (implicitly), we subtly encourage you change foo() to take a
>> > string_view.
>>
>> Are there no good reasons to have a string value / reference anymore?
>> What if I need c_str()?
>>
>
> Sure there are good reasons.  It is a trade-off.
>
>
>>
>> IMO having an explicit constructor to encourage people to use
>> string_view as parameter type doesn't seem right.
>> What if it's a third-party lib that can't be easily updated?
>>
>
> Then you call the explicit conversion.  That's the trade-off.  I agree
> there are pros and cons on either side.
>
> Maybe that trade-off wasn't adequately discussed by the committee (I don't
> recall), and/or maybe it will be discussed (again?) next week.
> But my guess is that it won't be changed, and is the right trade-off.
>
> Tony
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Requiring explicit conversion from string_view to string s=
eems like the right idea to me. In general stronger concepts (string) shoul=
d implicitly convert to weaker concepts (string_view), but not the other wa=
y around.<br><br>On Tuesday, October 28, 2014 1:13:50 PM UTC-4, Tony V E wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div>=
<br><div class=3D"gmail_quote">On Tue, Oct 28, 2014 at 11:31 AM, Olaf van d=
er Spek <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"WC7i3ZOpxQUJ" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return true;">olafv...=
@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"><span>On=
 Tue, Oct 28, 2014 at 4:06 PM, Tony V E &lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"WC7i3ZOpxQUJ" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">tvan...@gmail.com</a>&gt; wrote:<br>
&gt; Now with string_view, we have a 3rd choice.&nbsp; Safer than char *, f=
aster than<br>
&gt; string, more general than either.&nbsp; So we don't want to encourage =
the<br>
&gt; conversion to string.&nbsp; We'd prefer you fall into and stay in the<=
br>
&gt; "string_view valley", and do extra work to get out of the valley in ei=
ther<br>
&gt; direction (toward string or char *).&nbsp; ie instead of foo(someStrin=
gView)<br>
&gt; working (implicitly), we subtly encourage you change foo() to take a<b=
r>
&gt; string_view.<br>
<br>
</span>Are there no good reasons to have a string value / reference anymore=
?<br>
What if I need c_str()?<br></blockquote><div><br></div><div>Sure there are =
good reasons.&nbsp; It is a trade-off.<br>&nbsp;<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br>
IMO having an explicit constructor to encourage people to use<br>
string_view as parameter type doesn't seem right.<br>
What if it's a third-party lib that can't be easily updated?<br></blockquot=
e><div><br></div><div>Then you call the explicit conversion.&nbsp; That's t=
he trade-off.&nbsp; I agree there are pros and cons on either side.<br>&nbs=
p;<br></div><div>Maybe that trade-off wasn't adequately discussed by the co=
mmittee (I don't recall), and/or maybe it will be discussed (again?) next w=
eek.<br></div><div>But my guess is that it won't be changed, and is the rig=
ht trade-off.<br><br></div><div>Tony<br></div></div><br></div></div>
</blockquote></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1955_772310022.1414539986379--

.

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

The type 'std::string_view' is implicitly convertible from 'std::string',
if 'std::string' was also implicitly convertible from 'std::string_view'
you would run into issues when using any operation that can be applied with
a mixed type (comparison, inequality...)

std::string s("Hi there");
std::string_view v(s);
bool equal = (s == v);    // ambiguity!

    David

On Mon, Oct 27, 2014 at 12:40 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Thu, Oct 23, 2014 at 11:56 PM, Matthew Fioravante <
> fmatthew5876@gmail.com> wrote:
>
>>
>>
>> On Friday, October 10, 2014 4:41:35 PM UTC-4, Ville Voutilainen wrote:
>>>
>>>
>>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4081.
>>> html#string.view.ops
>>> "This conversion is explicit to avoid accidental O(N) operations on
>>> type mismatches."
>>>
>>
>> I'm not sure I agree with this decision. In my view (pun not intended),
>> string_view should become the default way to pass around const references
>> to string. That is passing around const std::string& and const char* will
>> disappear in favor of std::string_view (by value). Similarly we won't pass
>> around const std::vector<T>& anymore but instead std::array_view<T>. Not
>> only are the views more efficient (one less indirection), but they also
>> make interfaces much more flexible by accepting a range like concept
>> instead of hard container type. Having to say foo(std::string_view("abc"))
>> is very clumsy.
>>
>>
> int foo(std::string_view sv);
> int x = foo("abc");
>
> will work.  string_view constructor is implicit.
> as does
>
> std::string s("abc");
> int y = foo(s);
>
> What is explicit is basic_string's constructor - ie going the other
> direction.
>
>
>  --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">The type &#39;std::string_view&#39; is implicitly converti=
ble from &#39;std::string&#39;, if &#39;std::string&#39; was also implicitl=
y convertible from &#39;std::string_view&#39; you would run into issues whe=
n using any operation that can be applied with a mixed type (comparison, in=
equality...)<br><br>std::string s(&quot;Hi there&quot;);<br>std::string_vie=
w v(s);<br>bool equal =3D (s =3D=3D v); =C2=A0 =C2=A0// ambiguity!<br><br>=
=C2=A0 =C2=A0 David</div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Mon, Oct 27, 2014 at 12:40 PM, Tony V E <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@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"><br>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">=
On Thu, Oct 23, 2014 at 11:56 PM, Matthew Fioravante <span dir=3D"ltr">&lt;=
<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><span><br><br>On Friday, October 10, 2014 4:41:35 =
PM UTC-4, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/20=
14/n4081.html#string.view.ops" target=3D"_blank">http://open-std.org/JTC1/S=
C22/<u></u>WG21/docs/papers/2014/n4081.<u></u>html#string.view.ops</a>
<br>&quot;This conversion is explicit to avoid accidental O(N) operations o=
n
<br>type mismatches.&quot;
<br></blockquote><div><br></div></span><div>I&#39;m not sure I agree with t=
his decision. In my view (pun not intended), string_view should become the =
default way to pass around const references to string. That is passing arou=
nd const std::string&amp; and const char* will disappear in favor of std::s=
tring_view (by value). Similarly we won&#39;t pass around const std::vector=
&lt;T&gt;&amp; anymore but instead std::array_view&lt;T&gt;. Not only are t=
he views more efficient (one less indirection), but they also make interfac=
es much more flexible by accepting a range like concept instead of hard con=
tainer type. Having to say foo(std::string_view(&quot;abc&quot;)) is very c=
lumsy.</div><div><br></div></div></blockquote><div><br></div></span><div>in=
t foo(std::string_view sv);<br></div><div>int x =3D foo(&quot;abc&quot;);<b=
r><br></div><div>will work.=C2=A0 string_view constructor is implicit.<br><=
/div><div>as does<br><br></div><div>std::string s(&quot;abc&quot;);<br></di=
v><div>int y =3D foo(s);<br></div><div><br></div><div>What is explicit is b=
asic_string&#39;s constructor - ie going the other direction.<br><br></div>=
</div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<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+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113ec986b1926105066b3f5d--

.

On Mon, Oct 27, 2014 at 6:56 PM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.or=
g> wrote:
> The type 'std::string_view' is implicitly convertible from 'std::string',=
 if
> 'std::string' was also implicitly convertible from 'std::string_view' you
> would run into issues when using any operation that can be applied with a
> mixed type (comparison, inequality...)
>
> std::string s("Hi there");
> std::string_view v(s);
> bool equal =3D (s =3D=3D v);    // ambiguity!

Shouldn't comparisons be doable without any conversions?

--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Wed, Oct 29, 2014 at 12:46 AM, Matthew Fioravante
<fmatthew5876@gmail.com> wrote:
> Requiring explicit conversion from string_view to string seems like the
> right idea to me. In general stronger concepts (string) should implicitly
> convert to weaker concepts (string_view), but not the other way around.

Shouldn't it be the other way around? Now you're implicity losing strength.
Not sure what exactly you mean by the strength of a concept though.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_406_340620847.1415331977443
Content-Type: text/plain; charset=UTF-8



On Thursday, November 6, 2014 1:48:53 PM UTC-5, Olaf van der Spek wrote:
>
> On Wed, Oct 29, 2014 at 12:46 AM, Matthew Fioravante
> <fmatth...@gmail.com <javascript:>> wrote:
> > Requiring explicit conversion from string_view to string seems like the
> > right idea to me. In general stronger concepts (string) should
> implicitly
> > convert to weaker concepts (string_view), but not the other way around.
>
> Shouldn't it be the other way around? Now you're implicity losing
> strength.
> Not sure what exactly you mean by the strength of a concept though.
>

Implicitly losing strength is good. You want to design your interface to
ask for the weakest possible concept so that you give maximum flexibility
to users. I suppose it could be considered similar to polymorphism where if
you just needed a Shape, you would pass Shape* and then users could easily
give you a Square, Triangle, or whatever else. Inheritance and virtual
functions give us behavioral polymorphism, string_view and array_view give
us a kind of data polymorphism.

If my interface just needs a "contiguous collection of T" (array_view<T>)
then any type that is a contiguous collection (vector, C array, std::array,
 etc..) should implicitly convert to array_view<T> so that I can just call
the function directly with all of these types without needing templates,
type erasure, or expensive copy conversions to get the data into whatever
type the author choose to stick in their function prototype.

string_view is just a read only view to some character data and a length.
string is a read write view to character data / length and is also a
container which allocates memory and stores the data. A string is a
string_view with the extra burden of managing the storage of the string
data. That is why I say string is "stronger" than string_view because its a
more specialized concept, in other words it can do more things and most
critically it adds constraints on the physical location of the data. If
your interface doesn't need to do storage management then it should accept
a string_view, not a string, char*, or even a const string& to maximize
flexibility for the callers and eliminate dependencies on one string type.

Converting a string to a string_view is not really a conversion, its more
like constructing a reference to the data which performance wise is
basically free (and possibly even more optimal then passing const string&
because we don't have that extra indirection). The assignment is a shallow
copy, similar to converting a child class pointer to a base class pointer.
Converting from string_view to string however is a real data conversion.
Memory has to be allocated and a copy of the data has to be made. In this
case its better to have an explicit conversion so that people are prevented
from easy to write hidden pessimizations. It marks in the code directly
where copies of strings are being made.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Thursday, November 6, 2014 1:48:53 PM UTC-5, Ol=
af van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, =
Oct 29, 2014 at 12:46 AM, Matthew Fioravante
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
47WffNnL0rIJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">fmatth...@gmail.com</a>&gt; wr=
ote:
<br>&gt; Requiring explicit conversion from string_view to string seems lik=
e the
<br>&gt; right idea to me. In general stronger concepts (string) should imp=
licitly
<br>&gt; convert to weaker concepts (string_view), but not the other way ar=
ound.
<br>
<br>Shouldn't it be the other way around? Now you're implicity losing stren=
gth.
<br>Not sure what exactly you mean by the strength of a concept though.
<br></blockquote><div><span style=3D"font-size: 13px;"><br></span></div><di=
v><span style=3D"font-size: 13px;">Implicitly losing strength is good. You =
want to design your interface to ask for the weakest possible concept so th=
at you give maximum flexibility to users. I suppose it could be considered =
similar to polymorphism where if you just needed a Shape, you would pass Sh=
ape* and then users could easily give you a Square, Triangle, or whatever e=
lse. Inheritance and virtual functions give us behavioral polymorphism, str=
ing_view and array_view give us a kind of data polymorphism.</span></div><d=
iv><span style=3D"font-size: 13px;"><br></span></div><div><span style=3D"fo=
nt-size: 13px;">If my interface just needs a "contiguous collection of T" (=
array_view&lt;T&gt;) then any type that is a contiguous collection (vector,=
 C array, std::array, &nbsp;etc..) should implicitly convert to array_view&=
lt;T&gt; so that I can just call the function directly with all of these ty=
pes without needing templates, type erasure, or expensive copy conversions =
to get the data into whatever type the author choose to stick in their func=
tion prototype.</span></div><div><span style=3D"font-size: 13px;"><br></spa=
n></div><div><span style=3D"font-size: 13px;">string_view is just a read on=
ly view to some character data and a length. string is a read write view to=
 character data / length and is also a container which allocates memory and=
 stores the data. A string is a string_view with the extra burden of managi=
ng the storage of the string data. That is why I say string is "stronger" t=
han string_view because its a more specialized concept, in other words it c=
an do more things and most critically it adds constraints on the physical l=
ocation of the data. If your interface doesn't need to do storage managemen=
t then it should accept a string_view, not a string, char*, or even a const=
 string&amp; to maximize flexibility for the callers and eliminate dependen=
cies on one string type.</span><br></div><div><span style=3D"font-size: 13p=
x;"><br></span></div><div><span style=3D"font-size: 13px;">Converting a str=
ing to a string_view is not really a conversion, its more like constructing=
 a reference to the data which performance wise is basically free (and poss=
ibly even more optimal then passing const string&amp; because we don't have=
 that extra indirection). The assignment is a shallow copy, similar to conv=
erting a child class pointer to a base class pointer. Converting from strin=
g_view to string however is a real data conversion. Memory has to be alloca=
ted and a copy of the data has to be made. In this case its better to have =
an explicit conversion so that people are prevented from easy to write hidd=
en pessimizations. It marks in the code directly where copies of strings ar=
e being made.</span></div></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_406_340620847.1415331977443--

.

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

On Thu, Nov 6, 2014 at 1:47 PM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:

> > std::string s("Hi there");
> > std::string_view v(s);
> > bool equal = (s == v);    // ambiguity!
>
> Shouldn't comparisons be doable without any conversions?
>
>
That is not the case in n4082.  The comparison operators only apply on two
string_view and there are no cross type conversions.  I mentioned this to
some committee members that, I believe, raised this as a comment, although
my understanding is that the comment was late to the process to require an
official response from ISO.

The particular concern I had is that not having cross type comparisons for
'charT const*' comes with a performance cost, as the conversion from 'charT
const *' to 'basic_string_view<charT, traits>' requires walking the whole
sequence to find the null just to build the argument and then walking over
the sequence again comparing the values.

If the conversion from 'string_view' to 'string' was implicit, then the
problem of not having cross type comparisons would be worse, as the absence
would cause ambiguities in code.

Note that it is perfectly fine to convert from 'string' to 'string_view'.
There is no associated cost (pointer + size/2 pointer copies are not a real
cost) and if an algorithm can operate just on a sequence of characters a
single implementation with 'string_view' will fit all uses.

    David

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Nov 6, 2014 at 1:47 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=
=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@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"><span class=3D"">&gt; =
std::string s(&quot;Hi there&quot;);<br>
&gt; std::string_view v(s);<br>
&gt; bool equal =3D (s =3D=3D v);=C2=A0 =C2=A0 // ambiguity!<br>
<br>
</span>Shouldn&#39;t comparisons be doable without any conversions?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br>That is not the case in n4082.=C2=A0 The comparison operators only apply=
 on two string_view and there are no cross type conversions.=C2=A0 I mentio=
ned this to some committee members that, I believe, raised this as a commen=
t, although my understanding is that the comment was late to the process to=
 require an official response from ISO.<br><br>The particular concern I had=
 is that not having cross type comparisons for &#39;charT const*&#39; comes=
 with a performance cost, as the conversion from &#39;charT const *&#39; to=
 &#39;basic_string_view&lt;charT, traits&gt;&#39; requires walking the whol=
e sequence to find the null just to build the argument and then walking ove=
r the sequence again comparing the values.<br><br>If the conversion from &#=
39;string_view&#39; to &#39;string&#39; was implicit, then the problem of n=
ot having cross type comparisons would be worse, as the absence would cause=
 ambiguities in code.<br><br>Note that it is perfectly fine to convert from=
 &#39;string&#39; to &#39;string_view&#39;. There is no associated cost (po=
inter + size/2 pointer copies are not a real cost) and if an algorithm can =
operate just on a sequence of characters a single implementation with &#39;=
string_view&#39; will fit all uses.<br><br>=C2=A0 =C2=A0 David</div></div><=
/div></div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e010d7dea7432600507a9cb95--

.