--001a114304d64b488c0531243c6c
Content-Type: multipart/alternative; boundary=001a114304d64b48880531243c6a

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

Please find attached a draft 3-page proposal entitled "Proposal of File
String Literals".

Feedback appreciated.

Thanks,
Andrew.

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

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

<div dir=3D"ltr">Please find attached a draft 3-page proposal entitled &quo=
t;Proposal of File String Literals&quot;.<div><br></div><div>Feedback appre=
ciated.</div><div><br></div><div>Thanks,</div><div>Andrew.</div><div><br></=
div></div>

<p></p>

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

--001a114304d64b48880531243c6a--
--001a114304d64b488c0531243c6c
Content-Type: application/pdf; name="ProposalofFileStringLiterals.pdf"
Content-Disposition: attachment; filename="ProposalofFileStringLiterals.pdf"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_inczqaes0

JVBERi0xLjUKJb/3ov4KOCAwIG9iago8PCAvTGluZWFyaXplZCAxIC9MIDE1MTEzMyAvSCBbIDg1
NyAxNzEgXSAvTyAxMiAvRSAxMDU0MjcgL04gMyAvVCAxNTA4MTkgPj4KZW5kb2JqCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKOSAwIG9iago8PCAv
VHlwZSAvWFJlZiAvTGVuZ3RoIDgzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9EZWNvZGVQYXJtcyA8
PCAvQ29sdW1ucyA1IC9QcmVkaWN0b3IgMTIgPj4gL1cgWyAxIDMgMSBdIC9JbmRleCBbIDggMzkg
XSAvSW5mbyAyNSAwIFIgL1Jvb3QgMTAgMCBSIC9TaXplIDQ3IC9QcmV2IDE1MDgyMCAgICAgICAg
ICAgICAgICAvSUQgWzxjN2FmZDllZWMyOTJlMTczN2E4ZDBmYWU2NGUxZTQxYT48YzdhZmQ5ZWVj
MjkyZTE3MzdhOGQwZmFlNjRlMWU0MWE+XSA+PgpzdHJlYW0KeJxjYmRg4GdgYmBgOAkimf3AbGMQ
ybgaTM4BkUpHQGS2L4hk2gIiJaaD2Rog0uodWGUckGQMmwVmN4DIEC6wmjUMTIz/s26ATWZgHCgS
ACzrDH4KZW5kc3RyZWFtCmVuZG9iagogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIAoxMCAwIG9iago8PCAvUGFnZXMgMjYgMCBSIC9UeXBlIC9DYXRhbG9nID4+CmVuZG9i
agoxMSAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvUyA2MyAvTGVuZ3RoIDkzID4+CnN0
cmVhbQp4nGNgYGBiYGCOZGBhYDB9wSDIAAVgNgtIlIFlE8OGzxMTHBgYuAuUXdM7Vx8yidoDFUEC
vFDMwKjBwM/woqk4UIPj0NsHDDLJDGYrnjAmTRfgcOhNYGAAAHMfF24KZW5kc3RyZWFtCmVuZG9i
agoxMiAwIG9iago8PCAvQW5ub3RzIFsgPDwgL0EgPDwgL1MgL1VSSSAvVHlwZSAvQWN0aW9uIC9V
UkkgKG1haWx0bzphbmRyZXd0b21hem9zQGdtYWlsLmNvbSkgPj4gL0JvcmRlciBbIDAgMCAwIF0g
L1JlY3QgWyAyMDUgNjIyIDM0NSA2MzUgXSAvU3VidHlwZSAvTGluayAvVHlwZSAvQW5ub3QgPj4g
XSAvQ29udGVudHMgMTMgMCBSIC9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gL1BhcmVudCAyNiAw
IFIgL1Jlc291cmNlcyA8PCAvRXh0R1N0YXRlIDw8IC9HMCAyNyAwIFIgPj4gL0ZvbnQgPDwgL0Yw
IDI4IDAgUiAvRjEgMzEgMCBSIC9GMiAzNCAwIFIgL0YzIDM3IDAgUiAvRjQgNDAgMCBSID4+IC9Q
cm9jU2V0cyBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSA+PiAvVHlwZSAv
UGFnZSA+PgplbmRvYmoKMTMgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA4
NTcxID4+CnN0cmVhbQp4nJ1dWY5sOW79f6vIDfi2BlIDYBjomvrbRu3AsBsw0B9u7x/wOYrMuJQU
YkZVFdDDewxdieJwKFJU/Aj4918i/qP29PGf//jxvz+uquNPv/4bfxg/+O9//O3j8T/++fcff/lb
+Pj7//3g37dYPmLQ8vHP//rx388/ybG0+U8sTS/jj3oJjz/hqOHrA4Ef0Jo+WsP/zeEj1gcVftVD
/MAwX38Sxgzxu8f/wO9++v3HX34LH1muwn9q//idw38uEyNwwN//8eNfQ8j53z5+/5/7L2PsV4wq
Ug2R6kKUw1W0JLU0aaGRfvUcJIglWr9W+pWCqHZvpNYuqa3GbInKTJSCXi2UlpshElmIkl6hhd7t
SPLbQpTTVVvQkAxRWCaeJF0SeozNmXgq8cKMUpvm1BeiGq+McVr3PtfC1cHKHgxRWkbKIV0Ri0uW
4/LzStTBpy7SHBbkWC8NrVfLAmkLUS7gU47i8SlLuSTGKpbjedm7DClQ8KFHy8y6EFUIpmpLyRHM
3CGYvRSfBb1duZdl7+JMJGBBqWHZu78uRGABWCnaHBYIWKA1h0nG08JxKRBfqSl1Z+JS86VSqiaH
T9LyFatmFWfvINyXSNeUHWZqzFfvIWtxVEpzvlIRTcWRJxWIbxHo1K7Bv/7+jbnSV9y9fxU/f1V2
I1fyn/hR+/pRWhgbA/axSapiiDZbhZFr1tySIZJF3mNKVyhZQ7UjLVtEG5uilDh9LqxGFvuYcm5q
P7eOpAECiO3OdqS4ErWrJi0hWqKVBQWmsVetlk+rvMdSrla6qmVBXj9X6yVkU/GY2fQqMHrZsiCu
I7UORS09Bkv0y0LU81WlteZOvNerpdBKdKQAfw/DD9UoDjNThKjAP4rH8ZQgKgHCEj0iOKMGqaPx
WIm+FeckcV/uO0qQwnPfVh7BzdYKMRFDtMGD+AUPDM2mKA1+CKuvhkjWbbsVxRCdFcUQrSqX4dGg
u7nbOa3iLfDXUWq0E99ESSCUDUyLhmgTJYCfqqByealwexmTih4vi8CBSo/FY2ZNl5YS0sSCv66K
Eq4agaKS9zmonPZaa7MjyVGbzEhhVRS9OiyFukSQAtgL8MB+7udVUSKMXKLVMSNt2tTpZUvzWJAg
BTUJUf5576A1MHIwKZYFq79ORLcEperwKcGmht56797EYS6TBoi6N/EKKQCNTCq1KEJqkAK49OLt
XQJCqiHLJL7b54CQmq4qteK/UC/qUK4OM4Fsr1Bhni1RWvEfNriU2Ns00q8r3ISapxhC24m+tWl5
0vs/YgnTc9KrEhhLmE5bEgmhUqkxWaLV7ABq9t4Kl/8kkp9WU1gumIHa1Y602gFAqBwCMJsl2oI3
AOmGEK8bot3KAdYBRCa7ut3K1Ssn1RA8PmlFVAKXMPFpdeKAv0mxvZZPsvIJ8FdgRVPwVlfblRrg
vd27zWU0RCV0KxOfVnsJOBBg6hApnVmQAuS7w6bakfKKGeAPg+Qu3t4NU9gVIbIlWu0llAAsaNPn
NhXPDXYAsCnakX5ZDRgCjpZ5HOHMSeWCrYAPskRr5I0oNxfMzBOVhA0W+LpiWRB/m/QwHnFMZSCC
ONrONTxBECDCI24Adr3y4x8gL8CL8U8dhzbfE93nJn9kGhvzYYQjQsLQHXGnEU5AyNkTdxphxI5F
1RH3HDJUENFldMSdRhi+KndP3PPAWqm07JiqTCuEmF6yIzVgLFQQ7ro4kjwOBqARuTrMRBB7IbYs
qTuSnCF/HV5IxZtTDRfcZ6vVkeT8CEpgw6w9Wz1aT5CfGKPdlu1gIEBPG/6+OSyQmC7GLZOorCyQ
FC4EnXGa03YwgFACQCPNRm89Ykiw1ioymYU1msLfAmuV3Cd5KisRYkUVjZ7t4LFHB4tz31nwrcYj
3rkQSksMLzV+0kQZoDWCRVCn+M2RqP+9HO1+pTfDLCkvPMRb4ELeOGu4iTYYfp813EQ7uLjjLDkZ
CIKLju/ROj+JNkgA0Qiw8hIN0QYJMrYCGCDa1cXVRxtwcRNt0REkEaKX7eriBi6A+lWrBEu0nIvG
AtQfEBk0S7SepDCEapWHJM6cGELlxkMSQ7RyvIHjrVeq9flzDKGAw1UdPhFcdIa2eWfB98F/DPs+
3b/Cjj9+FVaphP37wjFrEB056a4Y+SbaIG9qPLSB+luidfkaeAqd55G2LckAYBIRY91EmxK0esGz
wR7bkVaB6wWhrzadPvfzeyxJ0yT/gHrDD34xcoWWPIQHkC3VEG1KybCgSebyn0SbvtFrK49IDNGW
ZWHoFCqPqQ3RFhYwN9KI0w3RltSB5sIDAqc7n4PmZsQgsXsjUXMlMvI3RKvA3UeJDp8qJp4Ct83h
U+3wkHBsdlteyRJUhskKZ6TOfI3WeXVrPNP7BejWkrfB2JKrYGLZbvAKyxgWpJBS6M6cEqQAvgJ+
0H7u15WoQzHT0LmbaD1ruc8bz6vjCQlQi87iu8JXgUstobjiCy8AeUJUEBxRGQFGgx5Y8d3SaAww
6AlcPj0STXVi5hbPVAidasuTIqyrY0Iu0Rg6KgUQDCvX6DEdjjdIJkDuxKc9YIBkRi19YsGK4IMi
EIPQRYcFzP8Bv9U2zWnL/xGZAp4XZ+JQAoAGGN7g8AnBOpQzM746KwKA3BUhvl0cZiJeg6WTJsHR
YMSq0BYFNPRWJwLlhEZVj0/SeDiLBdmR1oBBscEFKpq8ORWA85ixO96cgFEgnVKDR4QgRhOsvXjM
rI35kKqecgLDXDBOrXk2k8nU1uGCorc6WDp47l5kH+l7mI/oFR6MGWvz4xl2pz/049UsCGws5KrN
lnENnyKiNaCayXZs4RPBT6iAYw7zEajRfObsiZYkZWVE6p7rE+ZVGQIkR7vgqxCLBhhHR3FE4Byg
pal7LBCYz1KZMj1bIcTGcFiNYdfZCgmsdYUkuw7rke6OubgcL/TZVWdx33LiCMc1z5Zx4xNMOrhe
Jq+27V2TS6E4kzJvzIS1hq2eYcsWs8Nal9A0vVBmTyew4fy5BuhdQVSpZ6044s6vH6tl2hrlaxBI
YIHXcfYISg0vj2DHJYJWhAbptSKxHgFrIqiAxfUckzIGTS2W6KizMgYNI1lyFgnl+RM+N4vpWpLA
hCATKp5jUub6AK7rC+NmiDrD8FlMV3UGMmEmc5bAVUwVqgMYXia52aoygIlDLCl7Fk1ZV1WB1D0Y
pzzuwjgzMxd1ViYEq3wjKszBA+8Gl+M9XT0QfXkTR6SGQG3BxAufCmQcmKJN4GvdOyggUCNkrjvM
LJHVK3C86qhzYf4x5habs7qSqI/wlsnhE2TyGjgnOywokHGME4PnHkruF3Bzyu7nEK1ljNSzN3FB
2KuSZ7ywzonpzhgWUVkCjAIZT0AW4gU9BZY/tz5LwTbxwvAJ8b+H9Upl+ASM7SlnaSzBkxY9aFmA
huAcZPaQ6+e6XPCPcyz6Ga19a5XrKyP61hmCHmPjcfLfInyGIdrOEaHiPH0Klmgr1wBAaKGK/dwq
ARFoH2526JyeLEpMAAgAlSHbkdbDD8j314mNnvaNpxEgCa3akX5biRhiwsy5E79LpBw+jWwE1mfn
tNdRMRuBf7vHTH3UMlLg9CRLPJEk0KA6nVcHtN8zIN7Ep41I4RAREVSPmTz8qI1JSmd1PPxInekB
s7o1Cw0lgCtTnTi+leJig+Hvm8fMkRNF1NOa/dwarzMnilh1VoQ1FOfhh/ZWk8OCBHSRc+QZsDPS
nV01E/9pJXpmV53VQZ5qKCF3b04arlpbiOoxU8GCUKJMGrydkLCGpKaSHeV81JC03FxmInqUFvJs
C7ZCE7iMHBdF2I4sYC8bNiZ5n3sUmgA8OXxiXXNPBVDTYcFXoclsC9YKaRixCD3vnrbk2Floolqd
iUOXrgSUEpsjKpnJNIHF8EQlw4gpC6XEmxM8eYHDS5ZoS19CnjrTON2buMJgQO2i5xGysrqpYV8c
w5pLHrX7zZOCzOp2sDJOlm49uIJ9Utbuq8eClgFEW+2esR/nGll4pcLhEyQTgW5o7ucgmcDGQTwf
LAFOEZowmegt+EQchRgizoZ1zZbGCm0pScXZFoGlI0iYvPkWxsKINVj8Phmx7eCgXb3AwRaHBQKh
CwII4XGcad7Ua5pkfD84gOmRll0ZhyTBc4acPM+JIAOeM4rr7wSes0qGsfP2DpYu1KjZc4oCeYJ/
KZO/W72UQJ5yzbV2Z+KsuNckCICcDdYB1+BdmjcSkRiiwNkjrKEkjBgj4OCZHuAU5vNmq7LFdoRr
GllYeZYnFvgj7m+hep8TuDLNPQdvJIWjDqMM6ix0SpAF7D9b3zXkZvKoEUF5zCR+YprZc4rKqycx
SfKcohI/Qc8n67utriureYuLVZTJo1bKJJlbABiwuigjKXK0KoANUHNtExJbE7YIIrG6GoJnekpi
jWItLTgcx+pZD9iCOnxiUCq19NQcFiCGvJQVxhMzF28ORAAZD7O/2yJXmJ6GaHPG42sMTJAFb12b
N3GCrCY5eHi8wPTwBKd4G1yIxNIC/zeOQ+jgo1qujviWxoqlvvi79bikR4RusafJFvy0EnXeVcMX
HBbUwGS7xFL3iX8fA8cXIO+tGLiew9tAG96ZO6unlSGIhA0HK7Ml2mppYHZ4NBPt57bwVph/STxV
q6fNZf0DACZLd8zn1qB0GNUsSbzPDaMqmu2ctkISEQZbsVb7uTVKpOWVmFPx5jTS9lVq8eY00vZM
cdiR1lCS4W0nvvD4BGRYayylenMauf067tKe5zRuvLU+MXP7HM2zhoGdzvLE3H5KzZcnmucKfOix
YOT2+T2PBQkxS+mIE6vzuQRPzgOsaU5bADjMM2xqskRrKDnMc5VQHRYkHiwCPE6r269I0IbHrN37
HMPbzjDCmzgsL4ue+zTxlZlllJCXeaQ12Q556gjds93gLZqmUY1hBDbnvaNRLVGleiwYRhUBQrMj
rUUJnRfYlAWCZxkfMXCJw90fNXjc7Y0Ea87EsTJAECiCZcGa+0HcfhEaN08yc2zAKWmkfs9ECEew
uy3YvVtr30cMzJKa5sj4iIF5ZJS81QETQO1GWuw8JxixBmMuk7ZsRAhvgWjmbdnS9rCZMbfZI2yX
krEtsIaavNU1YIJcZi+1h7fjdGYkPo7awtpjLVQQR+jAIsSbj8TH8XMsUK4B5r47qwMu5hWXnruz
OlYx9wQj5u0d8+IBZrwVb05JER8AqRVndZJ4OpNi8FyZ5MSCd96sO6uUwBzWjCC3eBOHpYNgqrrM
hGR2RBITx7c5QTJTzIsRW4NSxsASW3A/V9JVYq7Fs75MnneM1MVRhBEDIx6LnlUZMbDIOIE8Glbp
PJ1hpOyxoLPqhBDa2WAmsOGlcw/OSExgRy3q2nGFZObAjL4lWiOyxNqP1sJk6dbUJYEfh/LMoY7C
11RTcoTuEU2Pq5PO6lhEDU3QSXyXbJsyryGIWTzxVV797uIjVtUBvdMk41ugDKEDCMkzwtgyyrzn
3zR4ls6G3GcW8BpXRwwcvM/xGpfAQmVHMnVUWiM6b9628K4XbKbYkbZAOWBbWo7zxNdgK2YYe0R3
3dmWkVFuUPTkjcR6zVw0e8wEaoAdRwg8zWmN7YRC10t05wRRQXRRJTlSMALlAjOu3sQRKOcIWNO8
zzEGxsTi5F5fxcDY4Slu2UJuwH+EpLw+6fCJmK49ctPn1RGu5UduejWsb6R4XyDmt8LbfjLPcVi5
OCoB+mnScVg5JizsSFuKFwiahVvREq3RD6QyIbjL9nN7eMsgojSK7j3Sdg+V8UEdQPSe+HotY1zJ
721iwX7FlGc8CN7cibNMByGLTHxawzaFJ2fPE8unPXJl7UUJTKSd58QKnNICIe15dbxwxtS7WKIt
vM2jE830uT0PzAKNlGP2Jg74yLRdit7EeTMF1nIWurWuAE46hazJ43hiBU7F7lVH6NgBAE46SnZY
MPppjDJOO9KrfhoFUcskT2ulPPtpQBRCc1iQWIEDM9A8jrMIPvAWnDtxOGnYuFEueOYTo+kaxint
ce8SDzvTw6iemalsOJU0RscWpAJ3zyqG7q2uZN69GV7zSbRGiQy5ESLW6CnCCLnxuSouEbTls2j5
SbTdkIb49k/AftTg1Fnw20lwZibALItZNHpGbFTKA9TVaVvWNCGL4BuT+I6lY307IMHwUEfxZX17
J/Dtjqh81beH7q3O1LefPycQOkCxydLteWCY6NRD9KwvRrmAx3stHguK0j6FPk18DUoRjtQkoQTv
czCHFdZ3cht7yA3JBDBowREV5oERAI/LTGdmMg9c4TpdUWEeWOiBHJs58sAAAK5THAXkCdZw2pZX
BeQ16WQw9jxwuaC+aV7dVkAuV2gxJ0+eRm14Tr7bYIo3AxpPlm6LywEfEZJmmYi2GDjzaEJnQLPG
5cq8HbY4ehOH0I3jC8/0MAYGwKyzy1+ZWZm3S616JhpgnXm7EKLH8Z4uwOeYPG0Z9dnQ39kWLIf6
rKqOUAMNzpx0wDXYnuxIJoNSbQTjDp8gStDgPALAo94p2/3BC82+ZdE7ZTZik4ItKM081JfJ3+1B
KSKy3mVi5p7iZSIN+xs9jvNmL3z+5KX2UDJgdb3OgGZlwQBZcVytOa+OZc5g+2Sf1s8VeCkYpzD7
lq3MWdnJb1ytOfKphH6NjkbisKAA/ufewwyQ13Qqg9I6Guw4nwP8Z6Fsad7EGblGqIMnKoW9mArW
6IlKEZaB1pH8OM+Jxcmtx9mwrrlpyNPw055vKeOmYU8z9l2DUuaBCz44MXNNO4+bhmWcip6lgBXM
tY5rmyus/TZyLO2F534n3oQdO1je3nlvghtnidaYhYUsBOzNEO2J2Wf/AjPSdsH52b/AjLRFrpQl
nqvZkdYYmIUshQkpZ3WjfwGcXbNz2uppeQu6c+cs0Vac/Kw7NhNfA8C7pNhhwV1S7LDgLik2I219
4p4lxQ6fql4NCDoHb+8q1CnEHIonBcy5amUizYy0NTkYF1JTsiPFNy8yxd73LXinfwFs2OeP0otu
XJ/9C26ircQ5MdkIH6aGaGMkcDicuNZoR1qXD+8UmfqyI21nPJWVeClPI22iS8fTgJ7s6j5l6fv+
BcEu9w8YCh7jvg7XeDBFJUnREG0HLgPEZHhVS7R1i3ieOd1EzpmTGWnr8EgQI30aae9fwL4TBdpj
iba6C+akWRpoiVYWDBDTo786XuhqgYbC+RxcRc4xi3ifu3ufOXziha6qadq7l01VU8FgduKr8eKF
ro5d6d7n7h4mZqTtpOjZw8QQrecWvAwAcFmDwwIMws5aKsUbiZcBOi/zOKsblwFKZXLBEG1dJ1lB
Oao6DdGLk6JWWXjhSMFol5ChCnbi24GLsHFODpOMbyxgT4UqbJRoiNZjEsRPiu/5I/GkqI4OeGZO
v7xnG5jl28TiLYuSDj/K3o/kKICBl18gW+IRYWT2SqeinolSZqkV8dRNtFk9HgsiYlc70mb1Rm+M
yipmQ/SiIzNwdm3unOD2A9AWzdCTSLebRA1EQMjNEm0dUtjJMLMVsJnT5tF5ZAJe2pE2IwuPHmDV
4jTS2mgksOEBoqTmrC7x4nBESJLsSOuhJ7vbMAyudnUr0cB1kc3qDdFaZySjD4XkaaT1BBnqFR41
2oZoVVQ2dWUjmeqtDmiMdWt5Wt3W+Z8noz1NMr5NvPGgY6SeDdF2Mso+jSxUd+bEVoGBdSh2pLXj
Mg89YdGjFkee2K81ENhNc1ob/GVe8Gq8ZWGI1jkBSYfcVYMlWg9i4Y95DyGqtzqeF0iSFhxmZmZu
Ho04DdF6VDny08rec2cNZrkOtIOVgmfJzJ0XKBqbz54nLoHJht6CNRhbJQ5vNyHqKp7pYatALLlm
z/SwfgZWhOjamVMGx8cdAzvSek4n4Dhv9kwGY72vAWc0TOZkxBahG4d5j7ImQ7Q1egDHS+STBc7E
EZYg5mbq2cxpZWZnp0sgieyIirKxa9EerZpvl+OJW8ooiriJlgDn6NpYLrSt5C0vWv7Mj9o7YL6d
ZMuC+XaSLQvm22mLLJi/R3LAfDttkQXzN5ED5ttJvSyYP6/OgPnz5wyYP3/OgPkznwyYP7PAgPl7
4g6YP3/OgPn7c696utfOO+fmcxuYZ9gLPk1zWtE1TyRbYZnxmZl8rkcRQHfLpw04j7ZmneVEZ3lK
fKgFhr1Hj0jkArSt0Y70NiYmblq5+45ilhOQ9jBxWYH0K0zsEN2Y2CG6MbEheqGon5j4Jtqv4D8x
8U203yx4YmIz0vq5GxMbovW05MbE5nNnTGxG2lp5PjGxIVpHujHxmZkGE99EcY0mb0x8ZqbBxGZ1
K2q8MbEh2uT9iYkN0YuQ8xMTG6KtOOGJic98MpjYEK3G48bE5nOrGbox8U2U3nS7qb/QjLd07p04
1CEyOvdOHHoT7ZeHbp07hilW546w0urcO3FoOaJ9q3NHMGh17p041Fmd0bl74mtUZHTuJtoc0a1z
53DO6Nw9p1/fFLgc96HfErgV570UuDOREbgzkRG4M5ERuDOREbhyMjlW4MpZKm+BexJtptkI3JNo
a1ltBO5MZATu/tz54MNMfLW6RuBuoq3xyS1wRxZYgTty3Br5e3XbQzW3kXeIbiN//pwx8k+i9Q1C
a+SfRD85Rv64wdbIl5NFMQcfZ2aag4/zSObgwxCtRwP3wYchWntQ3Acfhmi9z3UffBiirdrrefBh
9m6t9roPPhwW3AcfhmgtmroPPpyR7oOP8wabgw8z8TftpbySwrfs5Tm4MfbyTGTspRO93vbySVTC
e3Pk01vb0O/ECPXPHLbXJ8hxIv6byIn46xn73hF/dQKJZ8R/E+09yp8l4/WIM2NuV4YfKnZ1+7EA
8x+d9T5m4msTsnHnhVfSvM/dPcrrEbE+LjvzOQM70tbK/plTd/jUMh8ySfOc1tX1xIdMcrPbsvmY
uzy7npF94EXQKjU725JgFqU3bcH7XApXkV5a8z7H8uzEx94s0Ranj8PQOq3u7RA8v+DuW5ryZ9BZ
fQedOUS3tXGIbmtzEzlpqZvISUvVo78x6MyZ043ObiInLVWPSMigs3r0pgadGaIzOjNE57TUeXUG
nZmRzmkps7pzWsoQndNShuicljJE57SUs7obndUjyDHozJn4jc7qEVAYdHaek0FnZk7ntNRZngw6
M0TntJQhOqelDNE5LeWs7kZnZ2YadGaIzmmpswYbdHaWTIPOzhM3aSkz0jktdTY9Ji11nrhJSzlz
utNSZqRzWsoQndNSZnXntJQhOqelnInfaSkzp3Na6iwqJi1lRjqnpW6iP5KW2lbyTt0dX2b/9FAr
2IJiwm1Awg3RfmdQv567MUTby1HCXhkshbyJtqMBZSujwup5Q7T6Fd5aCY3XJs3nts4y4ZKco0Y7
0lqge2AJnJL51cJIcZAF8O0XI1cYyVZGge2sDNH+snLlHd3ckyHaeMSH/KLA/Vqi7aAxsLtFBx4w
RNs1Th1vKwL/mjltGYB8Jfh7sXPaT5DqlVonaDAs+HXd3MRLO2wlaOa0ZgCULQvgVy2f9nwe8G/n
9WI78RU38fIAdFLt6rYnyHlDEwKVox1pQ/fsFdkxfzunV/11B6Ms0XroAdNcamrNjrQhadiAlvKy
d9tZVEPEoXwJxRmJBbEIFoNlgWwPkxKEIri1LIhbVqKwCwgffTdEW8JB2IeYj74bol/e0x5eq9kE
7J0QoNU/86P+lNIXIcDn48A30fmZ9Jtmr5F/Pt9nBtrChOfzfc7X7rbbhmgzwohTO2GrndOKtvns
L1C7iDdx5YMine8rmM9t73ulq0IAa/GIxtOdyodbzede3aRusc2f28w5ezYlsMqOtD2TTu8hMGmG
6GW2nNub7EivSl/ZYjQ4Ex+XpEtmh47z3pkHhM8cNw8In/dupNTT6HRoPreF6qMlcZxHevlSGFyE
JVpBK+ObWLuk5k0cQJrPI2V1pCApb5k2OtnztiTlUxzAR5OobJekH1ebq6ebCXa/FviQ4E2cj4BF
tvb15sSrzU15zOKMxKvNfB1kUoT1fJaPyhapKTojZUAEwNE2K+d2tRlYC/JUJqHbwik+KgvnkBxR
GU93lboI3dbimg1BWpzUfHuSarzK1WdFWK/njFe5JPKm4pnjWUd/pDTt3RYHwvsD/cHYOaLC9l69
jtaRDjPZ3gu+LjRHnjKfqKV9moRua+/F3jGJz645q+vsESwwLI5ysr1XKZHPrp3NoUBUGrB5F0eD
JfLd+fGY43nifH84dYDz5PCJTwuXOF4NPHMcQskypDJtyxZ2sikX3xL3PMKIAxFxRfUmDqsCzNBz
8/hUWK4VeZfvbJ9Gz2nwoFVn7xgsNsBHcVnQxgXSVIMjTzKePcX3iqN30kdIFSbJ3C7asoeq6mwL
tkutI/Coiy1YL/+OJ0IIXx2souOJkDKg+ZEFo0tWrrw0ct4WJVZpDT7BsSqj53Qej/E6q2O40AOP
xZyReNdYIvvHnO2TFtgnfC++0OBvX8MbF5WxnslMvv3u16sfb73VRiuZ2nJxFIfdrvvjrrshWhc6
eq6GWDz509FONbIXliN/vCT4uBB/1q6CkAd+L88+e7svXYAmM9/ZOStOYc/VmrsLykbf7BzGMcNR
/tg3O8B+5kmZFzTJx5yAlLILW0bfbOC75HG88N0RIM6m3sTZ6Qubop755KVqNliIHrZh32w2WMjZ
Yya7tyYegjrKXHjo/Gi076yOfbNTLb16UsD70qo8VHGYCZBfU62zz976ZveLeY5QvNXxBROI5yu8
9VY7sKMJ8IJK2o5DBMfWEY1vxRqiLe7iq33A9wBkZqQt+fRsB2ZGWg9R2Bkxdzg+S7TdvGa3a2hK
s0RbkShv8Te+Ru5MXHiQyidVLFF9z3TyVCiNx0jMj981na9//OpIqWMJYom2zmCQ4iLis2z4CNWJ
ZVuoWh+Hikl3bphQVdiTkTrqzOl+jt6MtGWVmaaANauGaD3USOPJgcJmMWchNT2tzywwPa0N0dbP
69nT2nxuPXcSPm3ewiTu2+cYYMIZTeK+x44J4h7hY+znthrWcNH+iDh7l7DB2JOcXRbwlWlEaSV4
zKQtA8wNk1l49YA0HGh2V8cAsyjbA5iR1vgj8GlzYDN1bMd4QLpU9rQ+KzMMEF+KZb39eXWjfzQ2
2OUT83VwZ2xjZEbaemextiABw3mrE97VzRKzNyc2mVYJsy3YAkx4WYiCdI8FbDJda6wTx9eQHr4x
Y6a9ehyvfNq88CzCmfhoMl15bOXMqfF1L4REEzO355GUas4+GWei8fiyiMxWZYtCC18f1JqdbZHI
J+VimV3fGoJBVGqAOngTl5HaDV08E822WHwLOagjdKMtFqQgNYfjDDBjpio4HB8BZgPuLt6cdDRs
A2rxRirsxYZ4JzjyNALMR6txZyQGmAAS3fPZ0gNtQUrT3m0BZqMt4GtxZ+UcLx/x1R9PMpmyLCy7
mORpe9So8dVoPsF5E73bT0TTCy/5FiDL+4/+/cf/A5ibNhtlbmRzdHJlYW0KZW5kb2JqCjE0IDAg
b2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgxIDQ4OTM2IC9MZW5ndGggMjczODAg
Pj4Kc3RyZWFtCnic7L13fFTV9je8djlnek8ykz6TZCYkARJSCIFIhg5CIPQEiYTeRAgRUC5CUGoA
wQICKs1GlYEAhqIgclVAxKuCBQRUUCwRVMSSZOZd+8wEgZ+/373v877PH8/zYQ7fs3Y9e++1115r
7T0nAxAA0EElMMgYPmHopNG7CpcChH8CYHts+NQHnCsmfTAVoLUDQM4YNWn0hGnJm34FSBkDIPlG
3/fQqNgHpn8J0O8HgF5Nx4wcOuJY3vVl+MQDiJZjMME6wbIZw9cQSWMmPPDgsQ0VXgDSCiBs3X0T
hw8lc74cAODtivEXJgx9cJLmPf2TmI/tgfP+oRNGvkFG5wO8gPFow6TJIyd9v60c20vHuLYBRN/p
v374x7yLq4aY8n9VR6tBfDZ8lZwq6O67dr7z5/aG0ebW6h4Y1WB5ohTAu6qtvyd0MMOf2/1Z5tah
9BsfqYlIkZrgrQCGgwQUzJAO7QG4HttlQOVQFZp3Az76MdzLKyAc0U0VC9OkAVBM5sMguhlmCLBY
8PKtMBnLbsZ4O6T7RF0s3x9xHpGPGICICqUVIoYi+oo4lt0r6uIzJonnKLQCBqnjYaI0INCA7a2Q
3oZRiDUY3sC/go1yHkzA+AtY7yAHyBVlsM4KeTOsxPRnMX84pq1BWozx9RgejPUyQmGNaglECoqQ
MT0Fn7MoNN5k9ga05BWBL3AsJfjMuxHzsI0ipJ0R3bGMDWl7xHzyNiwgbwc2YD5SeBTbny/SER1D
tCs+Zy7mF2C9JIw/iuEo7IeM1IRwIZrQrZBHw+AA0nQc/8DguBFvwxgx5htjwv6H+vRfEexj95uB
bb6GSKR5gUtINTf17XY8ehu6sSyoRDoeEY3oTU/ABN4DCPJrlXQJmABKpuDTOcRdfAT0xDjBfvaV
dsFqEUcUKqgINPBnYR27Bq0wb7q8AscxAvndAnEd0ukP0Ex2wyyUr474/NmINfjMy4o8jIB+2H5z
pFn8kiJD8xCLsa0rjXwSvMH4bJzXPthWvVgxWL8vogvOSyXiPtEfbD9d8FzMOxngz8OyF7HMYAFM
tyvAsQuZFHVEfXyWOySHG/6isAHLLEG+XkDKEeGiD41Q5CwEzHsLnxOJkBGxiOaIS4gNiPGI1ohX
EU2wbcB2mSKvKDNCNhX5QNmQ3kYeYt8UmQ2OYY0yn8E1sz70LNGOS94K40NwiWeK9SJkFvuyo/HZ
Yk0JmWmkinyPF3JPfhLjFDJ1g+La499DF9EHZQ2ibDVSse6wz2I9rKD9YQHS1SjHjwqZFf1rpIIv
QtYUnuCaCNH8m8aaoawRpAwgMSTrjzbSRl7coGPgBXxmmTwMdco66MofgK7scRjGr0JHlgLNpQxM
w/FgWR/9HvqoD0EWzmUvjK+6ja4UUJ0i46RDOM4tyM9T8BzytJyfogn8FJGkLYFvJSBHpS10phL+
L/R2kEPBPEEFbs77f5v+vwJ6WtqCOnNL4DvpVCCA43lCrAnV9yQD4WykmL4TUYlIVaeRlerxpEbV
H8wy2jbERO6F1pIXcvkhnJ9w1PO4FjC9v/QFHGRLYCE/FfiUVEIlPQXzVOEwlK5AnYZt0dPwqIB4
PtJJN8nRLTJ3uyw10kZ5vZ0KnR+SqXikMq6/90K4GMJ1xK8oR8+TYBu5Qj8r9gF1NGJeUF4Df96Q
z6PwItJFjfJ5m5yOv00+9bfL5e1UsS2o3xvXKfZjYeP4hX4UOk7oSKHnhJ5pLH87val+Fd2Mciz0
8AkYFFrXCSHcjX38MrT2UQ/jfA8MBOTOgZflXYGNzBrYKGdi+BOEFHgZx/3gDZtaHPCH7GlKoy0N
poOu0Y5KWTAhpM9eUPTNz/CUYkcHKP3TyNthllSH8446UOnvutAaRH5iv8fzMuT5aliM44hk83E9
YjpisOCJMhcADmEXhE1ky5HPwhYtgUfZGfQXRN0ssCj2ogAGYt+PKmloUwUVadJA2CB/D5m8P+ra
QzBCzJUYh+iPmHv1FDCow1FPnIIWfBOWCQctllun8MALLytyIeqOR78IeaEaDiqU2Z5YRjxvvVLH
C9YQP15QeKHUR19EyJfgBT5TDoc+ij/xPayV+sNAXEPrVZWwXu6Pay4cNuIzXsR6/UVfsF6UYq+X
wz24vhagblqAOgcU+R8UqGNbcDwPol5HsErk0RZwSJXIw/HK2DvyoI6dL9YP2wweISPyctTDwp9Y
DlU8DTrJ42EJpi2RUE9iu4swbQ6u3wxcuwuxfnxIbwO2vRDTRd0C4csIH0GsF5UXbHKl4geA0gfh
p2D77FtYz+6GBSjH7dTLkQ9zoRnaC4KyF4doEYQSnxnC4iCUNHOQEhczw8NKehZ8QDczHcqtsKF7
+WwYywdAJmsBkdwCzfi/cK3+Ac8wEwzhx+AZXgOLRZzboAnz4fh3oW8p0k9CkUinH2B8JQzi+Vh/
AdzPh0AF24Gy9xFo+Sica6wnPYZykoT1f8bnhkC+gkFsAK6teRj+I7BVlFPa2BUYKMC7QjOl3k1Q
+tqI2/pMuyPf7sY5xf6K8C39xb7e6GdjH/+mf8o4xXOxnijDnwHcMwTOItxB6u9Nl8AWxDr6GXRg
hfAQ2YgK5lnoTC4hng1hG3RV6A5Eb7TxOWQGojnPgVcRszHcFOnriO3BOPpuOXAGMRef/QbSarEv
EKDtoaWgmLYGsRJxvDHvZoi2/i79ZkjRcGt8N1QKkGuBBoHbyyOfW2J7LfldyE8EyuIyAXkWDFJN
xflLxvQ4fOZtcWwnk++Gcf+uP/8O5CRkKDwMwnvzGBvnA2nEf4CzN1GnoCHb8P+pf/8rwPmdhShV
+PsjhIdkyEhOQwLSAUgHsCnwoADGm2G8pJGfBHe/CjbCk0r6jfkLpqOs4JYS7ro9/fb47fP67+K0
Gl68GY1ycEMenoA5ArwAyyNuj6uPwhwB+Z+Y98//Gucv/xsMglS2WukTKDJ2W1zuhTYTQZOwr1FK
ncUCN+IncS0jRFmlvgGWCChrF0F3wViBG/k5qL8RN/G1peArtqnkN85P47zcPj/YPy9/DzEIbcV7
kIG0L9J2jfSGfIf0xS0y3zso7zfiQpdcuq3MX2vir7VxUtiav3/m/03AtXMM8Tbirf/dbQktI3SE
WeiJs+iHFKAfeQr9k3vgUYAG1CX16YiXUA/1Q/oxpqH19qcgDBi2YNpopM8B1P2K4cmYfiqIAOXR
sC7kV0Zi2p5QXXXoeX2D9eveAfgTJerP7cH6dZsR4zD8E+JhDH+O9A2kK7H8d1hvDtLDwfyGIRif
ijiA8e8xfh+iGMPLkIYjbYqwIaxYf4WA8Ef+yz70/3f69/uP/5SizzIc+xkvzryQzrh9D/Ef08b5
/Df09r1G4/z/O3rTmcFtNMgH3DN9iX6f7+a9z/+0x2mkOJ/+m8H7BxrQp9QLP1r4ssJ/VvzHEFX2
b4ofi+0ChDVS4TsL/1X4zsJ/Rboe6QJZUvrTX+zzRb9AMSkKYpQFAZo+GMOQthi4pqU4gxXHoNAK
ZpJZZCl5gqwnPnKWBGgJfZsepZ8zwhjTsEQ2k1WxxWw9e4/reS8+mA/hT/Kn+XP8eV7N9/NP+bfS
XulN6TvpmqyXo+V4ubXcRx4vT5DL5ZnyPHml/IK8Sd4uvyufkv+Imxv3h9PkDHfGOROcHmdzZ4Yz
y9name9s6+zonOic5XzB+bJzq0ty2VwRrgSXx9Xc1c91r2u5a2MCTZATTAnWhPCEqIT4hJSEtISu
CUMTRibSRHOiyw1u6ta7ze4wt8Md405yN3Vnu/Pd97kr3XPcC9yL3U+617u3une697kPuI+4j7tP
uj91f+3J93g97T1lnuGeUZ7xl6XLjsutr9KrLeponbOuZV1+Xdu6dnUd63rVldQ9XLeobnldoH5Y
Q0HDz/76QH0gIE6oYZ3CuXVkOzlB/kTOvYWc+4TBDc7NQc49xp7nhBt5b34vX8ZX8NV8A3+F1/BP
+GXJJ+2X3peuhjjnkr1y2d9y7mpcZdw6p95pc9qdTuRcKnIu05kX4tw45NzzyLnNt3Cur+se17Ib
nLMg5yIT4kKcK0sYoXDO+d9wrugG55a517k33+DcMeTcJ8i51jc4N9Iz7jJROEeu8jqCnEuta4Wc
89Z1qOtcN6Buel1V3WN19fX3NrRFzlUKzgW+QsFcHgijx+hrLD1wlr6LK8KEEvkEmUbGk8n16zA+
VsisP82f6k/xN8HgDJgOU+E+GAM9oG395/Vn69+vP15/of6D+pOiZP2q+pX1W+vX4/Vk/az6OfWP
1I+tzwL4qhTgy7PBU/0LcxHLv7jnwpwLf3yx8cI0jL2KQL16oerCw19MOT/u/EMX9n3V9MJj5zee
X3FuxbkN5xYBnHtJ1D1vP1d+DjXzuYxz3nNZ55LOdj7b6Wz+2byzLc9mnc04m3I24Wz02bCz5MyP
Z74/c/nMpTNfilpn3jpz8MzrZ7CVM/888+KZ7Wc6nWl/pt2ZpDMJZ1xn4qIORf0Z9YX5dfT0Xle9
pHpO9azqGdVq1SrVStVR1TbVetVatF/fym0l3J2y4WLtkpa3fk9Bvw7ilvhVFtEYZyPgf/iwnqhp
/j7nMcQa9Ih68j68DOmwm3P5vYhRQfx3H14kwPuEYj3/p37cVtPDm9wIJ/2PJbX/bU6PW6IMnoc5
MJfdCyvga5gHj8EieA42wQvoIlQhWx+FJ+Eq/ARL4GlYAIfhLFyBNbAZfoGf4RpsgK3wDrwF22AY
DIdlMAKOwUh4G47Ce3Ac3oUT8A2Mgn/BSXgfXoHR8CM8Dh/BB/Ahyuq38D0shHEwFsbDBJTe+2Ed
TIRymASToQKmwAMo09PgMjyI0v0Q/AMeRjl/FdbDLJgJlTAbvoMfYC9ZQZ4mlDDCiQR1UE9WklVk
NXkGGsBPZKIiagiQZ8lzZA1Zi7poPdEQLdERPdlAnofr8Bt5gbxIXiIvk41kE9lMtpCtZBt5BXWW
j+wgO0k1/A6nSBVZRHaR3WQPeZXUEAMxkr1kHzERM7EQK1yAL4iNhJH95AAJJxFkMXmNvE4OkkPk
DXKY2IkDtoOPRJIo8iY5QqJJDIklceSf5C34A/6EL+ErEk+cxEUSyNvkHXKUHCPHybuoM98jiSSJ
uImHnCTvk3+RD8iH5CP0EJJJE5JCUuEiXCKn4DSch0/hMzgD5+Bj+JxcIVfJT2irfia/kGvkOvmN
/E7+IH+SNFJH6kkD8ZOmaMeAEkopo5xKVKYqqqYaqiXNqI7qqYEaqYmaqYVaqY2GkeY0nEaQdJJB
7dRBI2kUjaYxNJbG0XjqpIupiyaQFiSTJpIsmkTd1EOTaROaQlNpGl1AF0pmyUKvsNnsUTaXzWcL
2RK2lD3JlrNV7Dm0nC+yTWwL28a2sx1sN9vLXmNvsH+yo+wErtV/sVPsU/Y5+4JdYt+yWnaF/UR/
oj/TX+g1+iu9Tn+jv9M/6J+0jtYzLdMxPVoXgoN6gb/IX+Iv8418E9/Mt/CtfBtale3cx3fwnWiZ
d/HdfA9/Fe3MXr4P7fQB/hp/nR/kh/gb/DB/kx/h/+Rv8bf5O/woP8aP83f5Cf4eP8nf5//iH/AP
+Uf8FD/NP0Yr9Sn/jJ/hZ/nn/Bw/zy/wL/iX/Ct+kV/iX/Nv+GX+Lf+Of89/4LX8R36FX+U/8Z/5
L/wa/5V8RS7y6/w3/jv/g//J62AH7KRVJBt2wx54E3dH1bALjsAj8AbMR13Ui/VhRaw3688GsIGs
mPVl/eBX8g09xGfCAVgFtbgyX4QnSAEsJe3IVPI42osnyTSoITNILfmRl/PJfDavYCVsELuHDWal
fA6fwqfxuXwqn8cf4vP5Ar6QV/FFfDF/kD/Fl/DH+FK0yI8rNvkZ/iz6NGvQs1nJV/GH+Vq+jq9H
S/08y2Et2S9M7BFlgMYvignFG71N7WAm45KsUmu0Or3BaDJbrLaw8Ai7IzIqOiY2Lt7pSkhMcnuS
m6SkpjVt1jw9o0VmVnZOy9xWea3b5N/VtsDbrn2Hjp06d+na7e7uPQp79irq3advv/4DBhaXDLpn
cOm9Q8qGwrDhI0aOGj1m7Ljx9024f+Kk8skVD0yZOu3Bh6b/Y8bDM2dVzn7k0Tlz581fsLBq0eIl
jy1d9vgTTz61fMXTK1etfubZ59asXbd+w/MvvPjSyxs3bd7Ctm57Zbtvx87qXbv3vFqzd9/+A6+9
fvDQG4ffPPLPt95+5+ix4++eeO/k+/CvDz786NTpjz/59LMzZz8/d/6O73jHd7zjO97xHe/4jnd8
xzu+4x3f8Y7v+J/5jt527bwFbe/Kb9M6r1VuTnZWZouM9ObNmqalpjRJ9riTEhNczvi42JjoqEiH
PSI8zGa1mE1Gg16n1ahVssQZJdC0U2LnMqfPU+bjnsSuXZuJeOJQTBh6U0KZz4lJnW8t43OWKcWc
t5b0YslRt5X0Bkt6b5QkZmc+5Ddr6uyU6PSd6JjorCGDehdjeEnHxBKnr1YJFyrhZUrYgGGXCys4
OznGdHT6SJmzk6/z1DFVnco64uN26LQdEjuM1DZrCju0OgzqMOSzJ07aQextiRKg9k6td1BQG7BT
vqjEjp18kYkdRQ98zN1p6AhfUe/iTh2jXa6SZk19pMPwxGE+SGzvM6UpRaCD0oxP7uBTKc04x4rR
wCLnjqaHqhbXmGFYWZp+ROKIoYOLfWxoiWjDkobtdvTZp190/BXFh1s7FM+/OTeaVXVyjHWKaFXV
fKdvXe/im3Nd4l5Sgs/AutTduayqMza9GJnYva8TW6NzS4p9ZC426RQjEaMKjm9kYieRUjbO6dMk
tk8cUzWuDKcmqsoHfR5y7YyK8u4NXICoTs6qfsWJLl9BdGLJ0I4xO8Kgqs9D1ZFeZ+StOc2a7jBb
gozdYTSFAnrDzYGRN/KUkFJchLr3ucFZInqU2A0Fwucc7sSeFCfimFqJ28hWUDW8FRbDTwnBWr4R
OCNjfZoOZVXm1iJd1PdJbvQRq35F3V6WWPvDrSlDQymy2/wriKCQkxuihvmNYV9ami81VYiIqgPO
KfaxrRLPadZ0ag1NTJxkdiJB9kER8nZoSet0ZL/LJSZ4UY0XhmHEV9m7OBh3wrDoneBNTyvx0TKR
c6gxJ7y/yKlszLlRvSwRJXmXsusL96k9N/6ZzBG2TmNa+0jE/5A9MpjfvW9i996Dip2dqspCvO3e
75ZYML/VjbxQyGfrUMyiaShEo5mSi0I5+EZhESnW+7gb/8mKUI+oUalRKpUU4uzsM5d1Dd5LtC7X
f1ipJnBV1FLIX9VC3fS1Trs13uaW+C3d01cx7DD30O79BlVVaW/JQ1ELNtgtRFDioV+xy9nBB/1x
ZbrxX03gUCuBkmifF1nWQRRA+QsmhaK3FIwOhUvwI6SzWdPOqOiqqjonOjtXlVUNrQlUDkt0mhOr
9tLD9HDVpE5ljYJTE9i3KNrXeXEJ8moMad2sXSKYmB2uIAIIBvF4T0f0QgxBLEWsRchKOZEyETEL
cRBxVcnxMvvOJ7K8NUgWKaR63H2ZSnRoMDq4VIlWDywJ0sLeQdqxW7BY62CxFtnB5ObtgzS5aZBa
3ZmVgmoNmYfaRaDr/j6CwiS8E3oETIRAPKxj4eBDUCaHUrzMWp3kyVx7kHFAd4ARdEvjA4cY2Wmw
ZLbT0gC9AlaIpz/S2mAOra02WjLXtrubfgnbEQcRjH6J1xf0C5hFL+AKMOG9ALEWcRBxEnEFIdML
eJ3H6xw9h6U+h3REAWIIYi3iIOIKQkU/x7uZnhXrSbmLcAGC0rN4N9MzOKwzeDfRzzD0Gf0Mu/bh
zty8zL1KIC09FIh3hwL26FDAGpFZQz/Y+UdKfA39qtqZFr+uXQb9CHwIio19hA//CJyIIkQZYhJC
xtBpDJ2GSsQyxDqEDyFjndNY5zTWOYZ4F3EaMhBeRBFCTd/fic3U0JM7Pe3j20XQ9+jbYEemnqDv
KPRd+pZCj9N/KvQo0jikx+hbO+PioZ0O8wHrmJGakaZjvkTfqE6yxgfaWehBZE883tMRBYheiCGI
pQiZHqQJO0fEW/Eh++GYGrDkTvhWoS/BBjV4x8V7PR1Qxpzi5ml9F4bwtta51kO9nhWrMCpunsee
wJC4eeYsxpC4eabPxpC4ee6biiFx84wYhyFx8wwagiFx8/TqhyG81dA1ryYlx+f2Gk+c7Ux0GnJp
GnJpGnJpGnA6TVzwBxd9e2ZnaipybLU3LSU1vnIfqTxAKvuQyg2kciSpnEkqZ5PKfFJ5L6lMI5Ux
pDKOVHpJ5X7SCllRSby7bonmeR2k8hip3EYqK0ilh1S6SWUSqXSSXG8Nde3slqWQTgqpbifWFdK7
2maasI8u5KgLxdqFy/4g3k8iAkrMi4WcCcHCkXGCJlSnFgTjzVtnTmzXlb6JFd/EaXgTziM4TtCb
KEZv4kPexAeY8F6AGII4hLiCCCBkLJ2AHV+q3E14T0cUIIYgZiGuIGSlO1cQFCaGurhd6Vh6qNO9
RIy+iVcCXi7q8saaY8xp5q5saQwxxZFecYE4mgsRYpdvtagtuFvb85vh998MoGmnoY/RpRCLE7Es
RJfu/CM2voas3OnZH98unDwNcRyljuSBh7iRtoIKJZ4DMWpBsyGGbkGauTNmAFYz7fQ0jd9HjKLW
nvg/Yi7GfxtTQzF4OWZ//MfOGk52xp/ClC174j+KWRh/NL1GjSkHPDUEyT6nUnRvTKv4bceUorMx
Y/XO+JmC7Il/OKZL/PgYJWNkMOPeCox5TfF9PIPiu+LzOsYMi/dW4DP3xBfE3BufHyyVI+rsic/A
LqQFg6nY2ZQYpdHEOOWB/XNryBhvU9UKVbGql6qlKlPVVOVSxatiVdGqMLVVbVYb1Xq1Vq1Wy2qu
pmpQh9UELnjTxAFwmGwWRLwzQIArYTMVd3FWLPQaUVO4G3w21p1279uedPcdGg7dhzl91/sm1hAt
GlApsT3xWbtD937tfa3SuteoAn18uWndfaqie4p3EPJYCab66IIagtavhgRE0txo4aruBUIsc5dE
C9pk7pKSEnBETC1wFFjbWvI6d/ybW1nonvbXx3FLONa3onvfYt/m2BJfpggEYku6+54Uvuxe3D9f
7dRxL26lkZQU72Vtyc+d+oh01rZjSUn3GjJAKQdO8hOWQ4n5SSmnjgOnKAdOdVyw3OpgOTfWx3JJ
gmA5jQbcSjm3RqOU40SU21GR1KnjjqQkpYzdCRVKmQq78+Yyx9xYxu1WykRUwjGlzLGISlHG11Yp
EhODReJilCIkCmKUIjEkSiky4K8i6aEiC28UWai0xMhfZWKCZQwXGssYLmCZtP/0M7J9WhqpblMy
fLDYB5QldhqJKPMtmjrG4asc5nTuGF4S2iB4yoYNHyPo0JG+ksSRHX3DEzs6d7QZ/DfZg0V2m8SO
O2Bwp37FOwZ7R3bc2cbbplPi0I4l1V2KsnNvaWvhjbayi/7mYUXiYdmirS65f5OdK7K7iLZyRVu5
oq0u3i5KW6DIeFHxDjW0L0G3U6HVVKdFeS2LdpW0jzBPaqsIbxuXY2b0Pi5e7NOhF67HHZ0BIbKa
tWvWTmThmhJZRrHZC2U5ZrZxRe8jG0NZZky2JLaHtAemVEwBR6exHYP/KvCDSQ9MEQwP3tMq/rsP
5nXCfVvHigcAuvtS+3b3FaCfu0OlwtQyMSRf68Y0na4TupvBxOaY2FokMnajoEjLF2kaTajgf53/
KSHaQayCSrq/mnjjyANQUcJ8cd37UVQF/UJe9T50l4R5qCjBAVaQNFLR+Ayl2xAMgxhvIx6YEgqF
+PBAiAZrYZWKRnbc+GAdVFXSPohEREkvQyT3gAMg8A3isqD+sYHLIl9Q+h0WrgkBYCNsI2NhGxyE
w+QqiJO9vbALhMfTEZ6FGfAUzEcrNghTFkIfvCRMf4pEBnZBOqxHO7YeTmDZgTAT9kEEcQS+hVkw
l32IteaCARKgHRTBRFhCegSmwGA4zx+FXOgB98MkUhkoDjwWeCLwArwIe9k7gQbQQRQMx+tE4Efp
k8BZaIY1lsMqOE+e0OwGL7ZSiSWfg8mwmpVyEhgd+BN74IJp2AcOhXCCHKJp+PSR8A1xkBmsAz7l
+YAvcARLxUApjIHVsI/kkC7UJQ0OFAZOQAS28SA+dRXshD141cBr8BnRS1cDLwSuQiQ0hW44nl3w
HjnE/A2z/QWC0cilFMjDnInwOrwN75NE8gadKOmlTMkrTQ98BGHQAvpjb1/Gml+T3+hMvGaxt3jn
QHswIl8eF9yGf8IXJIqkk15kAE2hE+kaNhnU2GILvEbAWOT3Snz6OZSaPVRPT7Ln+RZeJ8f6LwSM
OCMeeAaegzeIAUfqJBXkEXKafEU70CH0Gfole4pv4h+ohuKo74UJsAS2wG/ESlqR3uQeMobMIPPJ
42QVOUHeJ5dpO9qPjqdX2BhWzl7j7fHqyyv4o9I8aZF82V/sP+L/l/+3QGZgHvRGeZiNvV8Oa3Bk
e+EkfIrXefiSSERHjHiJU9/+5B94zSRLyAblDHoXtvI++ZJ8ixboV1JH0bBSmUaLU1a8EulkdCif
os/Sk3i9T3+gfzA7S2BpLIflsxI2EXs1ny3Dazf7gkfxkzyAfM6UVkhrpY3SFumw+D5N9Qia9Hfr
n29IbTjnB/8C/wr/Tv+uwBcQjnOIxgK3UPnY+6F4jcP5XoEStx0+JHrkXRRJJW1JD+TMEDKOlJMH
kZNzyGryotL3V8gB5NLH5Ar22UBjlD43pzm0Pe2F1710JC1H3+sJuouepn8yFdMxEwtnqawLK2Uj
2QPsIbaC+di77HP2JbvO6vEKcC2P5wncw9N4Fz6ET+Fr+Df8G2mwdFy6JGvlCfI8uUb+CZ2Ytqoi
VW9VqWqpao/qI3WZOEWF3fDqzV91kAtsNuvEdsNjNItH4o7lPZTnITCCFVKUVLqRLKAPk100SXpQ
bkPbkJ5wFbf2T9G36Fp6nbZhhaQ76QvjxF+qio8cxsVffufzN6GWH8CxvYdPflDWk5n0iqyHnUT5
u2nyT5bB09hx+IydJyq+Hs5wLbGTWvoyK0IpeI23lYrBxZ6FV1g5eRh2004A2jr1YpTjnmQz6oV+
JJP8zgLo9fZEKcplX8GjMJ5+ArW4jhfA02QEHw2PQRaZAd/AS7gqUqT75VQ5nBylY3kVtZFdQPkm
8ffMJIkwKQzmkFK2Wr5CP4UpcJJr4Rzbir0/SV9hhfyq1IeMwRXwMMyD8sBseEgq5h+Q0cDIAHDz
C6jdZrBM7kI6C7XKYNRpe3B170M90I4VYooDJacHykV/1BCr8VqJeoKjBI3FNT4Qtdh7sEvuR2tg
tGQkqHUA+HF/HxgUeAlWBUbD/YEnoBnqg/mBGfjEjXAJlsJGMtf/D5iEO8dPcW33kDrTk1LnQDNa
RT+lfemKW+cXue0mDvgOr1egM7SV9kMV/xj6QkFgceAUSncT1LCrYBj6pxdxlD9iC13ZIcjy96Q7
Ap3ZJBzveegdeDkQT7QwJnAf9IID8KJKgqGqtFAD992Gn7FN8fZ9/t/gAI6vdQgbUBFGIcoQz6Ls
6AFUTRDvAGisQWi9QeimB6H/IQhD1xCOBWEsCsKMsPhwm7MHwPYRQBi2F94ZsQ/Ajo65/SUARx/E
uSAimwNEfSdel0UgjX0qiHh8jvNLANcAgARrEEnozXvw2U2cIcxAfA2Q0jaEyUGkZQM0HQPQ7DGA
5ocBMnBcLWSAzKkAWeMAso0IbKsljiN3GUCr1wHyPgBojWn5yI+7WiF+B/AOA2iH/WuPvOrwLkBn
HGfXKoC7sY0emXfwvwOFgwF6LgiiV9M7uIM7uIM7uIM7uIM7uIM7uIM7uIM7uIM7+D8AlChfuEji
rX4VtN9FyUVZVUNXeW0g8YsMtCp+kUCkWpYuUnaAtgANWUWagyPNfD2/Ib+n+Vp+YUM+FGDYXI+3
Fhkui8vixhsBDvVOdqjeK16yd/JD4m/DfABkqbQPm9PAwB0xUg3d7vWo82UKslZ3nGlaS614PrSS
WxOWT6mTEHJcq9XNdq1f6UhLw8ZK8wvNteaLFxsuXjT/CAUFheaGr7v3La6WOBBizjfnl7TIsDFL
loWxnKzwb3LPZz9/ktzHNKSTf3/9b/6nTpwQvbiXVdNpSi90MGUvQOD36gR3tlQT+N2b4EnJ1sla
lQScgCTJuh81ajVjFFTqfK1JU6mhmprAIW+4wZStOUcYz6fEa7Bkk0h9+csO0cM0wQ9zQ1ppvsIW
0aeGfLwRizUvT6BFBklLs4nusSzlvizzRLPPW5zIYNXEfvWq/9vgXfQzPPANL5E+hGiIJy2885vE
toqlGq6JpQNNr9pejXnb9nbM77EyoeGg4SwMNJJsAY1aZQaNTmWO1upVZofBpDLbjVbZYjfaWJjd
GEHD7cZIGu4wRNHwaG0MC4vWxrIwhyFOtjgM8bIlWquNjnaDJgxAY3A43HZjmN1uDKfuMMbArHJb
5Bqyx9vKaDQYtFoNRDscdjtow8PCLOa2RpUsM9oWHE8Z7E8Z3EavJa+Xca2RGqe4tE9Fa57C5yLz
dlvynECghq6vdm4aIwSpNK32ovniDXpN8Ct4D3EweDc3ICsteel4ny81T3vYfGR+c4cgpts+yOLS
0nK7LTEny+bKcdmymEBWeCJzhbtYos3FbC6ba/TATW/f7b9C0geuGEjaDHx64Lbj3UmE/92BKwb4
3xo4hbTu7v9nJNm8nIxfTrb5+wos9y9f7h9ANvsH0AIyHgcxw9+bluEMmeEurzbZRMBsVanN5hqS
VQ1rjWqkXotqrfFeYGbmZIxttTy3WBlxw/Va8/VaHF5Bvugt8VBLdm7L3CxZhVe4mZDzy98rHHRg
9kPJdyWmkTR/7wPkd2L88bOGuvdLqlbsf80f73fe1r6+CW1iphqtmYBVI3qgXcuI6IEJ1rJ7TcZ4
nIit1r9v35YIluxkD15ZEfaIcDNtmI1SmnBX8vTZBwYVnvT3JhfIFwf2rqga9EFdw2c/+n/2q7H1
yVDLW/M9uIpaeePhfg39Q83ul1Sy5n4t1/4hkfsLaC9KaaR+4CBlbZQWXsuvzTdfzM+H9Gs4i9da
ZLgtOEG4XnFiLJT4y8nSzWSpv7yWPLFR0I3++7Gdzf5z5FE4AVrouVuLamoLymCR16PoCKIl+aCl
DCMgt1K17gVDYCLMgnW4utfphN7Adq9dNNcq0iTuqEAaasVybJGRhesvTFYlt2yZu+dE0cDMvJbs
xInyRZ7CyKH3YLvtSA0dRyegZmzqjZxEJzFaSAqxyUSgUdIkLBDJJy0RI7tYav4a0gtrW2RAOTIz
xxXejqaQmt27xftN+/A2H3vPwO11UNHZ/GAXtwNfh/nruNLL66WlOB+1wU7tOyE0FRFvFtA8nF8G
ffcCC5zbGZZHawLnvM6wvKcZoWwt284omwokTPz5LcFyWnYZ6GWc903YOK+ejk/GtVRrDs61WDel
uGLEnKelhZMsQjYt8xdHSj/8GSY0Tn/UOBbpEMpTLOzeJTsjzTE1gas7qVP3euACRCCsCFPggncY
l+fTBboFpqNGSaPSOWgnW4/wuyM7RPezDQ4fHNknerxqvG647b7w8ZFl0Q/RafJU3XTTfHmlaoX5
qOMzelo+rTtjioqK41JYnMFgr9B4XYnZGRoCGjPq2GXxlgqhK7xGTHWCF7u2LO7tRSFlgbfyNMEs
wS5SWg6l0Ep8CMJmtrbMyoyIsKIQy4kJyR6bOSIrs6XF7ElMUMn9x3+4burOB9qP+3D9Rw89vnfT
jBmbNs2ccXcp/ZBwctfWIdX+wGd+v//NbStfJc/5n75ylYwh434cO0/MxXlkUB3yRgsVXicTWn88
n0WX0lVqvpUTDcgSZRqJ6Ck5plX6bhUjAiLWaZRe8qLJkBqHlCERp+SVqBSp20fyyVwISlF5Wpoy
tqBNLbDnEYuwF6VQmuZKtMiyKgclNYvW7Wr3Yb+nv0x/gP+j7Yz4V7ocGyL6l4/zrcL+xcE33pZt
pDbyfumgvF/1tvpojKqbvkTfzzheP8I43TrdttB6wHop6lL01Sj9Qd2rNhptjjHHmuPM8uuBq6DC
CVYj1QSueqPitGa1LB+LiQqLiYlSx0ShzKmjYpghzlxDX6juZSGWGuLYbYgLkyCuhu73mgjVayvs
H2J/xHyS/XQ2OMFMWnn1lt0FdAidSGdRTvfRJDRpS3cEJxSl83qaEFLFjSiobSi9aLGKseNtvrF5
mhEFNrheoXGWW0EpKZ3sDnd5cpEjLVvmZOP0KgsZ5x6XNCpRWcVV9bnU7n5+9ZWNq/7xyLNkr+33
f314vevLhzcMjtu2rV3+8EMzj1waNf7JZ6tsJz/9blvx5gMvLBjaAkVN/M6aGf0DLRjgmreltVg/
Rr9av0l/VC/1YD0MT3FmRT6AXmYqSatjKtDrDYZjjKOJ5MwAVG/gKraf7gc1ulfrvFrxc6J6PRzT
8ho66lVJ0npj47O1NSTXa1B5ExKzVZWuHNUyExXSYTCEZQM1UydldLexhixWmPRDKTIqLQ29C/PX
ZkU20D5eR2OYp/gV85un8aAdRGlRXpoyoK6w5hlqAh95dVl5LKFZHuOxsfniZaYSFCcs4w3Te3V5
+sqiPL3Xk6dPiEHaLE953akE3bcckmVBi2lhFkJXNMyhzz351lu7/DlkyItsT/3dL/rX4zQubxiP
3CpEnRGOchcLqbDTmzw+knRUecM7RnZ0DrL2c45nI1Qj1OOsI5wPqKfEzFXPizmt/ijCoqoJXNiV
7Ex0usRropYmcV5DkYHi4KPJh0MU72CMVyPFRUsJcWEG1GatvOGw211hVrQEWjiz2UzNy5pq95FW
EEfyvNoC+xD7RPssO7fX0KTqtJCuqA3pimtBbaFIVl56qVAbiighK4gKzZ7QDbJKSI9VSE9iAljM
uUKWSFiEUB9B+WJ11Y6m3cYPaNd/GG13YPSuhmnvz/nCf/G5hZe3fd6Q2+uxnpNf2PCP6Zt5X+O4
jMKMtj+eHV7m/+2DqtqZpDuZQTa9sfFw/eelm0tq1qzcvl34232Rc5HIOTskQgac9+bmRJCUiG4R
3Txf67/NkDQZ5GF4mMzgD6jLdZP1UwzT7Yugiizm89SzdXP08wxL7O9a3rJZE5CFO2OcUYI4nemC
NHN6BF/jUpx6iHOAPjqu+brmpLnVFSdLTeKshriKgxqiqaGjvea0CpPXiUxF58VkNlFTDXl8T6aj
wocWFfN3JlWE39DD4d5wGr6sxQ09fK20Fo1ruRJQ+GvNK02vDclkiMVBNk8uR8Po8eRkh9anKgLv
gGzGFFvYTRy+md1k3KT7vj546LvxE+Yv8V//9FP/9ceHzRs/Zu7CUaMXtO62rO/sjdsemfUyi05Z
OW7dZ+fXjXo6pemRBQcCuBM4tPQN0m/MnEeHDJ8/pz5QuKzXS5WPbN6IsorOPpnHPcpep5XXySWQ
VRoq53OWT2SOljkdCoAKjb1eHfIdynFoBWg/lUEp47IJrx2xF400Kzlxov5lNNYEJsGXvA0X760P
8uqXsko0B5LM1FTaTwdhIqODdlKvvI8UoVIoQnHeQrY4OY1S83zFRExRCS8J+Zpf29N8HSLTowpr
8eOIMgcbtwv9h74FCSckfBI7Xu9nlM7eSFZX+4/436iG23tQSZdyXKMEdRQVPcD9GPZA8hLRAynY
A3kLOqX5MkSpnRKRQj34uhTbzy+sFV34mx4QkiP+8Tb1OYzUB9hxOts/tJoUkPxq/yjhQ0z091ad
kk5BFxgIv3kHcpfZGeFyuXMMWcZOxm6Ojq7OSZ27dRnQzzg9xRjhTiEeTWqsJyUnqmVeB/cAR0ns
Pa4BKQO6lQwY6RjpHpUyNWp67OSkuY45UYtjF7nmeyKN5iIjsL7C2mhNyRm6Ih3VqSL2067QAbrT
/bs6tGbaeMx9tTVxpk1Ko2n7SCEk0/170rsmmVQE97aPek3moraQZF1nSsowT0JFso9sgmi6ZldB
q9QkLK+BRLrGq3HmkJzI4oGLQ75rbQOqEZT0aw0XzQ0o8Om1taUo9BeROQWlF1H280JGCk2TW+gQ
Ie+KM2LPzWJyuBDz3JbWnGyalJjAaXiYlWc5k9Dll3liQlJSMpbOtYIrkwsHXCXqJ3uIqNSWKuvB
SPnCdut7l2wc+/zPkweuyUuoXhaXEpszYPLcLf5tJ77zP3zqFHnyVyKTYcW7s373b/7pnH+h//cO
/UZMJ28Q7+9k0eSh7+75pFP/MIM/4pF+rWaUd50/1Fs+zvt893vGfDJ7LSlYd0/pMw1DF5uik+8q
IoalL5OEV874R3/3q3/NJt/MsZ/Nmnxp+Wtnrn1OTMR5/Oi24/5zXxxLTY4kPRau7DDn+KgFK9ot
ew/nP9AAIJWg9VSBkcR5h6ebM8yj1WM0ZeYFbJn5qPSWfMh81axTSyVkAC0yj9H5zL/ofzH8YtRw
PTdwI9NpNRLneoNRLatUegyrZb0KXWGnSh+GCZQxJ9eHYQlNnCSp42Qm19BJXg2o9d96xZ+o7yM6
VAE6r1XvhJEq1qeIn+TnOVvGCa8hxKsr0h9SndezZXqiF3GzSXVSRWepKlVU9aTp9MfBRR+JwH8O
nNyoSHNtLTgK8qNwsvPFRqL21u1ncGuPVth85IjxyJH5UpCiAuzu0/Xt7ovrPah4FzcxtWof+lUQ
+F3oxBIyubw0ER1w3JTidpR5kmUVo1n/osWfb2l4Zv2n5KdVnRNisqR9f3YmB/wd6SCyYu+0JYtQ
c61A7+Rb5K9FsbizvUWcd04ckDgqsUIzRyOPjZoiTdJU6B6VHtXJyREa5khOjYuI1Whs1rjU1JQU
iImNQy7Fx8VZQO3wyP3cHn1U09g4p6KEStPaDA4qIXG2c72wttEpQ6DhFFvwvHSLOMcgijoQBhQ3
b5kRN5S6kSYSV2bQJfMkoiORmavIL4ZXUM/G4xWjRs9dOrDyjcX+J8lds1vd3b3zI2v8Z8iEez0d
BrXut3yxf5u0r2TvyHtfyko+UDl6R1kL1scSMaqw28SUunUqfavxnfs81ELoulGBb6SpuDOKhRpv
2XA6Lha1dqZhOOrAB2IrYU7sMlgtbWEvGvayXYa3De/DxdhfYi1Ga6wlNpalyk0sqTHO+C6GAWED
wwdEjpHGx/7Dusi6mq0yro7ZSF6gGy2njDYIgyhzmDmKiy3XziZ5RBjC5CZ5ZhMQHm2L07PoOK4x
e0x3g0ccVUXF2z1ONVFHxg0f3KgzkImlhY3uh8UePP0pFVsWMpnYlZWP3LEmZeGyV3mE1ROKQdhA
vuvwXf43L9X6P35mO+lw+Cxp2uZg1uEnN301eMLX857/ktIWV+reIPd/cIn033HheLN1T2zwX3l8
v//bqgOog9fgGhyEMmJC/szxepzxpIM6OPEWc5wJ1NhRtP9R8bHm0LzH/TXvwm26MektMjo85G3J
olVqWS2puZrLkY4oB5V1Wr3WoEWtFhEWYYtgcjSzu4jViDeHOsZFIrQWF6Sl4VhT8TObKEJij7Dj
tiyMooi4XZkhtx19L9ca8seWQTNLHqjoOf3xE3P9O0je4y+26FT49H09t/nflfaFx/YY5j955GW/
f9PQzG0tW3T69qWvf0uNE1KwAdeCeO9eB/d4w2UpTq1WqYBxMVCtJk4HapWYsxizNVvVj93t1DoN
VBtl4JrQqPVt7nGEjhUVeS8tvHYx7XaBxx25cjwRxAaeVL+GpdWfYnOkfdv8BVv9hm2iJxuxJ3Ox
Jxro7k1VerIUjU1jZ7AjzzpxF01plO5G69o2g29r/SK6GsGGS29veSP7vP4S9TUUiVZbb2sYhU+Y
gGtgL64BN3zi7RQdFh1Oy5LJvWobsbKkJHBZ7dQN2DqR7XFGhq6fhhBPsjsJbT72JbkMdxiTK5NJ
cqzHqSXaSM/wexqlttBcel0ctTbkC3c55NqJczeMirWPEJYORaMjT4yOiYqJjGGy3mN2h3viPWo3
9yS6HYZYF0SYbC4sHGZzqjCWILldJEaHMhJmwVucxuWCJIY35a80UFbEId+Nv7kQUoOrJMdtuWWV
RNhVzSkuE3FMJiwoypGF9aATlvrfX/eJf+2ualJ0Zi0hT3i2u4btmTj38DRXq/mEPj7zaltasJU0
XJhcsZfc+8lpUrFrdM1TGZMqC3vP6bVg7RH/75VDc4lFzOQLuHYSFJkaI/ZRuORt4dmcxWm067Tv
a6lWolSnxsXgVKnk0koDMVBdcEKVg2Esi3LlNBAnbmjKDJMMvE2JI620HLdvyuIqvZ6vbOBQwtBZ
VlYYScsSJ2CIRLy/cJj+efhwgyzta3iJDvqzM61uKMSHH8SuzcZeMXhqt5AnKs4SqlvdpZwpVGdl
B2mzjCBtkhKkie4gjY0LUkdU8Awi3WDOdkrLpO0SygLa1qWwDnzA08ELRXAeroJkdWLiMmxuAz9d
oqgG3DPurETLWlpSPjm/obRxnsRmVAhqluXgYWGtsK+5gW/YUMVCFXrNI+lo+QE6RV5gWGCRNRT3
clFeF48zaTQerVbt0ZU6bcRp89qKbGU2biMe6G7dozRYay4tvy6sLcpfbYHi/OYqu4OWOdiYskvz
tNmumjS827gmh0veeOSNE2SdY+OMDhUz2c/1kTXHxp0TsymsZapy1p/l1ROK8yiB2il8Afqy16ii
LLQY5ZsU4NelQR0QHJYrfMVh+gEO7ZdtWHAlgGzC55nJFO8soCZ1GI1W86n6efp39Eyj76bvZmIp
3G1oaixm9/CphgeN8w1qHZXUeYaWxl60O8PNsbrQ0N6oXUlXsRWqFeqN7GWVbKUmozFDomGSRNV6
gyFDUmNQre9j6kO86NSoxe/n6QwGo9EMag0ts1ZaqXUf3QgG0mKn5FTXkBZerV6jdXr1s3REt48O
QO9Lhzm0Bl0hDW7unKZJZmKuoQNedUplUqXEpBq6sdoipDNSHJGW5jtw6Iq3g+GoG5GLpej7FOQH
T+BDF+4IFB9o/sOKD4QEp+cvZ+c10AfqQB04jd7gacXX6e7TY14TzBNL6vcdRq1IDZ1UfLTHlWds
6lJOK/bk5hkzc5Xg7maYGjqRSCtBbwnKSxVDQiLsLXOJC1cLSSSWlSSJ3JMREZlDhhBpv3/Adn+x
tK/u58e7Fj3D6v/szI/X5fALdU4hC8/iyo5XdPR3O6w6sQ5ycLmqhUepUqNvqaYqxtQaTqlGpebM
KctSqVNHnLjHKNNN0lXqJJ0albey0PVYM6TFg8sjTVnd5dduLG9lQ4BeIW8eZBARf862S+3tnMfw
AXs656m9mcFgZp4qIVI52N0TicHMYFCkJgaPe3WJeSpjGMIm4tf22DAYGwzGYjBcBH/fER7ilVCl
yl+9KYxDESZCtRDLs28zuu/tej+yZzafhayprKtEX2E4WpHPpY/ACNEwy1sWZSJh5rCwaHt0NOdm
Hqaz66L5Jvse41tGZrc7oqkz1mvpZetl90YVS8Wageb+liG2QfYhjgFRA6MX2VdRc2QcY9Y4nSbc
40QTGFUZS2JNHsGryJibHaNS4RndfIiLbpHNLDZAwklQdH6uGbIywZJN0TGC4WQBaXmcdN6yy7/n
4En/vo3vkNiPz5Doh759/D3/x/QYmUCeO+x/8ex5/7rd75BBr/t/858k2SS6muie9F+CoFfEG3D+
DeCAgd6ckZbxYbS7uXvYPeZ7wrhOH4dLEOyOoL22etRRziiC/6IchpCOiLzZOS4vvS663+goKIo8
5A3b49CJoy6XBcM3fBya8kThfU+U/Og/6l9A/nFgTWmPFnP8C6V9RuvIPRP2+xsatjKyeNbgR8MN
2NP1KKnoCGM/E0gPr8mqMxJry5hB8aPUE+K5tSbwZbU1Khvp1eqE5GyLiMcmZ5tD1BSimP9Jdawn
mI/lzSEq8r0VGHAb746529lXNzhmQsxkzYPGh0xztQtMTxs2mWpMl43fmMxGvd5pMYVZLCaLSa+x
RlNXVIRWtlrMBr3k0Ggi7FGRcXY7uBIUnjkcJpNRHecxPiuXOpMmJVUmsaQER4h3iW02/uXs4NxH
XnTU3vh2T2EhJuPmQjn4DZ77Sje+qAh9gueWWrXXlGcyt7ZYWwv5JuWKGjHiMomKzLPgQrIijN6Y
PHNCGCIecWNllNy0WUF31JbImlOcnURlppRjJ9d6WnXk3enHPixs0r9H4Nrh/vcPbObq/gVZP3dF
z6ef92dI+3q989Czp2PdST2n+MtJizmLW+lUDVNYVu5DXcYo3xMMDnzDv0evLAP83meHs+G8gj3A
uTs5h+XFdGDdVD1iO8V3TOqc3JeVqAbHDmyy0GZsYvAk0SSW7G5pyk7s6O6UPsg5ILG/+z7dOMN4
46iwkY6HdNMN000Pm6ckVbjnsSrdQkOVaYl5btKj7icMK0wrwuPcSUaDTnKhjx+tVsmcUZm4kxIw
DV3R6GZLUYprI6CZmThJESkjk8gyIqMl9nndzeLiIpgU10wT7Ym6W+OBFJISlenyWInH2k9Zsy1u
uIXipOOW/Yy5oVQchVwTR0M4Z2IbTEKnROW4om25cTQrM+TlJyUrx3/KdzOhnU54mD2C25XZQFue
5Bn8qmHIOw9P3Ny3aHAb/329x46e+fNTz/8xT9pn2rbJtz6vFfm0uHL6vLrn3vb/sop8bL5/ycD2
FR07jU60D03LfX7kxDdGjH13tnHRY7Pv6ZWVNb5Jm91Tp5yseOBbHEMGrvt9yolEL69BonHIHlB+
QkxTQyuqncGDgVdlJ6Hp4tSTkN0k6NBhrnrPquCaF6JrbrhY+rVZ+SaxoPFlhxzlq0ubP5ZX+aMl
w7Ztf/4ipGA9alXhRYZBuVfrMRXzYvVRNY8QpiMCTUc2b6PuzO9WTzW9JF02qfRALeJEK0bWhHlo
qTOCOCOKImhZxKSIyggWYVA8dFFXg3W1peHC5oiXDUqFq45uUlCRKioIVwlB9yioQBVPSXGaLLzs
8Ah/3Ufv+f+cdLjLtodP75H21e/43F///GPE8C3rVb/z4O5hh5XvEcX/4qGaKrQPWeztmAIeS4rV
48iDlpY8a0tHN+hi6Wbt4iiGgZZi60CHeaV6pYkyjo6LrEK/WKvT6zUGo8mkD7NZreKXfh3hNYH8
agkcTkH1Voug3kHhaEtBEm95QBgh4JDU6rhwR1h4uMOq12jiwq0YtFr0JpPTbAkzmy1WjV7tCJdM
FjNySwrXS8xhNqEbqVZT1D4Oq9ViAXWU3R5lbqchvcEJeryHI7wgkd57nGKLHhlZQxbtCGmiqMjC
BvRzGqIiGxw9O43s+PWtbxvgJZRR6LWNxjOewpu9nlsJ6pf5RvORI3jLP9IYuvmGbpAJ3SALukE7
rVpHTeB60DdyY2Kq4huB+KGmkCdlxJRqvVfyYiGc2MmlLpJlU1yfLJsViS0L3R9xbETIGv8/3j6f
FNVKS+zffdArMabZ12/679/vP56ssof5j+JEFzy9/Pskdq4hyv/DL4t2sVfQ+Jcudo7sUve8mG8N
WptuON82OtCbgks/kkToaIo1xdaK5LJW6laaVobWxhxrrk1rtTmtrmyruBlrAheqkRpCVBOiavHF
wzsY4KIUE7dpZJqOeniKqoku1eixtuSt1a114old1f14qXqwbpCxn3U0GcnHqcfrxhpHWqfw6Wqh
8qZZp9nm8SpVlXY5r1G/an2LH1V/zD9Rf2o8bf2GX1ZfNn5tbSp+W1pDxA8CMp3ZbDMZDQZiNhss
VptNh2OjBh3T27Q6IpupTaO12ZzBl1sYNRiceham1zOtRsMYpTaDQa8HdXo4CUcpcuq9eqqvIUNe
dWqXaQ9pmbaG1OweQtdSij51jVcr7/Kai8wnzcyMhbxaJ0SGhR92lW0UbypdE7JV6rgUWVtaW4oB
RbxKb5Gv+dItogRCwPLyTCYhPfnqIzeToPQcCToYpNEaKmZPJ7zDyDwiTJ4jOs8qTqqi82xBwmsC
l/dE56kTovPEW0s7Y4RffcgbH5NnQ/PIEAZjhD3fZo2w36VGa57PcHt9l054nM1xl59gzdPpY113
EYh15eu0IkRFSG+zY5rNjmkiRDF0688lkJvCaJ/RFGQRkhV02zEUkloNzfXrvyHavoktOpDkDxsa
aNpV/9J4V4tw/zJaT1/3L5hSUDSQzG0orP+D6prlFMX5ifI7MiitnVFa9SR7j1rTmvE2OLhvqq12
IXrfeI0Y4JF4Y+KmET6QQ5HKT7ydMcCb4M2KwqhO1aYb+RgyRh6jOydzIT6yWqWRZY3MNE6tLkyr
1clM1jAnJWGoYWS9TiZoOIiuhkZ6NVotShCaEWMNdXg1ek0fr7ZSS1FGdnsNOp3eCaxPL7pUkZXd
O4mwJY49BmNIPq4La4LmM0i+FtYkX7zxZAkqnPnN09To+0hCNERgvjhVNuOtu8+OiiFGnCer9Ro9
3xe4BixwTfmirST4zYPwkDQaFAc1AgXg3I5I4fz89SMbLstfU2GhbRqO/0BcRZ3a30tivmx4lU5g
hf7OM2ZULCPb66sbxH87Dov8Y6lDsZ6tvPGcpRFqluQ0UFlx/Cr5FS65FWO5Vf3cmEbvuPHdrcYz
RBtuohMtWeGLyJJPP/WPVfVe/seny299v6WHN4kQdNgAsRKQYctgHTrCUxkNE2uz8dWWGrLpVXqZ
kMY3W4IH1Le/2CIpL7b4Bz5ONgZfbSGQ7B9LdimjyPbGcClNJZsZTQNilSWJ0Fc4c6tgq+YZ8QXY
tb8ZAXHl4B4qx0V2+Ss+/ZQs8Y9dLicvBxL4wj8WDf/32L0or54UiDeDIJJ3aKe80NH4VhBDJyGe
b/KPfeQRsQ+5O3CZx/C20ARySaz3MY1BkxppiEpNMaSm5hlahudGt07tllpqKE0dZxibWpZRZZiX
sjrimahNhvCXIjc32RO5v8mRyJNNPgj/vIm6YwSJt8c70pqmZufxvKbdeNemA9QlaaPUY9Om6ufr
j+r/MPyRZsnNNhJuTk/Ktme6whxDUiam0JSYdGOBcalxrTFglNYatxuvGJnRGMPsNXSzN8KxPCwm
RgWdkrWZMUyXMtQ8FNyupBp6j9ec7AWP2eP0ZHi2eyRPizxFo8QlZmfkHcqj6/JInt3tSEhPOiif
lGm8XCBTuUUr8SU8zhRuj9Oul9Yify9dEv7KxYLahuAX8uW15cGjxby/vmcUG/7g92jCb8xVrpzs
5OCLHm2p4khGhIeHRdgTPUxWGanyDZsoxPJH7B23/UCXiq454z8bTbI6LZj1UKzPcf/7CxdsLjJr
7AkHYuzDjkwcnDlh7JgNnthH+3feMrfn7J5hRkNUklt7f7O7Ssod5Yu6e4fe3fzBq3Vz72pFPm8S
Y25SmN617J5ed03DGZyHMyhOEsR7Uqe9W4mkNyVJOVInSSqI98XT+PiEmKyY9jGT4pfFy61t+RH5
UT0iekSVqksNxabSiHujxqnvM4wx3R9xf9Sh+E/1n9k/i/zS9oP9h8ivYi/EB+IjnVK6KT0sQyow
eaUepiJplPRZ7K/8T7PeHG7kMoXoGNSf2vAYo86R9L6OmHVeXZmuUsd1D+BWH7KYm9JDBH38dcRH
rhIeTwpIL8JIZFyX3KDrUz5ZnO5eE957ueI64j/la52gEimfDOUuXLAWdNdxL2uGxIRkht76X1/N
N3t51+Qdw7aXe/0/v3ZgPM3u//jUrS9OmbpV2tfw69JeS49V+K/4Tz9HVhzsv+jE8fffEt+PFwUu
s1qU+ig44e2i0ZP4mA62Dva+tr72MluZ/Rn6DFtteMH8QpRebYjUjqNj2Thpin6SodLwkn63Zo92
t14foZ+n/4oyY8IQ00TTLBMzESGs3TKUU8symKTojAtwFR0ak0mHTr81RqdyxHBdjImYkowJ0diL
JF1aPGoX9AW7xYQnnVSReFWBiqpaRGcfUbRXuXhjZHLohzz34gJHh6x28rXayY2n4Ja8dDNue0ov
Nm5ziD34wkjou97GvY1gFsvfEXvllc/8v03+duG2s/HbI2cNWrD5hTnjHiNz7a+eJLFEu5XQ2dvX
R4+/780PTx9+BCWrM3LpfOjbvdPeLVrKDW5DtqGjQcoJy4kZSPtp+4T1jRlNR0gjNcPDymIOxX8k
nbJ9HnnJdinsiv37yEuKBEXEx6dF/T+tfQt8FNW5+Dkzs/Pa1+wj+8hz8tgkkJCEZENIjGaRl4hJ
gAAKEmXZbJKFTTbZ3SREULE+UEuV0mvFPi74qI/bB6+ggLWmrfW2ai94q23Vv0J/You2tNxeyr+K
Se53zsxuFrHtvf//JczMN2fO83ud7zvnm1nCdkuzCQ8KVUyJucrVxNSblzILzYucS3Kvl1ebe8wf
8L9zfYLPWxScxVqMihU4yyjYELAWa/TUYeSzWX2KcsKGFVvAtt62zcbZkvaSF4XjwklhSuAI7toF
VvDm+5fpjNV6FliKxlg2n6Y+CTmmWYsIdWH9JZvjwGY4MwRkbvil298c2vjGneu/Wn1oQv3O0PC3
nt6y+dF7/nnHxcf3YPb+5fMYyyeLGPtrr/zw5bdfewlwthSkMR84Kwtw9l6gqwDlZjGr2E5Dp7TK
GGY3GWJS2CgqSMEKU2Z/y/CJ80K2MNve5J2dO8/emj0vd7l9nXdFbtDelx3M3cxvzrrAXPAoyIWt
Zrd7mYs4Yawr17pT2aswisLl5MoCIown4YccwFzuALWqpLKZ/v1mbM4uIAvtvlI/uQbyiGYswAWu
OqVECJTM9GegTJfFitaJ023KIFgFgxXUj5s4TRkNJtLBZj3qRDf9BuMpZtMWxpxCIXXucCGNYeLZ
m45V/vHoh5N/ws7/8ya24E/PyAfvDu2YeJtZbpq7+r6tz+DV7sfHcAHoAhMun3xv8mNF3XesFz90
z/zeJ8l87IDpaRvMx250KJDvlLDVW+2t8Qa8A96vm75hfsYsZpvLzfu9417OS0ZXnl3gzxPNrMma
K+MspsLp4FgeyXuc2DnlCHBuH4dYZhemK6aHZs/105VTObfAvxPaetzj/T4+hgrRBSwjYhTBxE2M
IKX5rHL2bKdmFJF4wEabttfkVGy8JPAiTCmKZM9BNt6ag8HYnHnHHbgCGCtOZui6en8DWWUAOSRi
mEVi2A7u2ePIvnP4unU5c2tXLDh+nP3ajsFN/kXX278pL1q/Ycen3cBDV08uZz8CHspHM9G5wHqj
0eCsNPqc1xkXOnkpz5tXaSx1VhY3Guc4rzUucq4WbjD2Gj+R/5JlqSquLLuq+Kqy68p2Vu6tFOYU
zpnRUrnIuKhw4YyVhStnRIRQYWjG+sptlW+XnSn8Y/GfymxuF591hDkwVp7rEKgGU1RUQ/XXNjSO
TiDCXbcG5hlyc63ywqJck+zKqvPVyT6P54QbK+6Ae717m5tzJ63Yh4oKSl60HreetE5ZuQJri7Ud
tKK3ojJZSAQS/BAikOfJQs0gWby4QEKgT9M4OHJt1hdeB91ka5bOnWXAXYwmme761C5LZoRW9z5j
7fzkrfd6LHh4/zvn+l//0vdveTL8zt4ffPTIk7duffq7t2x++obs5b7arrUN+7+Im9/djfGO3ds+
3fjX45u/zc58ffzF13788o+B+tsRYs/Q9ZEDR5GLBD5muf0+rp5dyB4zcyxxIkvcXr9btJlsTtaA
kTXXIDiNssknBerm+KckPC5hqY0uqLj9c/z7XedczIBrr2u/a8rFuRinT9+Qg8zniKWpAmZPIQ61
ZS1e5tHDbOmKfcV5LZq4WZsDiQFO2c3CWwSfhTflYLMIjIaIW3MHqujUtuvoQlaWrdhGscJn2baP
3TY+/L2lY0Obln2pGabBP+/qfOIbEzczj27f0vHArRPPA4/dCyLWTPfwBHRroLNd2intlfZL49JJ
6ZwkIKlAGpC2SXv0pFPSlCQXSDBXCRzDgldyG/g+Bp6TecFnQPSD+vu5ce4Ux49z5zgGcSp3Au44
rk1MjTBOX0IhI8t8/aQzPkhD2GAU946NjXG/P378YhZXevFtEr3z2ORy3ET7aEePBFrBujdcwdUZ
7jEY3KLBIHAcwxkcCJuNDLjOnM1gFEi/jLyQa7PuBLkHz9lkMvtkeacRFxhbjO1G1uh1OL9buDjF
kHRfuU0hHvEgamkltgfdT0530VZXt10RtdADi6hYS0VFzsGSRchBGhFIiH1dFm6gXElWuEi01D1j
k71Fcwoa5ozVzXt4Cffh669/vOURy5Jd3LqLe19q7SLaDfDP/pXs7OLXAtkCv5pfK7FW838aLvDs
KnZEZuy86qCu4rlD9jLiOp4bg6vdQBPoCse5wF2QwnPgLvIN0mLADj9LvkEeYYfkt9n3eeFJHhfz
pYJPbOTnSi3mdvMabg1/g7BGupUbNTwivcz/O/dL/jT/ofB/+Y/FLLssG1iWY3hekCQRbiRR9Am8
UxB4luN8BtlpMICfCTciBvqSX9ESjUYkc+RDsoYiES6BYpXaL9k7Yeox+hDjA7sPgR/SDvzmNZl/
U7i4exrvdAF3MLWCqy9GwPTsbiT+EwkhhquHBlwLQAGxmaVnLag4IEuVeY2SmJfXzJP1hbxGuLxx
UKWXA4V66DDdpRtE+vIEPzV+sJBuch10kct7B5VGXrvQOxO9HDCmdvmwtq4RsL/LYdHpgtaczmZ6
glIXDnpI4T8cyNGy48411Fgl4qitKwjA0PhfPpzciF98b/LR2w3HPv0+3j85PNHFFNwySd7ouBPY
oIFy946jyACTUsNcbWPcX69da2ZrV+19sPGAD7SS1VBg2GM4aeDa4XTOwBYYBgzbDFMGjvxyLMNq
iobURBVONsxAexAeBzOUydA6XFomKyo0qaTKN05HQkZw55i+ew6akS+FmagYvXwUSVO/DswzmkEz
nuZOS79xf6Aa3jRcUBm3qBZLnhxVYtni/Fw+K9cIIoj54myvIp/wYfIrU4wPZNHi20mD9DsPe3w7
c3AOQAEvYuqKffgEwtTHLkCEW1jkLfEdwZsPTQsq+AgTp8kKxfnOCbqABW4BmZNBoVBWsrkzI0Es
Jqej1Gmy5WC7OSulLumrCySQnC78u2n0L9WZdHLO1J6P1j65cfjhgtte+ed/OVS87qqBfxq7oeu6
O5q40ofabt5ww7F9z06UMd+M3tz00BMTDzMHN29e9rUvT7ylzyO/BWy50GsBh4HlHczTyhHlffZ3
jnPsBQfPEZmdDQgcVfBu5YTnlGfKw6mi0+J02WFCwbzLLJstJkuJkc4qRgz/jW0eSkgyq3jOeZgB
z17Pfs+4h/OwTF2WS59Y7JdNLO7UpHK+WfN0YVrRVhGIikvPKy7eJsmiLMgsr5TaeEsOtsp2HWEk
6AWEh/J01hzdxc1A2PbHht5d/+gyRR6buemaxFNc6cP7Fg601t46kWDu6e+bt+u1CRL9tQDs4TLA
iRl50Q8DnXZB9poW89eIq/k1Yg8fEUW/0mRvctV7FipL7UtdCz3rDOukFUqnvdO1wtNn6JO6lD57
n6vLM4KzJN5gvpFdaVgp32iKsmFDWI6aZHcuJ9iA5ZwlNL7KUeLz1wgYCYqggmk7+yRhNEj3EuMX
YEsJCkAWwmgMmp1NDF/tPZ7Bis4LnZ3Tr/IQ74AuYHUYOqQNhg0SBzLuoJH4SI/Lz7RFFjxx30/e
wa4tv//iycmzRw9uv+fgobu3H2QcuOyB4cnfTPz891/A+dj82quvvf6TV1+BprdPRrhCwIsdrLzj
gW+ZlFnKlcpShWtR96tMgTrDVJxXm1Wbd3XegLpTFZvcTTnXuq/NWSPeaFrnXpezUdxkiih97k05
4+ovnO963s3+Rf5p5+n8U+qU6irmKpSKrHquSVnEXausVT4w/j5vUjHaLOA5EGedd4GzjizekhMy
VuSAvF7eJnNyEjvqmDq7D6HPddcLwF3Hn+evU4fd1pjprjtSQubKcjI0eNjGZqBq+xNNu3rvPbFx
6OSWtQ9W2Z4c3vztp5KJA5MRwwv3L1++Y2r345MXv3hd08RF9omfv/Tqm6++8ivA1zWTEfYU4EtB
uegHgd1GpoKZ6bmCWcqMmviWrBbvUu/O/L35Br/Dn9OSv8CxIAec+ZyQI5SzPn9b/hv8m/bf8h+a
PvIoM5giU0VWI1NvWsIsMq1lIsxbpnc877s+9P4251PGijmzMxv8TgvvBHcKWdyWOkS8TitWrAHr
eus2K2dN2j7H68zLv8TO1Yzc882X4wcNYpvupM/RLdtLXM7KmQ+vemHyT7Ff3PaTwccmCr+zOfHk
vuGhxycjjHhFG67Cwt7JO5984JP57Hd//vMf/+sbv/xXYk3cDebSy4AdG7ozcEW1AyscLub83Hyu
g+vmkhwv2URJlMwOm2RGrIiNlA2QLJXvFLFYpDqwgymy/U0r1b74pbSVelrpPB8nsYFkUI2pl36Q
8rPtFhp50xkncTEa/TW/RwBdcfdjV0VabrzpqquvvuImZz5X+ujgNU1PlS1uWR+feIP0v2XqDHsA
+l+D3wps4YqcRU3StdKCktVF4aKt0gPSXSVPOr5d+SPWLLmzPe6apZW/dBtymFUMo9Ri2bNOXCet
k9cZ15nWmTeKG6WN8kbjRtNG81jpWJmV7PaWzJhTslZeY+wq7SpPFidLtpV8Rf6GaVf5w5UP1Twh
P2N6vOyJ8kOlPyl15ZHtBnt+41qxzGeSuWy1NIszVuVlE8cot8Db4m333uzd5z3u5a3eAm/Me9LL
FXgf9DLe55lV4PEj4j8pJEZKwSfASsIKZkig7iGny08DdvMtNj/GVevyonlMXm6WwOVWGQuycXaJ
N+Dw+L1HmBsPCiUzIedzuY0nZuKZ2bWkVCl48+trx2uZltpttUytgjEuQWqJtehk2rianXLgB1vJ
+5XxNqr0iQ9/vkJfLhoEN74CtHmcCm78dDp80q1NBYGyWfnF4GiW2hS74lBYvsis5iCpXMjBhllw
ynfCbaGlOAcVFZtN4gwwg8vLJJmv4HJQgZJHJg0taJKe6LbLzIo77iBeyiAx81MRc2TZtKwK/Lo5
DZftwMMfCVehjl7LQet9W7Zurvd95eVH2ufNnfnljltfWGvbb0pEtm50uapz7nrx4dWRl289/ha+
MndTPLzgymKPr3bJHW2LR8sLKq7Z0uNZsW5FQ3FunkMuqZu3dd3aPdd/h3BaydSfmZmGR5AbbTuK
ZBKWWOqnr9HPA2CbFzwck1nGLHIpUoVVBlXJGq1KESrCZrvPhKcEcaG0cL0wIGwTdgocgjlmr7Bf
GBdOCLxwjNmIPHjOgW5NWOiLvuDVnSZa4GwLfV/cThwK5WfazoDPra09kZUCWwN9w43ujzNK9nXN
G6KVd9116PBhR0V5/qN7lKvCjzGhHViITn5px8RXWiuzyVjuBKk5Rb/+/cJRlE3WfcBCZFSHi4TV
nAvMsDv9FQ5cIjpcJuxwGUHgbTAcVOfyedzUxHDjcTd2t2VTsScmRva5bGYge2/2/uypbC4b/Nu0
QiBvw6rSCfAEOanNm3Zbz6asC9AMdO22OfXqCbBUNqdYzFYz2YsnEdtgY3CmHGQWbZrzNHPmHdoW
or4IV1ZKHSj3dGAl27L1zZseb1eMY0Zb//LlD1wx9o2xa/ra6xPMrolDX5q9eHnHg/cyjeAsYvKe
JHsGcCHjm56rBxe9yNYoE2k22xolMK/8IjkxR6Y+OgRXrF9lshMn5Rf6UTmc4O5MQAJrG7ngBHdv
Bw6XV/mRCieraQYql0rlRlQvX4MWy6vxamaNeIPUjbuZiBiRNqMRPMKMipulEXk73s7cw94n3Cve
L30T7Za+LH8HPSa/gJ4TDsg/Qz+R30Zvyn9A78sX0Xm5UkYG2YNccjkqlRvkdgSejSFgd/kNATAU
ZXCyfJLslCQZsQz4UzQ6AfwwUN001IAXZIlF2FBtwqYiMRAIaF+FwDmHA+AWMAaAApLKBHCR8aN/
p4Gs2d6JzonObM/Z0536S2Rp58vWeFkcJTg2g9MxTzTsKbXz7wAv53uT0R+c9hV4Kv5wdLKfK524
qye2cpi5l3jv2t7oc0ARO3MgoFideCY3Q2autd1oe8DG2gh/SgWFfiU3T/NuA98tKPFzvEly8DmS
127gEMcbJaNFtCvIwTqFXDHHmAfGm0+YKVZY/KheaBKvsCxgF/MBoVVcapxvXWy71n6jdYV9k9Al
9thH+VuEpHiUP2Z91v4X/qJUbrSVo3JzmaXcWmavds5FDfYR8R5xN/uw6Sn8NPO08UnTYfQsf8zy
U/CK35LOcGesv7Of5z+Rcu0sDScRDJIsi0aTSVZsNpCvpYcMyK4emVoS6JatFvXHNkFUBZvdXmEQ
wFUWLLLJ5DNbnGazRbRZrRWy6ITiJMZEpyJisGDnRKvNZDHLNplj7WaTibwzQMhqt5L4P9l5QTFj
Eri9zcyaj+CnArLaLuOYfDvZ3WVWBaR2G47ZbreRgJ1VAaNiwOupP8gC4Z86jC84LnTTacHber6z
0wNqH/4TBuj0fH58ic4RNnr+b4SXCBalmRwEJsfS/QUdN4yZVZPKfH/qFMJwWKZOjKEaq2o/MnUq
/RLmmqX7/R3gkotTJw4I5N1MSCjsWLq/ju5ziFOnDgiqlmrXw3hJUN2JZ60qqVs8MnXioFBDajyI
5jLHtJbSlafLuWk529SpQ7LKqUjbl8Z6hN4bz9obUSUcZMHAQbelNQ+YRvYSJqc87nDT2Ba2jMVL
J58/9kwLV/fM0T31Vz67b3Ls+Wdm/AqY/uunba8w/RO7X/05033xbWbr4U+Pk98IAn30H8D9Ch55
zmrH1iIvXWwIPOttXGv9KvdV8RHL16zjhnF+XHjVKlkDrsZs1iFlmbOVetxkvAM/YBSr7ddza4Q1
xhssD+Pd8m7jc8wR00+Nr1heU95m35ReN7+jfCDb7TzPakEnvETDTqxWhUSdWK1mJR1yosi8lbHK
ysvoZYlRfOmgk5fN2OzLjDvhFRp3IrfbsX2J+TZTkWwN8tJtARkUyXMBfhm/jb7iNj9gUdnbmKJ2
GOgS29aX9FfnqW4B1aJ8oJw/e1mISVVFp85AZHOcxphYrdtpWMlL2hkuAg010Vd5xiyevEYaAmLM
azQVuRtZOMj9wcJGhS7fZzXiosJGKZCbCqokVASLgyzIkDgPN9FUDWQ9hi3DVnzX5CO/ebwqt9J3
6FeTX8ZffPftpskPmXI8+fHimqvrLk6aJv4NX7tmspNor8LJ5ewfgX7ZePshay62kl48kdtY7lxt
3SezAXMAEKqW1/gVchJMkt1l9tjLjGWmMvMc0xxzveURm7HcXu64xrXGvsaxJitijzgiWaP8sHnU
dovzlqy7zffbdth3OO5z7pafNn5fed52zPmR/DvnX8wTysfOqdx8UAEmBfQJaH6v0+Hw2WUn3FhN
oDB8RtlpNMoOu91kMvJsrteKcpVcpjr3xVwm9wjTctjqCNgDziPMyoCxxR6wMzfbX7Qz9iP46met
uAgtzJHJI7tVNQYCqqnG1G5il5mmaITR1YeqrTBYpmUsR90KyiPbq0yQlw+BqiQA36OcP+0lH4c4
m+1RzlIIeYhxkyKxmLluR2isxw4t3W8BifSARD6PTFNnkHHqDM6QR+fUe882NMpFDY0WmIQPZzXa
9DjZNeQ7FCCSQE9HmbYt0ECjzvQpiHxcobjoducVlc3XuG2lBuNk34/erSgqqHh/bDI6r6Rm62r/
ZM8zSnlJziZrHlc+8cjQHVuHmU0Xf7rv6jUdhM7lIKdvAJ0t+N6A2X6E+ZnI2HGtFsDzbwEJAHxV
Pl2I/VHgWgBmMOVStdKIG+UleBGzSFwitSvr8EpmpbhWWqZEcYgJgQuyBSfFLdIX8d3ifdLH+DyT
4xVL8QyxQmoUvyX+CguEe59TsvwMaCCJfBihDExxpkmSGVGWfZiBCYLB5K1TJkjCQ3g5aEbmCovM
HMHWMZgkDDyJf6hEQpF5rwUjS8Cy3rLNcs5isCSRfBvG+xBuRzE0RZbSrEqykIjo9MIrcU5P090t
ZYJ+h+YDsE4/oBujugWgWF6qoK8Hkr0sPcDr8AxcKhJ/RkOLSJAEdz96jqCH4Eh7dWpwDQ38IWr8
vYNWMjr9cua5nEZJdOVcSab7g26S9NeA7GpknHBku6YluK4e88UklhULc+oKs8qZJxI3TLazXRM/
jI1uxL/fxYr8rpGJm7ZIXwfXp4P9T2at4RfICBb9rwPr9oB7xvxJ+JODOSmcdDDHheMO5kXhRQez
T9jnYPYIexzMg8KDDuY24TYHc1G86GSiYtTJrBXXOhmTaHIyTocouE1WI2KtH1vYjxmLmcGmZjNq
Jl9+WBaodsSE24UHwePHjrnOZovZ1AxTdcCd7bcMYWGu2Mxg1MyyDzKY8Xr0z3Bpb68p4DqTT4tQ
CLWQ0CTw1BTtI0B0TwT+gx9NvAMUHxwcxIP6P9yJs4rJVmKDm+eFwgwYO3+ozryxssHP4n9KQdxL
r3/rnuZlMxa5b7x+GgJMLWY/ZNoMP6OYeifQRjF1TjznZLCIncwp4ZSDOSGccDDjwriD2S/sdzCP
CY85mF3CLgfzBeELDmZAGHAwYTHsZDrEDh1TVpORRc5vOwhuTGZAmQWQhcVvCyShBgMCGdSMscXa
bAJ8lZndV5lMZoIu8xDDsM0IUFaGSDTsRootErJFVpaaKaqAR0/TN1jOah9KSl0vRVYaT4ODgDdt
P8YpaF9SqsuAr/9hQcWNlXPq2V+nAO6vgKArls9Y7Lq5YxoiWiHKfoivpLhKBkp/IbwvMAeEHwvM
n0X8FfFRkUmIXxCZVWIYTHARi4ABfcD5dMDYCENG6dHR4XlN3xxNM4M+qonMD0ChFNkJ3TOHsPXz
ekt+y2MR24bIlzvIv0l6Zulv2Mn4Kh1mkMXwng6z6CbDuA5zGXkMyGP4ow7zyMLn67CAXuIrdVhE
pcJWHZbQ/eYndFjmfkRbJrARbbBU6bAJdVt26rCZH+PP6bAFrbNcoL/GS/7dbl2hw+DSWP9Dhxkk
2OfpMIuq7bU6zGXkMSCTfYkO85A/qMMC2mDv1WERORyKDktooatEh2UmaH1dh41otiuiwyZwi7+m
w2Z2rf0VHbagKhf5XhbmWOibyXWRwgaAFbeRwjxJd+dQWKDpZRQWKdxAYUmnkQZrNNJgjUYarNFI
g7mMPBqNNFijkQZrNNJgjUYarNFIgzUaabBGIw3WaKTBGo00WKMRgeWM8RrpWBZT2JSRbqFjv57C
ChmLu4fCDoDt7iEKOzPyZ5F6dNiVke6lZbdTOIe2pdWZl5GnIAMuofkfovBMCj9O4VkUPkBgMaP/
YkZbpox0U2osK9EoGkBh1I2CKARXFT0Dx0rUS+FWmEr74UjquVQ0H+7iAJNzENIjNIcKKVEoXwXQ
Apoe/P+sqTrdMxV1wJMoGkrnSUDaErhq7c1GjfBXg2bpUC1NnQclonBdAWV6oA9JWmoF1JeAI46G
4dxF+9APz8KoL92TOLSrQq6g3pKWPwIYUqEEKU9q7EeVtBXyJEhbCul1BSFFK9lHayQj6IXe99Ea
I/AkSXP30rYI1pN6Cwk6whAtm6TP+2kt5Er6FKN9iOhjGaB1kx6FaK8StDXyhOTvolet/0O0NZW2
kNmrCK0/Cc/76f0IrbtXbz2s543RurS2U+lRWndSx0gI7jTMfDZfEuoMU6xE4KrVHdJThiimCa2m
uSRG6RKnGI3S8qSnhDv69FKpFkK0/LDeakQfKXmmYXMaC92Qk9SmpU7jNaJjN6aPJELzD9G7aaom
KMdGae8+nydSkpNIj4U866P1TdcRh3Y26b0N6vgPUZ5Wdb5P4ayLtt1DU7XyI/AkotOQ5IkC7TUe
icG5B54N69jWapiW5SCllcYdKsVhSB9/hFItSvMMUDnTuLGfltRGksndkTRnqfB8s06ZPtobwpsa
3RK6JEfT/eijd9Pcm/yMvkl8ZnwhvY0NtIYhiumuS3gzjAYhPYXZIfpLiqkRdlPeVikPbKa4TVC+
S1Jq9KSpTvquyTuRpcq0NCV0LpvWR9rTPkqRILqFltd6TeoN0afTnKa13kWxNUClZDQ9ilTbpPwI
fR6kmIjrbRAZ0rCYpOVTPU7VPkB5qI/q0FTfqi7Tq02XUI3oux7K/4S6TWi13l5K1xJdORfOKniD
rZQGcSoPmhzNyKirFfh6+u57lM/jutz30do3pWn8/6rzNbr06JowrOu3aT2l1boK5gMVLaPlVVRK
22uFczu03U05N4UxwpsJiu1evbYq1Ab5VsLssQiO+TAiArdDKim/CM7X0fSFkNIBZyIDiwGLC+Gv
laauRGb6RUKZjjKiy+Fn59BUutZjjXIDOm2nZeFy/GhzXgxwEKfc0Utzp8aT0vwpftpAn45C/qF0
m6G0DtVwN0TLTuu+sC4dRENN62tNT0R03ZzQdUcPrSWc1r0Et2v01ogWGdZ19ob0rKe1mfw7mEnx
1khaC4Z1yQ6nZSdO9VRS1xvdOt9/Hr5S0k4wFs6oZVpbXN5el85fhJc3UA2s9XqDTpl+vebPo1AZ
HdWlmNI0/+VccXnLKR1KtGWQWjRBaDWqYzuh66q/1XYV5f3+DH0+ehktwro1kyk52iwRpD0aoJgl
81aEyts/prmq82J/hg5NtUukv4tiOpIxW8UzLK7KdO54Bt9O2wh/H1Okd320/hRfxS6pb4TSfxOl
ZqY2Senh6ZwxyKvpmSGKcVJ/b3o8Wr8yubtP19wa/jWpGtD5Y1rDX8pDf29E0/yxhI79csqlbDwy
t4V1S1AbjWZXhihV+z9Dg/hn8D1dMxlfjGr+Ll2vDlMbbARlWnH/mPqp+jSZDOu2xqUzcqq+y+mo
YWvaMg7ROi+X4xTFgp/Bdff/qLfTWL68hUvtikt7FNat5STMkKkayCwzD1JnITI3zkV+1ADzoQrn
2XA3C/wNPxw1iPicq9BSPWcN/VVjP/xpcAOqg4OUmoPqwTchB6m9l9okA9BeNfyN0L8qOrdfKvEh
qvn+1jxBoAVUOkfSfKHNghFd25I+raAaWptD23Q7K6Zb8EQ+tZk0Tp9EKAU64Dw9bxCuIp4VsRP+
Z/2upvn7oK1qOCephiC0qqZzz82USzR7oiqd83+3hRFqA2h5w/8rraSeVX+GH9N1rxwdCHcHQ2H1
GXVlb1htjfXHkpCkzo/FB2LxYDIS61cHoqEqdUEwGfwHmapJZWpHLDpEUhLqkn4oN7uxsWYWnGqr
1HnRqLoi0tObTKgrwolwfDjcNT/Wnwz3kUrio2oiCIUgPdKtdoUTkZ7+SnVePBKMqiHIFYzAw75Y
PKz2DvUF+yOJpBrqDcaDoSQUSCQjoYSa7A32q/BsVI11qxFoZSAe7gqHwolELJ5Qg/1dahDqHwr1
qhG9qki/mhzqD6sjkWQvFA9DaqyLlCZwNAhtQPkgdCaVlhwJ9ycjYcgdAmAoPlqlUpTEhsPxIAwv
GQ8Hk33wiBQIDcEQE6SxRKwbukm70D0UjQJI+wrN98WgkUh/11AiSYeaSI5Gw5mYIMRJkFbC8b5I
P80Rj22CaoPQ/9AQNNRPe9YVCfbEyPOR3giMsDccHQCMxNSeyHCYZqBUDqpRQIfaFwbc9UdCkD04
MBAGNPaHwtCIhu4IQZYa3gyD6QtHR1UYWwKIHCV19EWiFL1JnW8SenshKLEhrA4lwl0aNsODQ6Sz
QyGCf7U7BkOGGmFQyWSkv4cMPR4GuicTlYRMCUAZ5SO47Qv2BG+J9EPV4WSoUkMaFO+KJAaiwVHS
BCndHx5JDAQHoGuQpQu6mIwkSMUk+0A81hejtVWleLVJG9qKcM9QNBhvWg3lCNfWVs2tVctbI6F4
jNBoBs3VupJenlZXxoH2fcH4JjLiv8f5MJYeYMIw8BvlKci6qkNdFkyqperKVrW9u7uKdiwcTYRH
eiFbVVv7yiWLlsyft3JJe5vavki9bsn8hW0dC9V5i1csXNi6sG2lWTbLK3uBFClME7KQimFwMOok
pUK6PyB5sZ54cKB3lLZDmJ/gacOoOhobIiVDhEOhd0P9XZT7gCeAoShfA09EgJshe7AnHg4T7q1S
10Cx3iCwTmwDET0ombykMwRbI4QFw0DsMKFOPBxKAm90A+6n+0XIHusJ0yyULdLlgJzA8RuGklA1
dDMGUpgxoLJEqlPA/GlUpAsTDlWHg9Gh4AbgymACuCqzdJW6qp/y+WhqFDAmnTggEkE1MRAORboj
octHrgIW+ymHkrLBrq4IoTFwTpwqrkqSHKe4pRrhM52KRvoiZEDQCM03EotvSmiMTXmYJsZGgGeG
NkQjiV7SDtSlobsPmBv6D6QaGFU1htcxdGlDFB9LuqcHRzTe4FA4QZsBXRkKx/v1EcT1ftPMid7Y
ULQLeHU4Eh7RVNxlwyf5gJJh0Bpd02oxPUboFlXGoeQ0jcnAgnqvuz+/WtrldAFdV+gVQTvBZBPJ
sKpjnjpLLZ/rb5ihNsyeO6vGX1MjSauWQmLN7Nl+P5wb6hrUhjn1jfWNZrk3mRxoqq4eGRmp6ksR
PhTry5SJsLogHhwhuAARhE5BTStiG0BC20BnxUDBVxIhjUdCkaDaEaSykYAZa27t36i7ujfZF63u
S/YH+8LVfYmbg0RPVJHE/2aBkXAUUsP/uAi5q9bxSHODMRSjbjAxQPqpoQsuIDbDZL4R7j+kpkDq
eQc1FolJRIyWLvZr7AH2BfZFOI6yx9jvZNQVpIZB6v43tO7wJW2FL6mN1sflc7O5pdxi7ko4N0Lu
IHURu3RzpBfvx4+yiJp4ZBEmTs0zUgdC/wVBCUEjZW5kc3RyZWFtCmVuZG9iagoxNSAwIG9iago8
PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDM2NCA+PgpzdHJlYW0KeJxdkk1ugzAQhfec
wst0EWE7kLQSQgokkVj0R017AAKTFKkYZMiC29eeRxKpC0DfG8/MGzNhXuwK04wi/LBddaRRnBtT
Wxq6q61InOjSmEBpUTfVOBO/q7bsg9AlH6dhpLYw5y5IEiHCTxcdRjuJxbbuTvQUhO+2JtuYi1h8
50fHx2vf/1JLZhQySFNR09lVei37t7IlEXLasqhdvBmnpct5nPiaehKaWcFN1dU09GVFtjQXChIp
pUpFImO9SQMy9b+4kkg7nauf0vLxlT8utzL1pCRoB9owrSLQC2gNykDPoB1oCzqAciatQHumSDPF
B6Zs7Uj70t7s7Eqpm8nHUBFnyTV/XEUWYUHmEOFE7iHCgs5gCBZUDBFONCbXsB7hAvRsHbEIE6zi
26xsXUPc3oZkcQNxfyvGIrpHMB+j0RrmM3TIIlxAPl8AJvY/zi/YfSuqq7VuIXgLeRP8DjSG7ova
d73P8s8fOT6+12VuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgL0xlbmd0aDEgMTY3ODAgL0xlbmd0aCA2MjA3ID4+CnN0cmVhbQp4nO1aCXRc1Xn+370zkiyN
jGycICyDrjx4lyXjhdjCgGwtSF5lS3YkwyF6mnnSPBjNDLNItgqOgECMWOK4bElI6lBS9uSZkNah
lDotTQgJSUooUOrkGJISCoYGIhtsjTz97n1vRqPFbGly2nM84/+9//3335d73xyZNCIqoH7itMjX
rUdS/zL4e6LJLxG5mK8nLsrqZsaIzvwCkUadka7uX934rQeJph4kcie6gjs6vy2+jue5c6FldcDQ
/b/etvPvgT8BOC8AQv6/50EXDQLOCXTHt7/w9LU/gK7lRIV7g2GfTnToF0TTob/w3m59e8Q9NyeF
9WLwi5DebZxhPdkN/UH4ICJRI3LjtueOExW3gKeSpO/u1zrfrKPtnztt5REqySP52fcD4+/k/Scb
3iwY3HCsv/DpSdPwOImYkpChUK7/WL926eS8wQ3Dvyt82qFnPjwgKbg+Qnn0FcqHZBFV02aI1rsT
5CbmIuQMH9Zvg7aZ2lgFVfMbaAZ/mBbzp8D/NE3RnqNqQDnPpygvp6gWoia2jS7TAtTEi2i6qxjr
g5TPLVrDH6cW11Jq4ZdTFf8Z7mfTefwJ3J+hFsmvZG6javYEdN1GF7AHqdp9B7Wwc2AXuuSd3Q0c
2eUzYP8NOp9/Gs+DgCR8At19Ifx9GnwSdtFFyueX4UM7ud37oe+3gBtoVc5Rda/Orafq/PlUnZOH
53zASjpX0tOQs4imuQK4E22V97xQZm2SA7b867QK+HmSJ1t+AqgDkAOKJnVKHUr2KTpP0lxv2GuO
PsWf+zxiCw7dRXR8QAI7mhLu+pRg16Zud7Wkbica0m04fhPu10vQ3k8eIBpeR3SiX9I9/bDXb+t1
7YZuxM/vBf468EvpQpelclnt9oC2BzmsPf4O6xj+GWsd3qUdSP6etZ+YymbguWf4sHbr8ceJ3i+3
IXk17HgAh4G/gbsfsP/k9CHMWBK9f/ShbJy9myrhlJrP3kidzp4/kXRXp0rcTan57qrUNPfME0l2
T2oxb0nN5stT+e4HU7Pdt6bytSdTX+TzU7vYM8mXXceTL/NDqaqcpakqxPswdGPeh+DD0Qp6PIlZ
TDbg+QGi935EdGwy3ZC8m7Ynb6WmZCfW/hb0eyDXB3yRHdf/ho6hN0bD8cWj4b09o0HWLw1Hjo2G
oTtGw/vnjYahxdmgnZ2crNUmy7QNyfnaPcmv82knuPZo8kssJ3mEdg91a/XJmbDznnZ5sg11aWQt
wytZ+fDp2p7k6doA4tk9lKDjQzsyes5JTvtIetYNn8/OsfUgDxk9bPXwRlY7vEn7RfIgn3mikonh
heyrw/dpTyQL2KVDc7UTwwXaC8e72dvDQ+zQ8FvaoeR96TlTPTsyg2r+MnPzwfNWPdGsjZkxxYsZ
U7OetiF5x+ijtJ6TrCvgT6XQJ0M/B/wj4sf5IOc2+Sl+PBWVIHGbpuhk80haBhqyn11ByO1N7VTw
XGqPgo7U1zD729CDxXa/yd45uhV4ka1X0oZegPwjvAj816ZuYsdTO/F8Gg+ldkke28/kU6jZd3BH
3w7n8MOpyyRIHLT7HDhq80jaeHC1QqY/dbeC3bAlQYd/d6f+6uT+JW3fiiGzPXWN49v98PNu3PdO
6JsFO9ZH8U3m7yT+3QDfbnDy90f4d3K5iem8J7UH+20x9ni574Jn6EXAf0IXZib5SvruviF1Ihty
WulyCQWXUVH+c1TkPohzqwE69mMGsiF9Zt2F9XepuhBnpGcgqy93YxYkrFTnXLX7n0aD7GkJsLMM
dpYVTnfkGe2W4BqkyyS4o6AB8moxS7DlutYGd5XSK2eIxvns+JjxKcv+ZLzW5H2DivOTyM3I2Vj6
Uc7d3Mc+1rk7ijbq3H0J5+7AJ94TbJC1fV7idt3YzelzObkCPXDQrvd7eF88inPzyK/x2rjBvqfP
hPTen97n7f3cnUs4M1OzAAddJdTgejuVcr1Nd7q3UBvgTom7rsPzAfuZTabv8EdpqaLPoDtz5ipe
ta7kDmTktkBuvoPn5xynYtzzFFxHXvY9+g7kGwHXQN9q3BVA/2kOfo32bQmpJ7GucNi6RtLT64o/
oeRXQE7g+Srg02EzD/fJEgfMZngjcGFXZMvpe4hxJS+jL+O+RgL7Ma3K1ekM1+9oC94J23I7EMf1
5NVaaYME6FfAl9D17DD6oYAqlL0HaSdiWi31y5hYId0PfSZgIWytgy8am0b/gOeN7GHa4I7A/iDN
x9otyPlTbqL/kDSeSh2Rul0PURQ6pwOEk5tr+PupFNtKvaBdD7iCval035Izn+IOVILvErtm4wGx
kKyjqlUWIFebAZeyyanfAlLg0dI1nADWqLUscOoo++Iap4bjIGcPNWbXNQ2o5zuoZRj3xwDPZNfy
JHBVNsiaOj0znW/V9rpe07BXnpB755q8HsTWTy/xo/TLnNV0APAiZu9e7TEK8a30GuB9/Ea4GfvN
H9giupE30ADu9+L5btdTtArrD7ruoMcAjwKigAOAZwAvAL4FeEDyS1no/bGbaXK2fwX6I7mH6Xl+
gCypC/cXXHfRazgXkriv5qdpn8H9x+C9PXcaWZKeW5xKZnTBHxu0ObLPZU+yT5NfazjRh7ovydFp
lauQVrJWOojfR373Y4AoNeXU0GM5PwfgDTFrnx4L498fjqdqcM65XHPQf5dgP3X2dJzLVZImf5o5
v+qm4bctMG06IIcyP/U0xiTP6I/81Uf/Xz6f0FMXex3Xdvw+dJOgz9NeeoFS2rlas6Zr27Wd2h72
I/YyO8ifmLR5kuHhHo+nyDPXs8SzwlPrafCs92z1tHl8nrDn86JQFIlpYro4W8wUs8UiUSVqRVzc
Lx4umzlz6swzZ/00hd/ysLGXvkkvwsJmrR0WroaFHzoWNk3yezSP2zPZM9Uz37PMc4Gn3rPGs8XT
6mn3dHq2iwJYOF0UixlCKAsrJrRA2KUI3YaPthJQCCScei5VeOyfj3178NzBRYOVgxWDCwfxS2Nw
zuDswdLBnwCbevTfiH4z9TcL7bT85sxX47jmvPriq6FX3nnllleWHLrt4J3oiHbtbOicAbhcC+Lq
wEQf7LZp7DJ1bbevmh+/3SUWmKiM/AxezM9knXw6L+Ez+Fn8bF7KBS/jM7mXn8Nn8dl8Dp/L5/H5
fAEv5wt5Ba/ki/i5fDFfwpfyZayLBZjJLmdXsCDrZiEWZhF2JYuyGIuzBOthvWw728H62F+wq9jV
bCf7POvn5/HP8OV8Ba9i17Br2XXsC+x6dgP7ItvFbmQD7CZ2M7uF3cq+xHazL7M97C/Zbex2dge7
k93FvsK+yr7Gz+cr+QX8QnY3/K9nb7LD7C32Nvtv9nv2DnuX/YENsiPsKHuPvc+OseNsiCXZMDvB
Upy4xhnn3MXdPIfn8jw+idfyfF7APbyQT+an8SI+hd3HHmXfYha7n32X/TVv4Ouok7ooQCZdTldQ
kHpwojSzFgyxnxnsAfYg+wZ7iD3M9rJvsnvYI+xv2D6i6qpNTRs3rF+3dk1jw8X1dbU1q1dVX3Th
BSvPr1qx/DPnLausWFg+d/asc7wzS4unTSk6rbAgf1Jebo7bxZlG5XXe+nZhzW63XLO9DQ0L5bNX
B0HPIrRbAqT60TyWaFdsYjRnNTg7x3BW25zVGU6tSKyklQvLRZ1XWM/WesV+bdumVuC31HrbhPWW
wtcr3DVbPRTioawMEqKuOFArLK1d1Fn1PYGBuvZa6NtXkF/jrTHyF5bTvvwCoAXArLneyD5t7oWa
Qtjcuqp9jPIKpVmLz6rT/VbTpta62pKysjZFoxqly8qpsXKVLmFKn+kmsa/8wMDN+4uoo32Bx+/1
65e2WlyH0ACvGxj4ojVlgTXPW2vN6/ttMUI2rHJvbZ21wAtlazdnDGiWe1aRVwwcITjvfevwaIru
UHJmFR0hicoQM2nCehon+AYPEV9ZmfTlpv3V1IEHq39Tq/0sqKPkUaquXNBmsXa5ciC98qktcqU/
vZIRb/eWyVLVtTv/egLFVn+HWFiO7Kt/s/AP68Lis9s7fAF5140Bb22tnbeWVqu6Fki17sRat29R
Jfj1dgRhyjRsarUqvRFrmne1zQCCkDUwm1uViCNmTauxqN3nSFmVdbXSL1E30F5rOyh1eTe1fp+W
pA7tWypKvruEllKb9MP6dA2KMrtuoNXfaZW2l/jRn52itaTMqm5D+tq8rUabrJK3yJp3CObKlEUl
hdjGcKeZZeS5s/JEKyvhbbJaIIh6XLyrV2KhCOVSj7Kiq1eKVq2E0myw4nBIbJQePPBZNQ1yiUvR
moaSsrYy+/MBLpU4PrlnWXlZuopAyPhk2zmpaza3dGieqDNqsxwcpdTtOOhom9hPJnPhGIZEnixn
Q3qJz8LkgsagRpFkFYuFRU2i1Wt427zooeqmVhmbzLWq79pm79pN21pVtZ0uaRn1ZK8vz6w5WPor
BvK8a5sHJI/XWSIx0GgRmq8aY7Z86lKbWo99amCg3ivqB9oH9P2p/g6vKPIO7Fu7diBS1y6dbEXC
96cev6nEqr+5zSpqD2hVUr+30T/gbW5diTTIw7Q6Nsk1rfQ0lygtdBWX5rrKSq8MnFF69VVlpWag
rHTvTm3vVdregJbjnl3qds0uncxOL+WsrLSSaZFwWamnAGhYqyzQptC00t6estIzipeUVm7XKqdr
lWdqlT1aZbEmyYa/rFQjMPvlnwKwha1+9Iwp2i5hzdw04N1uVW/evi9f7MLutGX7PqattviMsjLN
mrqW1rastk7XcG9ebbGaVlprrdy81prUdEnrPk27ta1k7X5tdzYBu8Ku/Rq1WK5d+xluU2u2XdK6
XztTLl5f8n3SNLLWtl9/S5vVdJblX9vcavWf1WYtlsjus9ooFluwYEFMftQdsMAmLLA/xF/n7+K3
62G8J+2lp+l+ugqwXVGuTVmgBFw/dO88MUCBY/3kxwl7iC898So1aYc+2Qvgn+rjbnA3weuX8LZ3
D32BXkcMFqUU5Ub619xXcSX+S/7miQT5XZ8Dx/30dbqfveyIrz4Fp+AUnIJTcApOwSk4BafgFJyC
U/B/AJj8/268n79OnHJpenWBm09yUa5GLixd9OxFz2qVzxb9+tlzFy2ZUjZlVtmUsn5Ow/2MTuDn
bbK4X/3NgWiGtjXzB5jFRJn/j5eLJxtnwFc4OKeZVO3griweNxVSh4PnZNHz6FMUdvBJtBC/MG08
n+6kfQ5eQKVag4N7qFbrcvDCnNO1hxx8Mi3KfVL+1cg1CU/+3LcdXKPJeZsdnAFvd3BOtXkhB3dl
8bhpet6jDp6TRc+j+Xk/dfBJtC3vqIPnaxWTmhy8gC7M3+ngHtqV/4SDF3pmF9Q6+GRqP+PyB8Ti
RYuWi/WmLxqOhTvjoiYcjYSjetwMhyrEqmBQRM2uQDwmokbMiPYY/oqL9URc7zY3G12JoB5dHw6F
4zsihmjs1rvMUJdYKBwG4XBsNaIxKBPLKlYs0sexN4Z8FZv1rkAipMcDYk04FjDF3BbJUWtGDV88
HJ1XLjZ2X6FHRXPACPmNtHYzJvSQ2BgxQoq7MxyK4xIV8QCUh/ymT8R8UTMSX9hiBBNdiQrRGJcy
HXrM8Au4syVk+sJ+o1z4IKmboZhoiSYMpSuciAfNkCEN+EVAh5BhhITfiJldIQhLK4mYIbCgiy2N
ynRFIB6PVFVW9vb2VnQ7MZp2iBW+cHflhyw3RcP+hC8ea0aKTZ8Rq5R+1NoGo82BcK8Pbm/Y2NJY
31izqqVx4waxsV6sa6yp29BcJ1ZdvLmubn3dhhaRn98SQIxSe6fuM2S8Mh2RaDhiROM7RLhTTFgA
FaiJIsuwOnaIHeGElPWFe4woAk4g7XZi40a0OybV6CIIP0MyC11Rw+g2kALRBrGA3oMEdsiMQjI+
yh3ZX7161BCGCWVR4VcVDu4QndFw93jPZDHDXYZi7YXEiLzfjMWjZkciDhNwNxwypE/SQeWVzzBi
E8VakU5QRpFsItGjBxN6R1AWNGbEJxbcEgoasZhKjIoQ8arUmKF4GCpiEcNndqLnxmVFdEX1UFyG
I2V1v9+Uk6Wnx6pcku12UhGMcS5odpsySBhRLCGRiMiHThM+zF02T/SGo1fE4mpaVV8qbeHekIgk
OoImhgmGIWnXplvfIRAY6hrZIbM7ksbRlmWeGjtHgtVDO8SVCSMmrciuQIKjISekaHp/kNyxQDgR
9GOr6DGN3pF6jMqH5EPZDUTgt8sq+TJBwy01kL74+IaQAeqO950Tq5euX2xgaJBhMwSBbpWbqnw5
eXJQY3Le8vProSotbDe1HIFETO8yMpWJBA1MnegxYya6ApH2Gh0COMzFbYUTT3p3sFISKx39FZKS
n7/O7DNCfR2GH4yJUBc2FIyV2JCI9+EphowEoLjTxKiFRLMJG4lOcGDPRfd/1uiIYWaMj2+1Sfod
CSZiwj8nKx+ZKqI3BTpb+KNhOf/+OYm4ib6xG8qw10aVPh5FaRJGEAvlosdImMD65EIsEYwDg2uo
YuyTOatHdbl3yPqlq+cz7wwJbB5Rn44dWATD2E9ujXabISD+9LybutihlrBPIZH2UiIWLreLZ4iQ
DCEaln6ZYQyvMIIyqcA+gZdwDpsFQvabfUiL6aQlHk/oQVPITUHubGY8bsp8ZrzQ4YcZRILSnoRV
Q+nBICojBfr6wh/Xmw89dSCU5tdjke30AAm87yzCdzmw9WSSj6J464kBOikOWg2wKEXUVQfFBBai
CqysoiC+AnRT/TU9Din5ZOBu4N6Dqx+cF0MugVWdusG5GdQuPAfxHIVFqS2M1R2wYUC+EVw6OEzQ
u/C8EDBagxijY6uyFnM8E7QMNlcgIv0jaG/E3Qf+zYoagM6QijKAtTUqDwFlcS61ZHTUgiKj9IFP
ZmUelYO6EZqvUP4IaoaUAU1+XMf6bqos6crTjUpjKEt3p/I47mBSV1zpsj31q/oIaPCprEewuhDS
BjKRUBmpUJzxjJ0OWIqpOggnO1twlVrCyjvpuc+xqausSKkWaE9gdcSvsIohqDiMTARSa0BZkJYM
FYtQemOqJ0KO5XQsCeWLcCR05U1jVtQVqovisFlFlfj2qm8FMje6juaoKlaoCLrB/8dJN6nO98NL
n+rlZqeLZbZkRJWZfNSOijCq6h2GLZ+T7Q2obAsiqwfUYE4kvhFUWfF6XNcpeh0ozbjKSboYHViH
73pFbQEtH98W1X0x1QW25U5Y8Kkcpul2d0SU7xHljeQVan7Fx5iAkYqaziSnq9Wh9O1QPZC2K3PW
o6zZFU443Z7dsXH13K34bW9kxYNOPkOZXuhSWgxwGk4XCGpzrMnu6nE6sCPTo7bN+AdkJ71/9aqJ
lBRDxRVwfPRnzXBQxdepMtj9kXKWnswwnowsrb2OjYns+5WvcTW3HWqa7Cg6nGqFnCg7szI4kiuf
ytBIJj/Mx4pxHTTeIzMzhT24yh1EhzfBzITGVGwfx6LcW4LKz1hWx4zU0K7vSNeY6jnseBFTen2g
djr73If3ilAUXeHp6qTt6rDhVxWxTwZ93GlVnuHO3p1GavDBmQuqncTMVNKOZERLSD1FMisyKjsP
c3FGzVP9IjvpCtUXI2fryH454pvcXUJqzhOqRqZzMtkR2zaz50ZWRvaVXTF7XiNOp6X7f2w3flDM
6X5qVLkZX1lZAan9SnVuxDKxpPcKu4Oj6uzJrlKUxr4/pHXH1J4qz3g/2W8Vcic24NFE83Hy/kjr
s6fdcGrgHzWtaX3jK21na+SE9CmdH75DpCuoj8n9xNP9QTuhzPrF6tlQnR505sa20J3VN1XgTJ95
6RM1ljnfpJ56x6uxlrN36vQpIHtKV/vb+JmJqCnXHeke1TOms1cknJ3QQF8Jh25HFx/l4cc507th
rzLDWTnG/4oMj4xxHdb61FqfeifxOxoT6mo4U2nHuEF1fp+zFnN6JOB43Kkk/Y5Ms+o+od7mOh0d
MWcvkxF/VkUcc84Z488Sa1Mm3xG1f8fUZM85SX+Mn0XdmZGgc7b41RmYPv+lpoSStveb7B3KGCV3
8qmPq56VUyM5go5EueoaAzTTofVlJGJq5uMOzc5a1JnOP2dmdeV5+r0jPX9jZ0+eVn9QGdGdrPqU
lN+Z8LDzfvJfit9Uvsay1kfOd1PJ7ciS8jvd5VM74YhUQu1T5aMmz1C5Slchqs6bWObsE04PG2r3
+Kwzm8aYPeNPl0vD2XWMTJX9akrtbjHHdEtcdYuudIrMm0L6nc1U62amP8fnQnfyYapo7YyPzkk4
a4fSVQfOcWbdttCHb/hPnps//reObWmsfl29SW3/H5CewWdlbmRzdHJlYW0KZW5kb2JqCjE3IDAg
b2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjI0ID4+CnN0cmVhbQp4nF2QQU/E
IBCF7/yKOe4eNtCa6KVpouulh1Vj9QdQmFYSO5ApPfTfC9jUxAMkj/e+yWPktXvuyEWQb+xNjxFG
R5Zx8SsbhAEnR6KqwToTd1VuM+sgZIL7bYk4dzR60TQA8j25S+QNTo/WD3gW8pUtsqMJTp/XPul+
DeEbZ6QISrQtWBzTpJsOL3pGkAW7dDb5Lm6XxPwlPraAUBdd/bYx3uIStEHWNKFolFJVC426u39o
BZL95+/UMJovzUe6VuqppPf3zOX/HaXMypz6lCWUIrmCIzz2FHzIVD4/I0BvAmVuZHN0cmVhbQpl
bmRvYmoKMTggMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aDEgMzAwNjggL0xl
bmd0aCAxNDc0MSA+PgpzdHJlYW0KeJztvXlcVEfWN36q6vbG0t2s3YDYFxoQZRUQRIm0CkZD3JeA
kUgDDbSySTciJi5ZNWgSjZN9M9GYPcEtolk0GbPvmSSTjMaYidljYjLZFfp3qu7tBjSZmed9n8/v
j/djd86tU1Wntm+dc+rUBQkQAAiG1cAgu6bJ2fqJdeFtAOZUpH/WLPXKY39IeAUg/UUAzbS61vqm
uJ5zWwASQjA/rr6xs86TcmwVwHjMR3/b4HLWHqy9XsYen0TKb8CCEJM+H/kfkZIamrzLQoq1owEI
kvFEY0uNE6bt+xYgx4r5H5ucy1q1K/V6rMc8yM3OJtcDE4alAFxwCiC+vbXN1Xr7La6bAVLOB9Be
DHzu9K1v/nn3XY8vNBX9pI/BpvjZ0vbsfp7uPmfH4ZMf9tbr79PnAgUDyhMhgE/duL5pMFF/AOvL
9PdBAuhgwIc9yWXYk/gohvmgwdZmyILxONxwHJcB1apd0cIAeejfSbDkgYVIbl08vKCZB3eTNUSi
D8Ij9EHfJhYP30gPQw/KjsSyhZgupYW+m1F+o+QhWZguQ2pFqkS6FukhpF+RbkHqQvl23pb3ESAP
kfQ2aNHM8/0dx6vQvAD7kC5EfoH0CVRqC3EeL8A83lYCKMHyC7GvWdoHYT6W12L9E1hWjulTmK9C
fgO28yH/PPJ9umsIYN/7kf8Oy3Own1CkR3Hea9kzKOvxraQPkhHY53ykEhzDg2kj0iKU4+sYxcvJ
C3AOecGnx/pJyOfj+BOFvAdqsY+vOWaICW8/jWOJ+dXI34PzuEsCXy/ygJRKH4bFNBKepA/75uD6
tyrrRnoBnuRrDqwJ56/O6UxS5rhoIOGYKwZS/9zOoNWn0T6WS8IwvRXJgTSOvgZN0vm4f5/AeZpP
YTYnPeo04jQf13hcqoVL9OB7BOf5qGYXtsN8gDxQJt0OIexHGI11y7U3wvdYDnQk0s9wH/0GrtMm
wxOoXxdg/7cgPYx9LhW6UAtzsH2m6OdTiEX+biQ+doofJ44NWslW3TVwKeJ+ilsMtn8f6T3yAtEj
AbZfjeMv45jzfSfzer/AfmaijBMpActbBHkgGLHai/v6Per3+9jXWlUPF/SnsEDV2wDxOfhJ6JlK
AvsH4TWkA0gvIR1CzK5Fmoz8VKRuJJQhehzbinqUIvQVdQZxSBH6gbrB9Z/vldBZZQ3lQseEzRAN
trdgPzcjPaB9GC5GegjpAZT5gtsL11k+T3/f3Ka4zvhTod+LYTd9kEbwdXKdCqTc9gBaAzaIuuVP
ud1x3ecpdcBoTOexXCjkOsv1zZ9yXMT80R65TQTS/rX6cH5Okb4LTaqur/an3E45FoF0A1wg8N4B
u5Cvk9qgml0BpdLfoJb2QbdmNO7lYt9Kvjb6NXToDwD3pNMxf8tp6c2cdO+SRZoD8K3A8124A9Ml
0rs0UXqXaDQP+b7UAHlJ8xBdKfgz0tOJHFDqeMppYN3/tPz/hOh7moegDvmvNO/6fLie67lN6L4m
2UiyP8XyHUirkUbo08jN+sWkRzcXzFo827TcFhwwRuOAAukAFEtR6AcAkrF8ruYItLNrYKz0NbjI
ajwL3iXBuig8A26EGD4WfQ8u58T7x7R1gB4N0rnTdcmf+vX19JT7fFWnRKra3oo/SAtRJwk/G7h/
FucD+mhBQl99zQH9fAmqMZ3i18/Beup7YYB+foP9Wk/Xy9NTcbagf/fbKbcN//q5f+Q+jvtI7udo
IUn1y5+e9rcnuWgntwg//BrMV237L0ibkGqwLgXneRTt/2Luy3Csd7TToUb7HDSwIVCtnY/jfQNV
2lyIw3V/GzhTL/J9o56nOf6zlOOE9d/4z1FNNuiFP3sVLhD+5lXIEOcozo2fn9p7oVcbDTq17Xfc
DoUNLoFSfjZKdXCjdL3vS1zHnWw34o3l0gVwmagDKGInfK9J1b4v+JnINgkfVCvd4DvGjqHu8bYX
+Zo0b8Pt2rFQG+iPy2DKy/j8tU/D5xKuUfOAOPM3+P0x33v9Gt9XusO4/mfgU2kPysTD55qX+VoQ
g1FiTRWi7T2+Vbwv3TzfHulLqNHsxTIk0eYS39cqHvMGYiF0mGOBfWoXiDN7v+YtrKuBQ7pKuEBX
jeMugc91FizjY12D+5+Jqdf3sjivV+P5lgG17AfUrUahi4s0l/qeYz1g85/D7AW0u8t972suwbQe
ia9dpOj30X5EvIE6on0M4zMeT2zCMz4JbtJuhU7tG9Ap/Qqdmk9QfhQUs+/QjiTkJ/m+UP12KdNi
+S/oc1G/lVhGiWd0k33va+8S45WKOfA4xQMr2Am4gO6BYvQlM/UPoq4sEOf0OtS/j5C+VQieRSpW
aYpCNATr3kIdXY75u5iZnIP8jTQXXqcPStFYZuJnrnQpuKV5kMNGoh8Jw5jiLbiH/Aa3MRP4pJfh
NqkH/k5+w3MyAn5i3TCb7YJTovwNaEG5Evo2FEk3o/8uQgzXwhfSQljFtsNJ9g6uoQ59PbbTXAvf
apIgA3G/jf1A9JzIJ/AVmwdfaa+C2/h4XA7pSey/mpM0GTJEuwEk5uqn0+ZMy2AZOw+uxPl+hvwt
g+aLcw3Mcy18Jub4B/MT8+D9YjsuI90GlwP4DiMlK2nfzAFp9H9BhwekMk9xT7fyc0G7En3ee+j7
KjBmCcd7E/Th3aYXbwa9e1CuHNNvsGws8plIeM/pM2DZUkx3YmpEqsNylPEdxLISKQ5tRfFTF2PZ
IqzvwfKXMcU7ly8D0xcATh1HMirUG4npRqRLkK5HmoQESnryQ2U+vhmYrsQy7O/UDdjmF8znIn8L
0m9I3yHdhbQO2xzB+nSkMswvQ2rgun1GXPO/nv7xefbfptxv8XliOhrt8IvTz6T/OvXv539ITz+7
/Pv/n9IBMehpqYKDfx0DztJ/e2b6U+wieyChbx6HPqqI+2XuG7k/Fv5ITUUcoPjFr/gZguka9IM/
cl/M/SH64ufRH16KaTumPAZ9BmWW+ufFL8UqDVGuvrpTmEPOQEHSHQXlcs1v0SvJKnIduZ7cTbrJ
YeKjFfQF+hL9kBHGmIHZ2UrWxdazu9nrUog0XVogLZQ2STdJd0hbpJ3SE9IH0peavZq/ar7S/Dj0
yqG/ySY5Sh4qJ8opcqacLefKY+QieZxcIrfIq+St8n3ywwmahIiE6ITEhJSEzIQ5CRcl3JBwfyJN
1CaaEsMToxJjE22JwxPTEicnOhNddmo32xOSIZkmhySbkyOTrclDkpOS05PzkouSG5NXJ1+RvDZ5
ffKm5LuTH07ekbwv+cnkg8mvJL+R/EHyZylFKY6UCSlVKTUpdSmLv9CcoCdGnqQn5ZP5J4tOjjs5
/mTJyem+Uz4ff3MBmwUCm8lj5DXyOyLwPCLwPoMAAlcgAteyLRKRjNJM6SJpg3SjdKt0j/So1CO9
L32h6dY8oXlTc2Lo6qGb5RA5QrbIMiIwAhHIkQtVBBYhAlsQgQcHITA74cKEDQEEwhCBmMShKgJV
ibUCAflPEJgRQGBD8ubkBwMIvIwIvI8IjAkg4EpZ9AU5QU5IJwkiMOLkaETAcXLiyUkcAd8n/D2J
L5JcRGaSv/oOkyr0PibEJQWCER/tqc2Yd3Md6kvrG9E3vC8VPZbZZ/QF+aDvVN/RvrdPfXjq8Kk3
T73ySSXAPw8r72SOXol0w8cXHr3i6G8f33+0A3PocY9uQOo6uuLj9o8WfdR5dN/HB45e+9H9H914
5MYj9xxB73ZkG2/7keXIkiMLMZd9xHEk90jS4UmHSw8XHS48nH8493D24eGHEw/HHY48TA59e+jr
Q18c+vTQP3mrQ88f2n/o6UM4yqHnDt176LFDpYcmHBp/KOlQ4qGEQ0NjD5ifRjt+WrdNd4fudt1t
ult1t+huZso7pj4Y9KGPKjQo30OPBN43pcOffFgs0svsdYYosCODav6B9E+F/rT1q5zY62ru5T+X
PKPlPWxrgN/8p1Jdf1wMW+AKuJKeghvhM7gKroV1cAc8AFvBDF0Iz+WwCU7A93AN3ARr4Vk4DN/B
nfAg/At+gB/hHngYXoTn4RGohhrYgL7nZXDBC/ASvA6vwKvwGnwOdfAWvAFvwqNQD9/CRngH3oa/
QQN8CV/D1bAI3LAYmqARmmEztMASaIU28EA7eGEpdMAXsAyWQyeeuCvgEtgDd8MqWIk+9VL4Cr6B
veRGchOhhBGJaOAknCI3k1vIreQ26IU+oiU6gpcTcju5g9xJ7kIbv5sYSBAJJiHkHrIFfoZfyFZy
L9lG7iP3kwfIg+Qh8jB5hDyKvqCbbCc7yE74Fd4lXWQd2UV2k8fJHtJDQomR7CX7iImYSRgJh6Pw
MYkgkeQJ8iSJItFkPXmKPE32kwPkGfIssRArPAbdJIbEkr+SgySODCHxZCh5jjwPv8Hv8E/4hNiI
TBJIIt6JXiQvkZfJK+RV9EWvEztJIskkhbxB3iRvkbfJ38g7sI8MI6lkOBkBx+BT8i68Bx/BB/AP
OARH4O/wIfkOTf179OU/kH+RH8nP5BfyK8aWv5M0cpKcIr2kj6SjnwdKKKWMSlRDtVRH9dRAg0gG
DcaINpQaqYmaaRgNpxE0kmTSKBpNskg2tVArjaGxNI4OofF0KLVRma6nCTSRjCQ51I43uiSaTFPo
MJpKh9MRNI2upVezrexeNpoVsjFsLCti57BxrJg52Hg2gU1kJayUTWLnsslsCjuPlbHz2VQ2jU1n
M9hMNovNZnPYXDaPXcDKWQWbzy5kC1glu4gtZFXMyapZDatlLlbH6lkDc7NFbDFrZE2smbWwVraE
tTEP87J2tpR1sGWsky1nF7NL2Ar06KvYanYpu4xdjr79SnYVW8PWsqvJJ+QYnnbr0Ntfg/7+OtiO
t/wukge74XH4K/kUdsIuOAiXwTOwhn5Dj9MT9Fv6Hf0X/ZH+RH+m39Mf4CfyOT3AwuFJuAWOo63c
C9eTYriOjCdLyUY8YzaRDughl5Dj5FumYVoWxXT0F/or/Y3+Tk8yK543wSyGBbFYFsri2BAWz4Yy
G5NZCEtlCSwRT6MklsxGsEyWxbLZSJbD0lg6y2BhLJflsVEsnxXg2a4F9X03phQf9DSL52/LJY1W
pzcEBYeEGk3msPCIyKhoizUmNm5I/FCbnJBoT0pOGZY6fERaekZmVvbInNy8UfkFowvHjC06Z1yx
Y/yEiSWlk86dPOW8svOnTps+Y+as2XPmzrugvGL+hQsqL1pY5YTqmlpXXX2De9HixqbmltYlbR5v
+9KOZZ3LL75kxcpVqy+97PIrrrxqzdqru9atv+ba6zZsvH7TX2648aabb7n1ttvvuPOuzXffs2Xr
vdvuu/+BBx9iDz/y6GPd23fs3LX78T09e/c98eRTT+8/8Myzfz343PMvvPjSy6+8+trrb7wJb739
t3fefe/v73/wj0OHPzzy0dko52yUczbKORvl9BefjXLORjlno5z/d6Ich8NRPO6corFjCkcXjMrL
zRmZnZWZkZ42YnjqsJTkJHtigmwbGj8kLjbGaomOiowIDzObjKEhwUEGvU6rkRglkF5qn1Qld6dU
dUsp9smTM3je7sQC54CCqm4ZiyYNlumWq4SYPFjSgZJ1p0k6FElHQJKY5SIoykiXS+1y92sldrmH
zJ9Zjvw1JfYKufu44KcKXkoRmVDMJCRgC7nU2lAid5MqubR70tKGrtKqEuxve3DQRPtEV1BGOmwP
CkY2GLlui711O7GMI4KhltIx2ynoQ3FW3bH2ktLuGHsJn0I3Sy511nbPmFleWhKXkFCRkd5NJtbY
q7vBPqHblCZEYKIYpls7sVsnhpHdfDmwTt6efqBrfY8ZqqvSQmrttc4F5d3MWcHHCEvDcUu6LcuP
Wfuz2Hn4xPI1A2vjWFep1S3zbFfXGrl788zygbUJ/FlRgX1gW5o8qaprEg69nqNozcKJ8OnzpSiL
ctlLeUnVIrnbYJ9gb+haVIUbEtvVDbM6E3bExjr2+o5CbKncNafcntBdHGevcJYM2R4JXbM6d8Y4
5JjBNRnp281hCprbjSaVCQkdyLgCdYIT4pwrmxWAk/AZ2aegGnTLNTLOpNyOCxnNH67R0FUzGsXw
U0GwVXctboO72zCxqss8hpfz9t2aZAyOun5C11plP/7N4BKnWqJNNv8EnOXKEVAwrPfz3Wlp3SNG
cL3QTcSNxDmOE/lRGelLe2i+vdUsY4LwwYxybFYxJgsxT0jgu7quxwHVmOlePbNcyctQHbcDHFlp
Fd20itcc8NdEzeU1q/01geZVdlTfXSIKierWpwT+M5mjI0obxnST6H9T7VLqy2bby2bOL5dLu6pU
bMvmDMop9aMDdSrXHTGxnMVRlaNxTNSiJi4ICPNMeUi3lIz/aYUm1/bo9KiKooTIk7rNVZOVZ0VQ
QsJ/2ajHd4K3Ekl/M3Wa3WPSBufHDsoPml5IF8MJSym0bM78rq6gQXWT0O90dU2yy5O6qrqcPb7V
1XbZbO/aS++l93a1llb5d7THt29dXPek9RW4iAYyJgNgfDisotvgMaT9SN8hSZCNz+lIC5EYOOi2
HdflOnowWSiSndNm5qzm6flTc0TeMVlJg0KV1DBGSbNzudzWnaXLeH7rzpwxSn7ESCWflJyzaryZ
bsU9/048TfjMQipGWoUk4eBbd0bFK80MkbzZlp2xcTmm/XQLSmzBdlvEFLc4grA6fLp2uo5+N76A
fI293SWeq8RzoXgWi2eWeJrU2q/46OK5XzwfE88s8SwWz+ni2SKeQh6PtOPkG/x+jd+vyFeOcEgn
YCNmdOs24kgnDhvGTAYSvCPPtrGHBDsK8myZ8kRbDlKufK4tHVMb0sUjJtsykBJGlNgKMDwnYMCb
uh4sFrSB8DC9o4c8vKdvTWjvmlAw9JDiHSPOt403kDGwT+LD5SPdiiTtGNFmexpbyyKLtzz60A7b
yYweMm+H7Xdbj57ssP1m66HEEWH71XbM9ovtCdtPtvNsL414yLYXpW7dYeux9UgotXlED33IYbKt
s83CyR2zLbM12pplUdWYgIkj2FaDjeaPmG8rR1eBo0yTxSjn2rCbx22lWFkyooeQx20O29W23AzR
NIc3fdw20tZmy7SJ4dKV4YYrc0vlyeO2YThYohil1DY31BBqKNhwWLfhft2GbboNK3Ubxus2jNVt
yNdtGKXbkK3bkKXbkKbbkKzbEK+L1IfrzXqjPkQfpNfrtXpJT/Wgj+zxHXWk8dt/pNbME63En5Lg
zZQ/+RsRhIsSPYXzoDuCldGy2RNIWfeBGiirlrt/nm3vIUFohxr7BNIdXgZlcyZYu0enlfXofLO6
C9LKunUzLizfTsi1FVjaTdf2EJhT3kNieNGVcfyc24u7GnPlNXE89V15TUUFRC8tthaHjwsrnFTy
B48q9ZnW/7GmDfqUzejci7tcvlNnO0eH2dmY3cCzG3jWGt99Y9ns8u4H4yu6czjji68o6940W15Q
vhcj/YdLS/ZiyI9JRflelk4eLZ3Fy1l6SUVFGW6NkEO1f5TLPcoTlNO/B8VcDor17wk5iShydiGH
aqfIRctgF3L2aHmQ3FDyCJcbwROUsxyFoUJuqOXoALnt++ylJdvtdn9f+4TMPqWv7iIhYrOhSIJN
iKCp2ISIjVAhMqlfJEMVyQyIZIqRGOmXsSkyobJfJpSPlPZffVwT0tJK3VxXZpRv18OECjwFRBpt
bh0n9j00Zty9cfvgbfY1BONBGISRVLB9AhQXW9PMRSRLG9KtxSIdEpcem2BdGbdPAnK/kA7B4lC1
KmN8xnhehdrLq4w8JFOrrCvHJsTtI/erVWYsDsMxBszT623HD1hL3SWB/zzqp11NvVDWPWJ2WXcx
HkDbdbpSjFJKKrAs218WHFza4zugFGZiYREvZCwgGCgzGFRBROPx6elkuo0U4BQq0jw4FRxoIIJe
D2j2QYygbRArpYAVwPc50hc87XP7vuV1fS2+f1L+HmG3SsrnSdgP6/GOsg2/28FMJLyLd+Jdfh3e
V76CLrypbyS78F69HG/298AT5CnaCvPxHm3B+/ZfIZsw35t4l19BQkEL4Xh/fw3mwUbfdSQCgiEG
JuKdfC97kf3d9y2ZRJrRT8RBCcyCx9m38D6R6Dkaq8bjywANGOB5eI2ej/MOgygogCkwDRbgnO7D
uT4Hh0iqZqLvI0gAB8zGkTvhWtgCL5PrqIu2063sRc1c360+HAV70kMKTAI3SnmgA27FdXyHd/cI
vFV/yqzS7X0/9P3m4+89hkEejIdSaMfVHIRX8Db8KfxK5pI6vH/OYa2SRqr3Rft24ZzjIQe92nkw
FeZCFVwCqxCxO2A73cLW9x3s+wU9H8NvBs66AMbg+ucjVq/BP/CWH4P38GFkMplN3GQzOYk35kJ6
Kd1Kf8F7XCp+89kWtpt9yD5i30uTpWXSZ9pgX6qvzNfgW+a7y7ff9zFiaoNUOB/7XAAXgRNX1QGX
wuWwFnfrdvzeAXfhffFx6AG0cPgb3uo/hh/gF2IkOWQsKSJ1pJEsQwe0m+whb5C3aSV10nvoa3gn
nI9jb0VrKJFmSB7p7T7oG923vm973+s+o2+H7wXfN75eRNOGmCcjohlQDi4c+UrYiLfUe+Eh/nYC
v/vgEByGLxE5A37NJJJYSBIZTjLw5p9PZpCZZD6pJ17SSS4j15IN5BZyO+kmO3E2T5PnyD8If8X4
AyKDMNNgaqI2mkjTaQbNpNNoPV1DN9CH6W76JH7fpO/Q9+kh+inemX/Du2skfhNZCpvMzsP7fYu4
q69kDyGer7CjkoT7Z5JSpXTpCule6THpDelr6TdNsOZazSbNzZpPNZ9qQWvWnqOdoW3Q3qDt0X6g
Y7qZujrdSt0q3WW6x/HYs+sfhh1oHdtxpQM+dAHcDX8jT8MRso1F0ofIDHofuZEYmRUWs9vIW5oy
uJoW0W4ylUazf+ENfilEsQfIj/AjPE4l+j5Jk+4jm+FJtKT1dDFdJpnIBdIDUi/xSm/jNfoYbKPf
8nG0kdJ9ONpSPFibyDjk6qEJ7qSR8AqGc1fCEngW7tQa6Abc9+sghU6GUWQK3xv6HXyN1hFGimER
2kkv2aLx0rvJcvYFDYF5pJd+RMZqvFCHR/mlZCedxl4hx9DynkR9KSMNtJBUQy98Ru4hn9G5MJVe
Dlukes075EOSRqZpGlD/QDrKprA6GkGfOOOt4GOwCy3hNTifvQgLyPVo/a/RNJhCW+AO9hT5EnaR
S6R61oCzXEYlcjnawsOwk02WgmEC7GK74GlyP3uPpMFj0jLSTDb5Snsr4SftNulRtl2TLw3xvdx3
mNxL3vTto99Dge9lNrevntwuxaBdXoLW24YIBcND2P529BjbQI9cMtrjtaivUejbDGjlk9BznQ8X
kR/QYi5HlPJJKkyjibCYjtfJ2kgA3bDAarz/l9T9/xah7in0O+pAEIBmDGrpZAD+m2GGBoCgg/0U
fESh0CFIpwBMtQD8XXoY6nZEHUDkJLyb3tpP0d+epbN0ls7SWTpLZ+ksnaWzdJbO0ln6/4ko/3mh
Br94g9fBedspeYJkghZ0tGAHaKQekrmLQZCOM7sJxOi1Gl5PgZGJOw0XPm1NM/9c1Fs0zfxj0dTe
IihG3nwKHyOzE8ISwpLxQUCCUzI7cMrBf+VGlg6A+HFSD32ENuGYssNMLgb6GLtVQx6DGGnpBGsa
9jb1mPnnY5B1fGR2REGCbmEKTU0mPbt389/CnO/7QsqXxsEwGAXPOGZemEGSg5KD7SHJ6WPIeUSb
pS/UX5BQnyDlpY8IlrJSU0KZCZKH2lPTWERoUE5salpaelBoZFBQaHSSzUIssyJssbqUoBwbC7aU
m6JJdA/5q2NolqxNyTfJQ6HcbG+1U7tvqCMsPA+Gmoe2DGVDn6TLoABS8Mkn+1ll2tSfK4+bj/N5
9yIHxceLi4/3Vh5bY8xMM64wH4Sw8MJCTgQfYeGWQvxvZDaphMrKZK3WnpgyKi8/vyA/qSB/VN6w
FHuiVjcsPz83h//KhY5poyIt9pQIrVZnpFGR0bk5+fnMfNGjNZt2zbzKeQ6Ze15UZnFn28aEPaP/
tfc5T3nM2CHRe0znpFxQd+dlE9zO+duqrphZ9siaiqtnh4cY488bWZyU46o033n/RZNa57b2/bpy
es5FeeQzk9lgTLuo8PzqhQ/y/fEgxtGIcRysdwQVMndkfdxNWsnKfyQ01xyWVxi0LowuiHObLzF0
mm/Ra7SR0ZHDDRNJOS3Xa01JxtnBJCkbqmAD/8czUrgtWBdjk4KhXCbZhJITxmhZlzLEVA5Gs5Ea
y+JHl3EYf66cKhA8bv5RgfB4eGFW5TFz7zEOVWVlGlQSi4pWeFJuTnSULoVjpYLCEnaXnNz8yN+7
CLn3oRd3EM9FTZsvXFZefje5POKFZ46+9CiZ8dgzd4W42rr6Pr9s7dqrUJMacZUvafaBCWxw/16I
9x3diYsL56tcaAzLMzCtUYqPYe6QntDHjbpoY2T8cJ096lzjBUZtpIVkkYSg9Kh5QXVBmjEkJ6go
qoxMCDovSms1mUKCgyMNIRBnM+hMxqBIGw0OfdVYHvKq2bTQ1GLabJJMPSTp8QSzrEmRU/aSZFB0
/rgA4VjvMb76IiTUlqw1ZuOKgyOzUVXIEgQhLVlFgOtHRC6xk8hoXD7XHATDSJn5tgdueumu75Y9
71q2q+/1+/qy0xedd3HtVVfUjl/snnzrjo/eeZaM37yfjv19EnmqZfXc1Q/+vvLaMeve45a1CPEY
j7seA4lwYC8kIA4GBMQm4yOao1LOUdGmJq6zrouRrDHnxlId7I55LoalsPTgjtg1sRJwWYiLBRZO
wkzxkGQmVYQCMZMZyEhkthQXmx62IXxzOA0Pl2RbiM6CmhHeQ693xEXK+hR7vGxyWOQ8MJlNraaP
EKlxSSnjFPVIU/RDgUcoB/c2vZVLjnGz4jb1UhpXlbYlCFMa6oqESAWUJVKXoFU0hSQoYGnZjO6U
vu+eWvpc/d0Ebnj6E+OpH6Srayp39SXROWTtYu9+4g6//JumN698lJx71zevTptli7nhjuVk+ZCQ
tRs3o5VUotOcqPkbRMOzjnq7jv+mXXCh7qOIjyI1VpISnh/OJAJMimLhUdHRYciDJiQ4hAUbjGHR
0XbQRGKBUTaQSJrOIhAOiWmjUyEowhvJvGZKaLg3KsoQHV0OBslLiCGL/7C1h0bushheWW9NS1tu
/oFYsyrTikjWMcx8jxnBo9FkIUZp3B2b+bcXdWmNpt8VhReaX9JpzEVFOiSO2BL0RLkR9oLcgnEU
1UonXJAuV2dnlc/cE3+PzZrrqSm9PGHBuFEFkdaX419+ht26/qYltePj77SOqmlbf6qOa8+ovguk
K1B7EiGXxO+FFMWaRvYoaQ7Xn2LUH2lk5EgqWQsNc1NcKatHaZLTskfR5PDkqGIosknR0VHpFktQ
UExqaKo1JsYeZEFPbSFJAGYcoode68gNzbJF6qypFm2qLTRIa4s3Wa2GmJhyA8ohWAbLKguxWbIs
qy1vWKSFFgLo43to8i6DXTZDD3nDMYTK1yWQhOfMKcVBBIJIUF6qxRxkCcoLSlmIqJqL0tKK0swH
KpeQz9CXf2ruTVv+Q2XlkjYSk5W2/AAHebn5TZEIxLEoJgusXCUF5MdRU4Xj1yDaaVwx1xjNB/XC
hBULTrNYtNEWYbQFBQOsuSCXGamishGRFm7V+eGqVY/ZQxOTR07bOjkrNfyau+7+4KFvVry1JGnb
e/a2V65cvffCz6OGtpRUdDdtXDzhksUFVWHjxoVFzy3cP++64x/sJOm3PP/oSd8DTzVMWDUrhs5u
Kpg6cwXRdlx+27kbX+a+vgRd9Fj0glYS6eg4VyIpOmILsYVSA0nWTyGT9BewNfrXw3T1uuX65WEP
hD2hfyJMKwVLRhoZHIn+xmKl1Gq1A0FtJoaQEHuoOTI01Bxh0+poKoFQVGiDAcvLQw3XmYnZbMgK
LQ5dFfpGqGQOnR66MLQlVAoN7aErHBmxBkoNViuqezjBjyEbSBYUw3RYyH94Oy/GQMAcagZLqGXe
OPFDfa7cJG35NPMJbgdtXPkr05ZPDVgCbpSoWaLWmP0bZs1SzEPsl98yMLWmYaozKkaBnzaoXJJL
chk/jMVZbI9QXYdWx0pIzu5216MLrrhevnz3mvjJJdU7XCMWavb1vlY9d13b6Bt7r6GXr0/Km1C/
84W+0ai856CRJCHOGGeRLEfQfex59jn7iUmGHt8Bx/lZo/OmG1Yb3jQwmyHLcJfhMcN+g8+gxRBM
IgyhBMJSqU5nl0gkL6nh2Go1Wl2qFISo6XTNksEsUEM3wju0YoerpTclKjmCTXlSu95AzJIKnApa
2pI0RGLigvLdkmNqZrFoZihOKZYc45JFbmdZilJqHJ+ApZGp+Ai3K1Xx2Uo6JEtJLaqoIZKLxg8T
uR0xCcWDfu5fccYeqX6KP8VOqEaj0wzwTmlLSEGujkTkMlKatiutr+TI7iPS8ddeOxkhpZz8B9fh
fMQ2XmDb55hbpSHTNas1b2qYntg0WZq7NI9p9mt8Gh1lTNVTjh5DzUToGGv2K1w47Ic3gK6GN3G7
HMEY7zVICBtY5i30w8ZRa1NAA4c1vBj8oAEHTeSMQwowh2ABB4sX7UwoUFIECfwgAQdJlCJIoKLN
0z3jeaU9fDByAehOQy6tSEVNINWG2kryUTH7Xtfs+32Sat2F6JUt8J1jRpJulI7aaZI+n07Sz6MX
hNTRTv2ysAfD9qNRv6p/KczIoi1U0jJqsXCkiMNc2EpIv2GbsaDNTFT7Zj2kzxFGKdGmhlhCQ9GX
cgM19JA9O0LKzZg40NRJv5k/QVdgbEHJvh2WctJD9jki+u17nrXfsPGUF2EQJkswEXYuzrKitOIi
iDEfswqrRVfqt1tk1bNtjfHgQSW0zo3I1Z1puGi3R7YOW7zPeemm2DW7r4maUrrug9x6KWVvU+36
9rGrelfQu6uzRk148V994agEtRgRzUL0jCDDsr0QhmfYbDzD4mR8DDOQqsTWRKrVxEVFDmUVkfOj
5g2dZ2uJqrJpJ2qI17w08uLY5UN3Mc0Qm6TDIDjYJIMjIysPUhJiZNCZda06pvMkprgGRL8Y44jo
hp8WS9AH8VAmwlygLIOKgKaABzHjaCDiq91z008Hvv5L33c3XfLK4t0bWsa0VZdG2TY2z12/ZBTZ
RApevf/Eq3v6nrt/0bMbb7wtq+ric2su3HDXzNvfQJPxfd3nlibj+sIgAX53JJba5kkXmeZHLTZp
xkSNspVKU01TojTJUqYpLapAKjJpzD2+E46ZuPghHIEK6zLSab2a3AS/JmhjrCkho8lkUm9usGr1
CSQ8jLJ4Cw0LU03ObDbGK2eC1mIzBoelgtEgx0Lswlga20MTHEnA3X9YGLr/tcIazTzcOd8Aianc
BCEx6JVxA45nohy/lWe6dm6klZgeV/27ePaGYSStGIqqJagk4jTGwLqSkYCqUH7DGMbUA9h//kaR
3PtslZtm3fxi8+at8/a7l20Pi2kru/3ApVWlS10T+tyap/7iLPvw9W19322b9mzvfjalI3P8DLJw
z5pNUza+jXrkRpwXI85m1KNvHcH7QsjFMVfHXhXPhvLwCKGM4OFRGDKx0WOh0DgdLoRFoE3kbiEj
N4+njimWIXnaodFDLzDimWs2h0JkSBw1mkx2c2gkZvllw5gaquW3DXOqyWg0GkymcrOhNRTNFcE0
m83F5unmhWbcRFLjMBvC8PZhTkgNNZst5oQgvIakwEB8p2GkzSOfAK5n+p7j/QdoILLkwY4wwDQ8
XtLQDAfcV6IxxBEXlkBko9PqtPSH2679y6u3fb/aedfI4bf3vb677+bLnLPuW3yVc+G5laNSl234
+I3niWNzU/Nff5/Izr3jprXEvOqyv4ybcZNXjV7YhYisCX50XGxgVxk26TcaJG1odOg2/QvSl9Lv
TJtCU6XRJJ9OJp3kaqIzmigLpoibGrLglTVYVUyTciQgbuAwmvPAwA8FvmfZ/CKLEWgVtOLhcAL9
leK5GMwzixPilb2kCAKHhEANvfFE/tt7gHsYmaA6fqMFfXtotOLwMywi3TFU9fUVatCS9odxSj/Q
fv1F9+B3ckrMztC5bc6Ydces/OnnZY1e+GLhfCnlg4uXDrs/8Z2+433zOF7T0KMxxCsdftgdPMKE
t7se33s7MWVcA2OQuSH09oTbE9lStjzmxuAbQqRgbuqyqqcJXKoEmSvZOuvW4G2h0iTWGbw2mI0I
SUpItI8OkeSQYBafqE/EVCKWpOhZEZBEyPBYW4ROYxseHM9f+Ji9JJ1f+QykXOZBHuHXGoc5g7+P
OaGXIdmcTJNPRHPEwpKG50G0OZoejSbRz2TOe0ZxlkvSpv5Y2XusEtm243hQLAm8MeAvDMIshSRM
eckCSshNxDOiQFyWxVuWpGE80BZaqbxHiEKT59+oSOECUubuzr503rJlScl9H6dOLHlx14tvSdul
1e0XNWQMXfFm/jznC2t6Lr2ULA6e1jypanzWiBEXxwxvmbxy196bQqpa5+XkpMTmz8+b3TH95gsv
vFC8UfmWXq+5H2JhrWPEeaY601LTGtPNxlsi7jN0Dzkw5IuIICCEQYwJwoPTw0K0MTYWbDoRhifs
DrM3fB/pgwgatzOy3BDSQ+N2hHqDn6RxqKxxYECQgpPSUVnNhusMzNBDr9sZN3onfzFXmfbjsR8R
D/5U3ingTTBMXP+49iTrxDpH5RXwq19EAeMXPuWOTL4eOv6cRkd27KXXxV9X8MbMHUO3X2xJHlG0
6S9ho1JL7Supez3RrOhbub53d2u0nIjrW416tVRKwfO9z9Eeo48x3BD8uO7xoM+jPrXqDHqD4YqQ
q6w36G4Ieog9oNUPCyqwLtUtDfKGtFu16STLXBg2JUyKirFi2BEdExmNUcYq3O7oGB52aPSR+mwM
O/REo9GDPibaoMe7nwndXIw1SBObGh2j15gt5dE8oDBZy4tjiDlmeszCmJYYKQbvFTvj0MJ5LDIk
RM7WkDc1RzUnNCxLU6yhmhiLxqKJDRr9jOr4pnGjnXr8R/4KagkmIvJAZ8gD1OMYexQVKYcHDz34
9W4NMuLOYDQr97vKSr+/K8BoVX3fkI/3PMzZWcz+Fy++KXH17mvDp5x7/kZ3QnR81e4j9x14/5q6
iVuoq7diblbRxPNWzivoIq9gWEt8vRi7TUVMTcToiAw3h8lhdJjJETYjrM7UqTsapg0Tx0LG2Dyt
IdqAUZgWVYjixR0kDV5QDAZ9UBDD6C3EaDQFB1ODIQhPC73RoCWSSa/TMUa1QRiUmPCCdr42qCaY
R3MG4/nEVAP6Gt0+mghaGryT3zW4+hESudsMLXiY7SNvgJmw7VzHfqo8hmj1IqlP9Z2D8kQLFK+v
9AfXmPUHjUVKitxBZIzIYIgvzorKJcJV6n0/70gaZerx/bwndkiePsgqeIchypKnCwq35BWoobCd
kFw0VYx1iX1YyjDCyOt9v7w4PyeV5HzYN4GEvLgoMa3vII2jwU8tcpK1vZ/3/uv90rq+FeL3uxZK
y0H5qz7+f83LxO+xB/HftxM8hRDNt+D/6z+NmgMqLwFqq8prwKo5pfJaGKItUXkdHNRWqbweUnTd
Km+ArtD3VT5IelaMzPlgqDZWq3wI1BkPqnyodpcuSeWNsMA0IvDHCFaZrgr8TV+NOdn/R3lBG75C
5Rnkh9epvAQh4bervAb5K1ReC8bw+1VeB9Xhj6u8HiIiLlJ5A5RGt6l8EHWaNSofDCOj96h8CORG
f6HyoWx+hFXljZBpieN/LUliODejZa7KSxBrmSJ4jShvUXleXiN4LcffcrXKI+aWFYLXifK7VZ6X
3yB4vSh/RuV5+W7BG9T9VXhlfxVe2V+FV/ZX4ZX9VXhlfxVe2V+FV/ZX4ZX9VXhlfxVe2V+FV/ZX
4ZX9VXhlfxVe2V/OBw3AKmgAVsFYHqmuPRjLZXXtIfyvNFs+UHkJhlheE7wRy/WWn1RewrZfCp6/
RDNaDSrP++8VfIQot6s8llstgo8cgHnkAMyjhPw5Ks/lRwo+WpRfoPK8vEzwMbwf6xKVx36sLsHH
CfmrVZ7LK3sdP2Dc+AHj2kQ/W1Se93OT4JNEP0+oPO/nMcGPEOXvqjwvf0nwGaKf71Se9/MJ5/UD
8NcPwF8/YF36AesKGSAfMkA+ZMC+hPj3ZQ50YvTogjpwQg2mMjyANAcaBD8VXWszkleVkmEi5tqQ
508nlruFhIwljdg+E7kSUe78v+wpKzAzGWZjTaP41/SKjAfLpmCqjDcSCvGbDRkqlyNKx2OLRkxn
YZt6nINXtJqF/XmQ2mApPmvFHJqxzgVNgZm04bgySjnVkRR5NyIkYwvenvfYjLEqH4XXOMVINWpf
TixRWjaJHvkKGnD2TaJHN9Z4hXSDGIuj7lVH8IgV1oi2XlHfLHrhKZ9Ti5iDW11Lq+ibz6hGzMoj
RuM1XL5WpMr828Voshhh4Kzcon8v1jeLfIfou0Ed3aXKtoi+lLH95Y2ib6+KSA3mFGROl/Niny6B
ihtTpe8ataRdIM33ql9LWsS+tAlEG0V7PlOuHU1qK/8INaL9UnVUt7pSXqeg2Y9CHUry3pTSflzd
Krot6krcQr5d5Pp31SM0tlHM7o91wm85nsBaXOK3v3l//X204TiL1dk6VfxrhE7Lqt77MasVY9eL
UqV9B9a41T3kMo3i35PwFi34rMe6pSraSg/9tuwUe6VohywwrFHX7xa71ihkWoWdKdrYLFoqKxmo
3e6AZslYv0zdmSYxG66byr55VEtuDMyjSeT6tdd7mr/xnLa+GnWMatFDu0C6dpBuumAJlvuR5bpd
E1hhndBtWejAMoGtR+idV+xGfWDX+dwVe+e2lB6wJo+qZf3+SKltEjvihOWivTJr3m+NqO3XNGX0
WoFWq7CSzsAq/GPz9h2i3imQaFPH4DakoOgV7f0z9vfeKnSoSfhQ/9wyz/CrYwbtGvd39UL/nWJm
U8TaGgXa/F8HKaP7PS/3nKPxKUMq9stl2oR1KFY1fFDPA3vqL88YVD4VbaG/7lFhG22qr2gSM1oc
0Iv/03NC2ct61Xu6VJ/Y79uUXufiGSLDDNFehhQx3lR8Tsex64S2+1Hm+uwRO9Sg9pYJ01BuDq5s
EtJEXBHnp2Mpbz8Jn+eL8lIsmY1PbjfnIvKl+J0qSudAKAQJmiM03fMHdiAHypUZK7vdqupDv/2c
iY9yTrYgBm1CoxqEtH89/tPCr4PVorYT5dsDY9YE/K6CXbto2+8vXapFca/W7+MV3+JW/blH9Tf1
ohdXwF9zbCvU0bjnWar6+erASamM6f03yPg1sCPgOV2qN3AF7K1N+Dav6mvqVFv5I7z8HoIj5hrQ
S7+HOXO8WlW/uC5XC6+tzLpa3Zlmtec/2qFhYlWDkVJOizO14syR/X6Xe1iniIKcOGqjirZH9W9/
Nnam0P3mAWdA5xl74VIjoIGWo5wsTjGjVoEsP+vcwt7+857Lqi42D/C7/nG59dcKpN0DTri2AVFa
ekC6bYDe9scV/x4pPrsm0b9fr1oG9dch9n+x2M2B3sTvu/slW1BW8TPtAnHef0NgPcq8Bmp3k+rt
FfwVq2pV9aP/VBisQ/9uRf36MUWs/cyd88eF/Dx0qdGjsholFq0Ru9p82h60nYZ3f898fS3itKhV
/epSEbd1wMDI7z/vvr8/xSZdanwy+BT393fmPipo9UfTNaLPM+3Yv2PO07Cu+x/Nth/lM0cYHIsM
npFLjbC9eI76e+CnzHgszQB+go6GPCjAU1PG50jMZeAdJQ8pG/i9fC6UqZLZWDsSa/JUvgBykXir
fBiF9xlOvPcGEce04nhZ+O0Q30wRDwy2+Brh+f7snOBcibDOjoBeKKegW/W2fE6zhIdWztBpamzW
okb93D6Vk7RN1LjFDszGZ/+5wbWK38Z4NPE/m3eWkOd/Sy0Ln17hIfheZYmzZ6HQEiWeyAxI/u+O
0CFiAEXW9b8yir8u6zR9DPQ9p7PVVeescckPyHMaXPLUluYWLxbJE1vaWlvanF53S7Pc2liTKZc4
vc7/IJTFO5NntzS28xKPPKUZ240sLMzOwEdOpjy+sVGe5a5v8HrkWS6Pq22pq3ZiS7PX1cQ7aeuU
PU5shOXuOrnW5XHXN6fL49vczka5BqWcbqxsamlzyQ3tTc5mt8cr1zQ425w1Xmzg8bprPLK3wdks
Y12n3FInu3GU1jZXravG5fG0tHlkZ3Ot7MT+22saZLfalbtZ9rY3u+QOt7cBm7uwtKWWt+Z8oxPH
wPZOnIy/zNvhava6XShdg0x7W2emLCBpWepqc+LyvG0up7cJq3iDmnZcoocP5mmpw2mKKdS1NzYi
K+aKwze14CDu5tp2j1cs1ePtbHQNRIJvjoeP4mprcjcLibaWxditE+df044DNYuZ1bqd9S28vqPB
jStscDW2IiItcr17qUsIiF12yo0Ih9zkQuya3TUo7mxtdSGMzTUuHESB283Bkl3LcDFNrsZOGdfm
wU1u5H00uRsFvF5VbzzqeDXYotolt3tctQqariXtfLLtNRx/ua4Fl4w94qK8XndzPV96mwv33etJ
59vkQciEHmG2yVnvXO5uxq5d3pp0BTRsXuv2tDY6O/kQvHWzq8PT6mzFqaFILU7R6/bwjrl4a1tL
U4voLdOvq2OUpc1y1bc3OtvkKV5no7tmzDxszpU3J3N0jpw61V3T1sK3argirAgJPkPhp84Rufvl
OW2oFU3OtsUci39nE7jKelRPF2qi0DYUnTtbnuH0yinynKny9Lq6TDFlV6PH1dGAYpnTps+ZMmnK
xPFzpkyfJk+fJJ8/ZWLptNml8vhzZ5WWTi2dNic0KDRoTgNukn8P+IbxjnHZiIdX7E9gPmiTLfVt
ztaGTjEONwuOYHWn3NnSzlvWcN3F2bU31wq9RG1BVRMaj9riRj1HcWd9m8vF9TpTrsBmDU5UqpZq
bpTY0jtoMhzADq6cLlQDF9+3NleNF7WmDnelf15cIVrqXUJEKEygHW402kJ1uxe7xmm2oH0OWNAw
j39SaBYBKAKNue7KS52N7c5q1FenB/VtYOtMeW6zsIBO/ypwTermoLE4ZU+rq8Zd5645c+Uyotgs
dJe3ddbWuvkeo5q0CZeWzovbBLbCV5w2qUZ3k5svCAcRch0tbYs9isoL7RaFLR2oM+3VjW5PAx8H
+1LgbkK1x/njVrV2yoopqAgNHkjgMaWuf3HcFy5pd3nEMOhFa1xtzeoK2tR5C2FPQ0t7Yy3q6lK3
q0Nxfmcsn8vhTrrQn9T2O8zAGnFawk3XePv3mC/Mqc667o+7FVMONFC9iNoRjuP0juECc2ePlzPk
1NF5BcPlgpGjM7LzsrMNhrllWJg9cmReHj4LcgvkgvxRhaMKQ4MavN7WMVlZHR0dmU3+ja9paRpo
Ey65pM3ZwbFAE8RJYU+zWqrRQqehN2tB15/OjbTNXeN2yrOdwjY8eJaNzvmTvrMavE2NWU1e/v+r
zGryLHRyP5HJC//LBh2uRix1/ecmPJel4iikB70cmSjCbI8IfJ2DahaLmuVw/E9qlDYDy8sGlLeI
8Ll9YD3bzJ5gD7OdbC/b/icvaJTrwcC6EjITU+9pc24ZMM4fr4Zfyv9obp0ifD999I/VcGdQb1Ks
NFFySOOl0VLOH/T1B8iQ7MBKFg9qMQNaiFNcUppPm3GzuNy44SvBDawpxb6Wi7DeCQD/H0bdRHVl
bmRzdHJlYW0KZW5kb2JqCjE5IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgg
Mjc4ID4+CnN0cmVhbQp4nF2RTW6DMBCF9z7FLNNFhCEkzQIhJaSVWPRHpTkA2ENqqRjLmAW3rz2m
qdSFLX2e957H46SqL7VWDpJ3O4oGHfRKS4vTOFuB0OFNaZZmIJVwK9EuhtawxJubZXI41LofWVEA
JB++Ojm7wOYkxw4fWPJmJVqlb7C5Vo3nZjbmGwfUDjgrS5DY+6SX1ry2A0JCtm0tfV25Zes9f4rP
xSBkxGnsRowSJ9MKtK2+ISs452kJBd+dzyVDLf/V99HV9eKrtaTeBTU/8TJQyiNdiPKc6JBGeo5U
Ee3PRI9HumXNy37T783kB5LlVfTuopc65PtjPHxaI6Ip9Bxmex+ImK31s6APoCGE5yuN9z8yowmu
sH4AUGeLtmVuZHN0cmVhbQplbmRvYmoKMjAgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
L0xlbmd0aDEgNDMzMzYgL0xlbmd0aCAyMTgyNSA+PgpzdHJlYW0KeJzsvXd8VEX/L/6ZOWf7brb3
ze7Z3WzapjcCG5INSagiRZBEiISmFBEQsKBIrChFQERBUGLBAighFENRULEgKqhgAwUV7FH0QfQx
ye79zNlNCKjPfb6/3/3nvi7n5DMzZ2bOnJlPm/fMOQtAAEAD9cDB4KpelcOe3XDJKIAGAYA7U9Xr
korEYDteP2kCkBSMmzpmevW7n4wEUG0EMPcad/0sYd26Mb8A5HwLILv9qulXT9157I+ZAMJprN/3
6mtuumrxtb//CjBQDlAyZ+KEMeP3TXPr8InHkIomYobqZloCQLB9SJo4ddaNH8CmGryuBlAOvWba
uDEksA7rFl8DYFozdcyN0xVXq2djeTHWF64dM3WCenP+uwD33glgWTP9ugnTz+z8SAOQjOXK54GN
jb73432nwteO1pb8JldgN/B4IjBkDIu39dyiiB7+c6nEIQ/ipQLrE7EChtJn21cB8O9ED0ff51vj
+ecOjuVIkokP+sF1IAEKOsiGcix4FJ/LAeXfgatZRYxZgz8QJeyCk0gR8gWtJZnwJSwlQdhJ3oGv
4RSWbIBX4UPYRwzwAXxDjOQdHONYmAAPECN8BHoYAfPgUaiGtSirKXjHBqjBlA2yYCJsQaqGHbAE
LsN+BGAwjIMjtCd8RUqwZSC7YSlk4h234h0fwVwYDi/CVtiDvTHDNbAMy+qx9CDcDyMhBMX41BXQ
QlbQEvIA1tHjOQ/bZ0+6DFs6d27A+2LnzvjJWus4R8bPNjIEe3ELLCHTxF6LbCG7SBk+x4B9nYot
jYUHkK6ARghCETwNX5BUkgw9cTTT4WvyA47zXtiMfbkMRzYP72N9mohkgGXRX3D8R0k7CWA7q7Hn
45DzMphCh0ECGKEVORmEE9iWHsfAqBq5FzsB2wBsk507SQk+s4T0oEA2k50kRA4j9y7HZ+5AzhyB
FloSbYfbsPUV+LxMlF4CuZ4MJ+PiGsHkMhfbZLXn4TgZ3Ro9RffhM5eK9Chet+PT60Wqx5Y7KAv5
xmgicq0a72PE2lmCEmF0GXKREfZCpHk4wiuQX9uIE1bCIbg5eooYMJ0AlMztIBbCs8irVbCUJoqm
kEgTWRijjoPMxVJWWzz+Kf3PB726I4GnNk7Po7yT0Q7QEkg5NOMoKY5vLdFivxVgjP6LEpIFu7CM
kklkEjyPusF41MG5Di7FODW3k6ag7k6BUuTzi+fRBtTnGtTo+zv5WY8EyE+I8zTGzzmdvOygAOo7
k+lH4vMNqHGDYTpaJcvvICxH/SqBe7D3aqynAieVo37sInIIR9tQy8qjZyE9ehh+FS11Aj7xiGil
NcgNZqPLUbbjUW/2YR/G4RMSoQRLx8NYlNpCsgtGEB56k8thIWyhWtSUchgG/UkV9v0t7PcIlGEV
zCapmFqGNFvU5Hl47hD1eAP4cZx6uAEysE3WA+Yt+kN1tBW9UyqeN2ANG/Yo1ot52IsMsR81kAY8
nkx2I1C7Ldjfpci7m1GvrsDYhFc98LwR8sGD9y9DYp7kKez/DTjOgdAbvHgOwNafgtshCe7Au+7D
u5k/eRE9wlbIj/6EErsR75iCT16JFp4LE2mA9Cf9SD+aRF7AcyVZiakBNIkWoVavpCXcQthB3kbd
fpSY4QloIDeQfijdiWQmymor7EWvcRfanwsGYfpX+BM+h8fhNdgIb0MDSvkuLN0Dv6N8v8X6K0T9
3ItlO0Q6JJ4dLU9AT3uu3bvENlmLne2RG1AiWzFnI60gi0gdSSJvkDeglaJRkWPkIaRj5Amkt8hR
8gkZj57tDJlHhpFuRE5kJAUexNpf0/7kPfIvoiEpRI+SPWd/b1GOEsqRx8mTZAOZSoZi3hoyltSh
7gXEKiqQijV12A92LEXOM9tihxJPdqxHT3kaHkI6jbUeRVvAE3vC/HQs/yFyBzmCPX+GvIX1E1EO
wc64I/1/4MC+rxFnOJyy0cqVcAA59BBq/l6ym/wh9lN0FpiOj4+8Se7sHGtHXnysf4kfJUMYiTxg
JI3xpjO+8FDH+ROPiQPl2yXu4C1q74divBWKxXI5zBDjJtIk5kdQq9n1v7Cv7MDxiGNZD9eL11ej
jd4Oj8Ea9CRI1I7SRr2AMXAJcuQo6oYGNeAJ5EQtCCBBObyF5xGUxh1Yyp6yBtaQ78lv5De07ylk
GzlDviLJdBxyrRHtphySyQnM+Yr8RF7GFt9ALjyKz/oIccO78A6ZTGZhD9+B3djHEtTle1ED9fAT
avtuPN+Ah9F/3E1q8XwJz93kYXL8HLc7ucA0hfE5UdQHIH3wrIZ/wafkD5QXIi1xjkK/iX1YhVa7
jxwge9EPvoaau4ME0TJs5EpSyc2FN8X715IXyTryqmjjQfFMFc9o57kPOdD1+tzZC2sjdc6f/y11
nTv+jk6hV2JzBhvJ/4QunDm60jgRd8SI9YE94x/uIdmIdn9DQl+I/tmEfvRGkabgORbvZzQYNTsN
fesUnMV6YZ8nijMZiDbPyBVDpMqMGBJV5QGvRFxNpuOFDLXyVpT+EnI/eYw0ohZGaQ19g+6nn3GE
4zgF5+du5RZwi7jHuHd5NT+IH8WP5pfzD/GP8E/wW/hd/Cf8d5Idklcl30vOSNVSp9Qj7SEdKp0i
nSqdIZ0lvVV6t3Sl9Enps9JN0relR6Qnpf923+X+t6AVzIJb8AnJQo6QL/QQSoRSoVKYJzwpPC1s
9Eq8Rq/F6/Mme7O8w7xXeld4n/FRn9Sn9Rl8Zp/D5/Gl+YK+vr4xvgl+6tf5vaiaNKAO6AKmgC3g
CiQFMgIFgZLANYH6wJ2BewKLAssDjwU2BpoCOwO7A/sCBwIHA58Evk4uSQ4n90quSx6XfFXylG8l
3+q/NX5r+zZ0mp5WnM5ppa1Ca1FrSWtpa3lrZeuQ1prWqa1zWxe2rmiNtinaEtoMbXltlW2D2mra
xrZNbpveNrttSduytgfanmp7pm1928a2xrYjbR+3fdae017Wfk/7r5G2SDTaFo2iKAScJxjHG8gm
RJx/IsdfR45/jG66g+N3Isfv457gCZ/AD+Gv5JfyD/IP84/zz/PN/Mf8t5JGyS7JIcnpOMe90rC0
Djk+/W85ftpd724Q1IJRsAqCyPE8oXsnx59Ajq8/j+OXeUd6l3ZyXI8ct/vccY7X+caLHBf+geOD
Ozm+NNAQWN/J8beQ4x8jx3t0cnxC8uRvichx87d5p8lp/rS2lSDH01uLkePh1orW3q2Xt05undO6
oPW+1rY2ucjx3LaytkvbqtuuRI5PbZvZdp/I8TWdHN+PHP8UOV4icrw+xvHoV2gIy6Mm5PFuLjN6
jOKcFtGiBSxDVDCZzGhrwOtJouMORtIjaZFUTM5BK5sFk+EqxEYlbZ+1HWs71Hag7UTb+20HWc22
VW0rMVze9hiey9vmtd3ZdnvbpLb8NvSRX9UCfHksNqWcuOvEii9GnrjzxL+/eObEDSdewJylSAtO
zP1i9vHJx286sfOr4In7jj9z/MHPH/z88c8XAnz+FLvvuPXzGZ+Pxqucz8Of53+edKz3sapjJce6
Hys6ln8s51jaMd8x5zHTMXL0p6M/HP326KmjX7K7jr5+dM/Rl47iU46+dnTd0U1Hq472Olp+NOmo
76j3qNux19HmaHX86fhC9xKrLXlJ9pTsEdka2WrZwzJcwcr2y3bInpM9JluL6WxZUJYqU0oj0t+k
LdLvpF9KT0g/l74ufU36qnS3dJd0p3SHdLv0Ueka6WppP2mp5KxksQT4CH8N8zHk2vMnVs4do/Ou
U7lLO6/X/O183FF6N9csxh//benrSDgf83fzC/iVF5byi2L0Twd/PSP+xvjVrP/UjwvuvITv7D/f
/39bO4MvuiBn8vm9+P9xcIhN74S7+KvhQfga7sa5fSE8guu5J3GFsgDFcQeuKU7DL7AYZ+x74BU4
Bj/jzL0e5+pf4Qxi1404A78Oz+FsMg7no/G4jpiAKGA/zuEHENO+A9+gFbyHGP0QrtWuRpywDA7D
+/ABzjTfwQ+42p4Mk3D2mYrzz7WIqKchGpqOa4mZiE1mIeK5AXH1jWhPN+FKYS6u9V5A5DNP3F+4
Db6HHxG7P4iojxKO8EQCrdCGWGEVYo7V0A4RIkVULIcoophHEMWsRZ/5GFEQJVERNaLgJ+As/I5Y
eB15ijyN6OBZsh7RxUbyHHkefWsjrs6byBb4A46QBWQh2YpIaTuii2ZE1gmIQXYSLdEhwjbgmv8L
YiQmRCe7iZlYELm/iMhnD+KVl8krxEpssAkaiR2R4KuIQpzERRKJG5HM6/BvxPpfwlfEQwTiJT7E
Wm+S/YjWDpC30be/S/yIcwIkmRwkhxDlvU8+IIdhJ+L6VJJG0uEknCJHEE0eh0/gUziKK5OP4DPy
MzlNfsG5+FdEkGfIWfI7Iqp/kz8R47SSNlxdRkgGztO4HKYU1wM8lVAplVE5VVAlyaQqqqYamkC1
VEf11ECN1ESyqJlaEE3kUCu1UTt1UCd14RrfTT1UoIuol/pILsmjfpKP66oATaYpNJWm0XQapPfQ
eyUJEi39mbuNu4O7i5vP3cst5pZwy7kV3CruEUQG67hnuQ3cc9wmbjO3jdvBvci9zL3G7efeoae5
97gj3CfcZ9wX3CnuO66F+5n7hf5Cf6X/omfob/Qs/Z3+wUm5RPpv+idtpW2cklNxapwJCQ7sccQY
T/Lr+Kf4p/ln+Gf59fwGfiP/HM6Cm/hGfjPfhAhkK7+N386/gPPiDn4n4pHd/Iv8S/wefi//Mv8K
/yq/j3+Nf51/g3+T38+/xR/g3+bf4d/lD/KH+Pf49/kP+MP8Ef5D/iOcVT/hP+WP8sf4z/jP+eP8
Cf4L/kv+K/4kf4r/mv+G/5b/jv+e/4H/kW/hf+J/5k/zv/C/8v9CjH2SP8P/xp/lf+f/4P8Nm6GJ
LiAFsA22w6vkFK6gtyL+vx1ehvmI5L6he/m5iLFXQQva4Tq4H1ddS0g5zkPLEA8sx9VjM7mFtJCf
+On8DL6ev46/g5+F/ulOfjZ/F38j+rj5/D38vejpFvI3IA5bxC/m7+OXID5Ywa9ChLCaX4PI7EHE
Zyv5W/hH+bV8A/8Y/ZwepyfoF/RL+hU9SU/Rr+k3XCLn5gq5Iu5f3Bn011Lo3LYkFNiS6/wDCzle
IpXJFUqVWpOg1ekNRpPZYrXZHU5XotsjeH3+pEBySmpaejAjMys7Jzcvv6CwqFtx9x6hkp6lZeHy
XhWVVb379O3Xf8AlAy8dNHjI0MuGDb98RHXNFSNH1V45um4MjB03fsJVV0+cNHnKNVOvnTZ9xnUz
Z82+/oYbb5pz8y1zb51Xf9vtd9x5193z77l3wcJFi+9bsnTZ/csfWPHgQytXPbx6zSOPrm147PEn
nlz31NPPPLt+A7fxuec3NW5u2rJ12/YXmnfs3LX7xZf27H35lVf3vfb6G2/uf+vA2++8e/AQvPf+
B4ePfPjRx598evTYZ58fv4iKL6Lii6j4Iiq+iIovouKLqPgiKr6Iiv9fR8XhcListGdJqEf34m6F
Bfl5uTnZWZkZwfS01JTkQJLf5xU87kSX02G3WS1mk9Gg12kTNGqVUiGXSSU8RwlkVPl71wmNyXWN
fLK/b99Mdu0fgxljumTUNQqY1fv8Oo1CnVhNOL9mGGtedUHNcKxmuLMm0QklUJKZIVT5hcZ3Kv1C
M7liSDWmF1f6a4TGFjE9UEwvFdMaTHu9eINQZZtYKTSSOqGqsff1ExdU1VVic5tVygp/xQRlZgZs
VqowqcJUo9U/fTOxlhIxQa1VPTZTkGuwU40Of2VVo91fyXrQyAWqxoxvHDykuqrS6fXWZGY0kopx
/rGN4O/VqA2KVaBCfEyjtKJRJj5GmMRGAwuFzRl7Fyxq1sHYuqB6vH/8mFHVjdyYGvYMfRCfW9lo
nXPSdu4SGzdUVM/vWurkFlTZJgnscsGC+UJjw5DqrqVeFtbUYBt4Lw30rlvQGx+9CJk44DIBn0bv
qqluJHfhIwU2Ejaq2Pgm+KtYTt1koVHh7+WfuGByHYrGsaARht7kbXI4wjuiJ8BRJSwYVu33NpY5
/TVjKl2bTbBg6E1b7GHBfn5JZsZmnT7G2M0J2nhCremamNBZJqbE6iw1YGgnZwnrkb8fKkSjME7A
nlT7cUzFLJhQDAvGFWM1PGoI3tU4HiUyqVFRUbdA14Pls/sbJQEEsQt+Q6de52/58fycMfEcaUD3
G7Ak05NOVcPyjnRjMNiYns5URFaBMsU+lorXhZkZ1zfTSf7pOgEjZB8MRt6OqemRjez3epmAFzaH
YSxeNNYPqY5dCzDW2QTh7GBNI61jJXs7SszDWUl9R0nn7XV+1OSt4nLW3ChP7vzT6izGqok9Gonl
PxRPiJUPuMw/YMgV1ULVgro4bwcMO+8qVl7cWRZPNRorqjknjaeokxNLUSlHdVZmF9XqRj6Af1JR
qcc3y+SolWIOEXo36ur6xsIapdf7X97UHD3N7hKjc7fFu9nYI3j+dei86/O6p17AYYf5ZDpg2BUL
FijPK+uNHmjBgt5+ofeCugVjmqP1Y/2Czr9gB5fMJS+YXlXXIdHm6M6Fzsbei2pwEBNJj8wd0b3c
3qbh+eFmjHqI0ZaEpLx6Fqs0YtykyC8rz+b2wnSkTUgHkXgYjeG8eA4HHgzLkFjuErG8gdsFjUh7
kQ4hsZydmLMTc3Zizk7MKUOYTLgXuO1NSR589NYt9qS8n8sd3BaIIlFuGbcQvNj2lfF4dDxegnE6
xkvj8WJuYVPIoy1X4DWBnzGMIlEc25qmPoPydoiJbiViYnVHzuotmOMptyOUb0TCKtirNdirnzEk
2OpqzF+N+asxf7WYvxqI2JQ3Ld5UPLGmSWuJ52CiXMnVcJdDHjZRHY9HcJc35Xn2lNdxw7HpTWLY
wA3DcIkYjhbDQWI4TyydJ6anielpYrpMTJfF0yzM7hJ6xFDLQm4odxmkYc4Qrr8YD+aqIIDxILxm
8aVcPzEeyPUR40sw34bxAKxnwLg/11u87ofXlRj3xWsW9+F6N1V6csqn4/VoLKP4PJZfiX2oxD5V
IpNYzhKkBqTjYs5oDOchHUTixJqEq8SzAs9yrhzvCGMbYSwJA8eF8SzDs5QrxZKeWLcnhmGuRBxj
CdYqwSeVIK9KsOUSFE8JiqcEZFwJhgJXCDlIYaTBSHVIEmwnA+/LwH5l4BMyuExIwra8dBGYMBbi
sYcuBDfGbrqwye0JlyvoVhiMVIc0Hamebm2SGLTlJqzH6mYjDUIajTQPaS3SJiQ5lMVKwipaRsu4
QXQQx6N2p20pKckT4/yiWOxKjMVqR562/DouDdmUBmuROOxyGnY5DYfaceVBoqg6KbAH6SDScSTG
8BRkRgoyIwUHmIL3p4i1pGK9n5GiSBwqUQq2f34diXi3Bym7SyssNxVzUvEqFe9JxbqpmHscQyLe
wcoHIy1B2hMv84nK7BOV04dt+bC32RiWiSkthh7O10QV2mbkL+mhLe+GfB+EhIV0MXJzMfJtMdMQ
yow4G0vK4jWWIG1CkiBS38Gl4ZmCZyqePjy9eAp4ogQRIbrpUjyX4HkfnovxXITnQpSGaVNwT5CO
LpxWOK9wSeHawk2Fewplu+gYPOtoXVgJFgtOPAa93FGuozyMAg35UwyfE8PrxDAshtawY5Tm5CjN
m6M0q0ZpVozSVI/SXDpK03uUJnuUppmMDVuDmqNBzdKg5vKgpiioKQxq8oOatKCmXE9qyAjQwEti
2EsM88TQJ4aJZESTBhS7yUjwylHjScpW722eU95mnjR57vA2yzG6PXY1MhaFWOZ2T473ak9GLCc5
FiV5X+SxBRhONoKMBMMZsv2y0bKwrLssS5YpS5WlyPwyj8wkN8h18gS5Wq6Uy+VSOS+ncpCbmqMn
wkG2t2ySsp1XkPIs5MW0jrKQbUPjTE2JnEJ/aDRyA+iAy3qRAY17x8GAsULj2cv8zUSJU5jE34s0
GgbAgGG9bI3dggOaZdGhjcXBAY2KwSOrNxNyXw1eNdJ7mgkMq24mUZZ1l5OhxR1ASMZdi53xuKaG
3VO9mSeLF9eA5foyW5mhVN+9d+XfBHXxMHjusAW7XmBPEhsfHHBZdeP6xJrGPJaIJtYMQM4xcLmD
FtOiqsodtBuLaqp3KOtpcdVQlq+sr6w5Vw8EzK/cAV4WifVAYPVAuKCem3Zj9QIsitVzi/Xc59Xb
3NNbVbnZ6+2o01Os0/P8OlefX+dqsc7V8TpcrI63Sx3ZCfCKdbyyE3+p4/4v6gT+tk4Xbk7oFfwP
B9kB/cmHmyvmMGRe56+agFTXuPD6ibbG+rGCsAMqyIdx0J5cN3bcRBaPmdBMPvRPqGys8FcKm/vP
+Wt54xxW3N9fuRnmVA2r3jwnPKGyqX+4f5V/TGXNlj5j0p8773H3djxuc/qYv2lsDGssnT2rz3N/
U/wcK+7DnvUce9Zz7Fl9wn3EZ4laj2oph141CAXFeAtVKVGB65zeml4W3fRSUZtDXtutzp08kGdA
hchYjassDRIryizPLGdFaGWsKIEtwOJFtltDXudO8ky8SIfZen8vsFVNqsS/mTPjif/yb+bMmbOu
nHnlTBaLfzNnzUZiYoKZMHMW4AjK1eL85kFvzHzzQqRFoo/mZs6smQWiTGfOBtbaLBaca7wzNRtb
JjO7KgHMvPBgmhGEGGFzM2cTrMUqzo6rzUz2oRk2A6yTsUaA/wbpfnBi7ObG4nwN0eNx+jJya6w8
0h6N0o/QPQ2LU+wYhucKMRxGBsZiGA+HYSosg4cwL5+8C89CGLSYfxg4wn69UALL4QY4AsOjv2Cu
F56AnyEDusPEaET8cjdC5sITJPbFdDF8wL5lpCVckP8BXWM6yeE2kNshE1sZBg+CFQ5ii+lRJV5v
oYm0BO8aBge40fKMaE70V7KX3x8dC4+TEvoh/zy8DS3Ex0PkjujC6OroGkiAM1xi+6vR3OhUvGs4
1MFsuAV7UA+Pwjukhvake6L3it/FT8DcF+AACaI61SGeG4q174SVsANegoPwMZwihGhJKqlnO3sS
aN8X2RftFx0bnQZVcCkMhnosTSQBUk6v4K7gnuM+av8qciLqxraHwfVwI9wMS8TfDHwEn8BRwlEl
HUaHc8+BE3qKX7MvQ549ipzcD8eJnBSQHiRM7iYb6fU8174P53cezMjBviL3l8Fq5Ok62AT74BC8
h23+gjzliB1FP5yMInPJXeQ+8gBZRzaS58kPVEI/5jjuNv51/ofIh1Fl9OHos/hcJ7hAQKSbgTK4
BOX5DnyP40snGaSMvE+DNIMjvLo9EsmP9onOi74W/Qj8kIJ1eyKqrYKBMAJ7fRPcAbvgdbz3HXgX
vobfkUscURID8kIgfjKUXEZmi/u0P5N2akH5FdNraBM9zAW5d/gR/PPtWyPmSFPk50g0uiHaGH01
+rYo3yJ8TgVKoBamo4ExiW3D57wGJ+E7+A2fISUe7GtfMgDHuxLbP07aUJ3k9Fa6kUYR+y7l9vN2
fmXk0sjUyMrIlmhBdCDqFoeQyw4FePZAbRoONdj27cjNJ2A9SmYLas+H8BOxETfJIf3I5aSa1JGJ
ZBqZTmaQm8ktyNVnyVayi3xIjpKfKE+l1Ix8CtJx9Ha6nG6l++iH9CQH3GW4gpnB3cwt57Zyh7hv
eR2fwefwA/k6/iZ+jgQBmdQif7vN2ja1fWz7w+2vRrIilZEpkYWRlyMfRr6MqqJ7oqcQiOZgH2vg
auzjXBw/2+1fi/qxHvv4BXwDP6DMf0VecERBHNhjjyi3Cuz3QOz5CARMV+E5kUxG/teTDaSJ7BZ3
ufeTA+R9coz8TAn2PgvPEFrBcHoVjuFhuoE20k/w/I3+G9fAGVwel49rijoczXzuHhzPQ9wx7hRP
eTOfy1/Gz+PfkHCS8ZIHJasl+yRvSr6X6qQj4z5i2HkvLt6mL/Ol3DXQgGsDjvuevk9LyFzaSp6m
ieRlfFoirrYG0woaQmS0C7V8Kphkq6VeqZeaQCerY23QVTSTG8Enc2qYhfYG9Ap6N62Dp8huaKV9
UdOu596hDXQ0t5q/ny8lH+Hq4mUeqIachXIoJ6Uouw9gBkook9vEs295QSLn2iRTqSY6n/9GQrn3
0Q/2JJR7i1xBWshgakFuheh94MdrHWnBuB9a4Ceo+TsQdBbzJ7hFtD89innXwHLyMo5xF1xDd5HH
US7FaI/XkcFkDZcLt5IZyI3uMJk+AD46nfpQn4fDv8jtxIyW24qySaJXAc9p6Dg4TGtQ6oeIgWaR
W1FPp8JCsgAySDvZC2/TZVBEJnAvtdnbUylpayGbub6wmbTy+/n9CL1bkZOJqLlyhNtfoE6vxqe8
Dl4uGbWmGCSUfS1bix7wEtDT38gt9BqYRFZy35F1tBwGwQRuJu1NHoz8xpdz+cixnehNKqTd5SAp
kSTyBSjxb6AUtfFqAOlE/rjkdpbmPuDORGui3shoSULkGMxB7vRF77YQbakvfEos5EoyhI/SAXw0
ejlsoJv4Y1ErURMvvBdFC4tsIyUkKSqQGVEVGYIafiX73Rm/kL+Ln83fgnNTK3rNu+F+eBhewdnk
SZy3UpCPlyA3R6HvmYRzRA7kQSGOrhR6oVfqh2WD4XL0p3XoJa+Ca2EGet5HYCNsxhlqAPLjSrzv
KpiM+TNxhroZbkX7nw+L0Ac8CE/Be3Q9XYsr3Hvoa/R6Ogk+hU+5N7gwuRwO8/fy8+AyXAEPIUZ8
cjeUkgfvWxT9AJ+WBk70/gVopaj30R+iH0afaT+I7T2Ffb9f2gt+kFZ0msL0vye69K+Ea3ngfvwr
8cX/Q3oJdX0yyi0nTn/+Z5Lf+v+NFNf/z0l1HYAG10cJeL/2UwC9DReTswBMSQAWTFt+BbCeBnAi
ZnG+BeBeBCDcD+DLAvB/DxDAsaUUAaR9DRDEvIw1AFlXAeSpAQr7A3RbCVB8CKB7W4xCV12k/2N0
mv2u9SJdpIt0kS7SRbpIF+kiXaSLdJEu0kW6SBfpIv1fQOwfcwEJnsCBDHpvlsqaiXor5kp4luBA
KZVgYjvHUYdCxvK2E7DLB91sC16qO1MysL3kUt3ZkoG69hIoK2kvYZSb49V79QEMCPDQJnB728Ls
s3+B38t+jbcreiuvl/SCPjCA9ArnDzYOdq01rXVuMm1ybHLK+kDf5EC/8nC3jMyikf3CxsJ+23ND
uZQM8Cf1lysMiS7jyP7N0b1NvkIxSopFiWIUrrQW9t9u1VglDaSyIZzWkCk0JJGRA2Bk3/DIbmUj
i0u7FfQtGFBgUI7UK0bqSw3h9AcLDGFfoSFs6YEJbeFoAzE008HhzIFZIwszRxYFRvZLGtm/sLSo
oF/B4P6kf4HROdK01NZgo66Rg01LTQ0mzlRqZI9WYVM641Jjg5Ez7qa/wCXwCxkCtqDuTG3wx9qW
Wl0Lps6c+RHj2In5ePwoJs+caevIPhk7ITtb184qtJewQyeGYl7XjNwcUku4/DyL2ST1+zmp1J+S
XFho7Eh1M/p9yYUFRfn55xJFRflWi1nGdUnFbvf6uXxOMDzmdjjcT3upVa+3e18SqE1nsBNhE8vd
ZljjcTg8j3vjmS+KtRzEu4WVRv71ovElejLyh9VotEYy3DZe69CSd8+lWD6Ri+HhRDuvs+kieedS
4l1/sJ9s1kbauE38N+CEweGUNHW6jkqsCUalwSKVSnRWi9FcapQMVCiMDQlJADpUKLvrrZ1EAjZi
v4vpZO3A9jMljJOokGUlekP37oQFIq8KDIZuReKAZVJqNhms4tB9Kck0mdaWrE9RJxjssmuvvPJa
md2QoA48Eya/ziSUDPWrbHql+q1I85PrIs371Uq9XeUj/SNASGakjc6L9zZNQRUOO7U7eNZjhUFq
tegkUuytUomdxv5qwYP9dSQ+uZMM7OjvWdbfk9hhsbvn9dZEqUwqSq5bkaGwgKaIMsyzWgwWOu9v
e/vLzEg08pxPbcfe7id9n1xH+r6FvbWpfJHtrLfvRL/kCPwCGnCFlaRJruI/VtkTpu4gbhDteSD2
oiU3J9ChUqLW0OFJxYOHdGPBL4OKe1zKCP2G2BY3FttyQm5YoW2yqORNIDXsIhawA08s21Qqu911
rnH0Ei1smC3sEeS8Rxj/6YHnAm7s4G6hSxm1L+nSi+JoOgdiL2xQHdbvTTiU8LHuRMJ3utMJ/9bJ
rMZmsn5LjpZom4kjrMD+af+le9mCbswS1qgKEt7XWojlUztI472EMiKaaYuu/SToWjAZk8R53eO8
RBoXCx0WKB40uBsGQ0YReeSU2a63CdIuXX07kuMzuM1qY+xHyeXcR/xA0MMdYfdmKZErFEns34BU
KIEoWVqPaTno5SMJ6zagmypXkPWgJLtBTR8EPd0AcrK7SbqDNNMNYWU2tmk3wKDbbM3Ef1cQ7NnE
JhrAyZYW/AP7GVuLXYfBfHlWMGGubh/GNjHBBqUncUsgJG4F3CKLSm/3tZ3lFD67XmWhfcifqEp2
Y2RwZLARE+rzR3F32LdH+p76VzV3Xu+7jmqkXhwJjqhchSNho2CjiY8ErX1DWA07sqVEigMZfDMO
xNt1IO0n/4uBEBKXBiFxA+E+apslDoVTtv0eH0pEKg6FNJLG2FAIrGW/B+TvhwL4JXxlnYRoFeqg
Tpeo8DrdhT5fojM/U5vjyaE5wYKCxEwqlxQRkig32M1BvT7RnpwBabo0mhYMBBIzfP5kewEEkpIB
7JQkK+xUIS8IZAaSIUOXMTiDy2gmpeGMpCQ/kGSdLxmcgpMOdjY4DzlPOE87Jc6hekFHQFevW6o7
reN19sKzO4g8ZjW1M3CSrZ2BGsnc/pnaFvT9UFaGl4bu2e14gSmCZqX7rfYwehGi++1wCcTjjuxY
eWexyDS9N+734zODPu5o8r16k8jPQpzARXZazB05ZA0RRF/vZOGMGW6HVuXmHrEZjLb2uSTTZjTY
WJoWRjzWWNrKfY+eXaOMHGd3vBMZMFq8/ycWjmbatARlUIIy8MN94XQUQCETgM/lKfL7E13I80LG
c6PdUmQwJNr9BrfTgayV25vJtO06nd6NTWAyLOhc2a4610EXr3WVuQa5Rrumu5a4NrmOu+Su7wKv
TMN5+GztjDOMV/F5of1CpvyFRfr8CxjUwZhzCbr0UzaQ9t9Z+GnkGTZo7jk2lfGlbZZzLIh8xiZO
ckPkXjH24ySwNHqcv5yrh1QoImPDQ9bLnvSsz+KSZQFPiJ9lvMFxvbPedJfjftMKxwZZg+lJx/PZ
22S7Ezabtjp2uA8knMk1K4mdpBPuYf0DDnpz1oKs1VnrEzZkvZZ7JPdUrjzV10yfDzsC2d5AwOf1
pRoSjda0Ii8UpSFcUCsyiprJifAV5J5UUOZ7OZXCy/R0OuppWkitTjWt0XkTZaxAA4LgDWssZVov
yfaWeQd5R3vXejd593iPe+VeR7F1SY5XysqnSddK90iPS3mpvVv6LjTjjNhcTIID279mk9wMEmRg
UfT+Lai5Ldm1mCorOdOC053BGpv1DN313UHX3hPLbSiGM2jeMKDRftmAxqQhV1TvAVn0DyiInoZC
JHv0zBaDPEteLB41UDsDq6qwqgmr7gI3VjFG97KSGbWk1lsojUOgPIu1sCDZ7+ucWWOAoEPaXLJY
ZjZZ8vOKunHVLxx6aP2Jj3rcM6i+fuxmQaGzKhPGrRm8tmk6k+RroTv7vXD1pTdcN3XXuJseXjVt
znat7p6qq7orbQa9UutIf2Rc+2GmBeRxvW5QaOglE0eMZgg4E2U/AjGDC1JJ0maNkclKpcs26XRG
k0/jsrBroz3bbLdbzD6XW8YRlZCsrlU1k3Hbkr0KwYs6Py6czrkQtMsUqkSvFjlPpY50/zBQC2ZT
WKso05qmmY4jOrWnXXlfV3EwIZwUUQfOxGVlJXbdSRvOyvaTtpNMAkhd+f9XYajjwggPm6wgOaqc
pD6pl6eOT33Wty7pBbJDtdu9PWWf5ID8MH9MflLyvVxv4XNJnqSnqoIMUvVzX06GS2pltarx5CrJ
NarZ9Gblze6bPPe6d3pe9G0LWEhz9HSTSpfaHP1+s9vC5MqEN6OG6FFGYDYBTlJm/3kOqyifMGnG
BUbSV37UTKSR37cdW/5ah49yuLlHP73//k8Z8d+0f/B65LdX9kVOv76OGSdfyrxW25trP/tsLRJ6
pA0onQFomelweptXqdKWmZujZ8MZmHjDfCzwScoJzwnvD4HvU2RJ5hRLpTAwMDBluFAbuCJlsnay
fVLgXrva0hz9NTzTaKoxXm6eErgq5axDInXYdWYHThiGgGOBbrXuQdsKxzrzOqzrTzbotXaTkwAn
T7C7rFoNcHoV3KP3pslUW3ip63Gr169KCMlrGjxkqWevh3ocGSZvMhNyQzLRJnuSlyZzyfbgvi5y
Rmsb2CKa3cAzDHExU2tBAVuZgAmLmazZBQp1Rm1xMUE+B4Mk7u/NIr5JST7H2E7U7PdBYQHk53Gv
MU9PrEa9lUo3PbDrlQ/Xjz0w1KzTWyc88eaBSCtRHXiZ07iYlbzkcVidfeq/f+iJw30Hm6z6YK8p
hHvjAFEzW7gVub2BfZ2K/P5ie7/0ielUTpkBJICESLKJREKJT+62sSydM9vqdNqsPrfS4ktV1CrR
DLakepHfaA6Cz2tyg1plkrEP7a0ehVDPvtskxJER8NbriK6ZLNoSTK+PMUl3dkacP+0lsQm1DGfS
lpP4d4bZwT8YQS2zggGNlrgRbEmQG+TMxZyzix2QHv2xSTCl7ERflRz9ZotfnmTv9FGdk4pf9EdM
fxle6VBlYxdV5mnMxdz/xXXv3XTTezOPPSheT/94xYMff/zgio/5b1qnMt/y9Js3nbjhxuNz3iSf
xjS54dixBqbJFOqRt9moyXYQ4FB4ktKyykzzaC86lI6jr9PXjW/ZPzV8aj/m/Mp2yvOnRWN3pbsK
aLG7v/MSzyjnFZ5pzms8tzoXOVe5VrlfkGhnW3a69nH7DPtd+91S+Wt6hyDgikKf6LXKeK9epR7m
CDUAmY4W1ExOha0+IURCDSYyzbTHdBBdEW+ye9M3dlHRgS0tTAAtJ8U5ARmMc7Ku5Twn02QxSdEl
bHWaPG7aHP2x09UT/PNazlPMTs0Emai3Mj6z7RnLqWevfLfcmIBLzJzfbvs4cpxo33yXKEfYjyxf
fthBHnnijdJ8rV2v1+WNIM79L6Dn+NdtC5/fuJghk48QmVyBmlkAB8KBsHqwpF5yh/q23AZ1k3pr
8JXg4aDSKkfA8qZO51MUZEEuyW2m/Hb2gRLClmYSDjsIam5Sqg8CtWneRACDYM/KtEkVcqUPdTGs
LIIMIjgOiqq5IqzJNofN082HzLzZXjib/SPAMfg38ExtCdPRr0XYUsL2WNpPirMlnIf2as/Bvtyc
ipvCCelBJwo0wwNBZ5qHsA/Hb7vtH3EfJuJry44VMVNEc7wuzSaiH22fxsID21m4feN9N8zPN9tM
cuNDE6+9gdwrOlpNe58O2EN3MH2cN3mNRW4xGKyc9ZqqeSyHWf3cyK38raiZKZBP3OHcKtN0Ez3m
/SDwo/dkoNV7Jkk6JW1q5rjscflzNLekzchflFaf/0jasvwNaQ35O90JVM68wVjRQSgkErnCR8Ed
zLUJOquAskxwL8/1CsqgF5Yny+QhiosLkpooEEGp1CkaFI0KTqsYpBit2KQ4qJAoHIVZ3nr/Un+D
v9HP7/Ef9J/wn/bzfntB+pjzlFX0FmwJi8JAd9FSdpK51DK209ByvseovWCq3AXO6BlwRM80pcvz
mqN/NLnl0IxXGfIcFqWp81lmpiUbp73iLkcMuZDCDpehN8kSaHwNmm9lql/IvAgtLDDk53V1Hdxt
sbkvyTZ91EARav/S/4YUy/wjz7W2Pndk/oHFi996a/HiA/TNh0WPsWNYr4wrUxG12sgl/dLL23YQ
sm0bgciAB95+Z/kD77yDtjAcbWEq2kIxGRHOXOVoFShPzGS8dLZ0KXmANpAnaSPZQpXrpE/Jtkq2
yV6XfSw77pA55Hqr6Le1Jo+JmkbZTCarzadPyxYBT8aonIyM7Bxfmk4Z8/caohml0GiUCp8uhl9V
gVFx/Fqcx679hdm5hYV5ub5iIqS5vHxaaiqKuxh4mU4pVwj24zaC88QTYVUP8Aq5e3IO4tqtmfyw
pXufMR1en9mSTrSouMtnZ4v+Hx3+hd7/PxSJVqdzOCUyacApsXuIQ+aK2R0aHqqDoXOGkEbPbBPU
HlMM4tSQWiZoPZsJLOeAaKd9xsCq7C/5HfBn6ODlI8feO+pKj93uifzM5ogr75g9qjz7mq5LLdF8
Efy0juhTtWRQ+++dRsqNnJMp3ND+Y0dGDA8xG30RZW6R6IFDnDovnO6z59nD9qH2cfZZ9jvtMqNG
V21CtCpVK6olEp/a4rKvMCNa5V6jzeSB7S6pRo3r/11ktPhv4Z8IJ/C8RDAPMhGTPXHIvJhrY1gU
V2Ti1nHZ2ZYLFq/QdbVq9hcaL/Bc3g4O0KW3zCP92cDbbWyYpP9vuEz0SPSffBIZ0vZrF3+EiIWN
bGvkVq5YHFkirA0HdYAumOq4kdoaF2I41yxtPdSTelrPrdAmXCpfIl8r3+Da6ZK45M6daMgutFmJ
St5MntvO8z5VbMDhBJXUMcwuGIwJluVutigdHdZTynFuj1ojJCYO4glvd+8k28h70DF4HLqeTXsd
i9L2k2Vn2zsHDQjKinGaYyPvHLFJKuscvySvqJAev+W2iMbtsHton+rqnsMiv4kMUEy5k42+vU20
73FTlmZ6RPNedDXa8h6U63K05UL6wA5Ii+7dYtGUpTVjbFKLcXiQQVV2tfEpI91XQNJN6YGstPSC
1MLuSWWBnmllBZNNk/2qq4zEbywy0qBpUNongU8Kfgz8WNAaaC2Q9wj0KJicNLlwg2mDX5pU6Mel
ruisVZ2e2sVMeyt4iMfDHqrWlbE4rEN87Rnl93h8fp/LD5n5ok/IyeldkJOTX+DLLCjUq8SGErKV
CQkqpU/vNIvrJK3NY6M22yqTzWY2+ZwmY0Yyy++TljYqkJaWHPBlBJICSUlCYYGpsLDAbzIajAL4
TQB+MBYmmSR+4gu5XOaQU5ocysgPZWZmZFBVyKAHeYhQpYktlBXT/MT/cCBpeOFO0gABzNFML6gv
oEJBTkFdAVfAfE5iNyPO8DjHTFfUK6hOIShyMMFmG6nCXrSLPML+1xIy/q7OLR0GO1my5Qx7F8B2
f3E13BLzRzqcWthOBAPq8/msYAX7RaQxeniLu6TM2Iyxq1sstufFYmumGDeZUstivzerIfMlc/fN
T8iyBSVzdftsIO/0Vb9ko+fqevkXt/bPddGX/aW6LEEnvonoioH9iIFN8sDO6K+4Xj8b83Izahlw
wxpYa3C81h9bAvYCIeYEZwBbggSJ/sIFXr6exFNxB+An5AJnSMjuLsu918iEoGgHGuYUxkSaydox
LBU5zXJDkYfI9ZEFXRZ/f5IM5hpYOvJTpKbDYZCZaC270FpMaC02qA0XjDXPNN9hRvigrmaoD3Fe
NcN4Bpt5hV7vswFCOyCCXqcbpNuj43R2e1dPx5zcf/Bw/+jdlp3v235lvq0D/Hf12ATM2Nc9iKp6
U2m4RNtNW5zQXdtDW6LtqQ1rK7RVCkOyuki91dmUwaeQIkKHu8bKxrpmyWa5JEWyPFeVrMo1XCbJ
kXfrKdre8R6kR+/SHj16lvq6mbUsyy0YyGDDIcMJw2kDDwadIWzgDL0TDAZtgs8c8IhTPfh0Purr
7fb5PG5foCgnlpmvy6f5vbPz83OyfUW9wyxzwvEKUtG7rKIiXObLzJa6k7MyUxNdUiJL7xYOQW9p
updzeBUKTtatqCgQMCs1CYLVEvYU5ljqLdTSlpzoFlKS2XVyfTJNbiuFbKGslG1FQeme0oOlXKm9
T/pzti67HuyNW0lnhNJgthbDb2h4+vgelKE7/MN8/x+vamf8LRwQUtNsdqWal6gCaXyKh0ikdqXV
Q1Il6R5iUzsYPEB8oCthEAFBQm0t4gRn3IrKlaCM/gQ8kiz6KYKGT4FEP+hAhmSG6BRkzH87SqXN
sZiwl6EYg+gCao1mcb9LXGOeQxZ+EVKcQxT+CyHGhQb47ZRrysd6i2f2GFnUpw/TwtWX5mddVd5b
TA7KzczoWSFmf8mCWA1u7PCZVb17V4UuuaJ9G9NU+lB4WNWE9g/E9LKKEYlp42MX55YKqMHXoAaP
QA0uJteEux2RHpHTfdJ9cvqEvEnaJOdmyOpldJxsvHy8k1vtXCelN3u2kK2Uc3kmeygQnlI32mIM
cZo9ZmrubTebbXaf4ULEGZtKEiCBJPSOzyYxxKmDgC5AL4CdmsLeMdiZFyqWkp3kBAhkXNiY6OVl
iEANBr1SoRQcx+3EziYCnQg+l+Y0IPi0M+R5DurEcWdM8drPoJP/b3Dmf4E6TU6XRC6TS+VU6pKg
VjnliTHkmS4izw6NavKYUEE+3+w0xXRoBttcm1Fbi/CqKL72+4sKnK8qfwGfI6rvq6kbVDxSFPoX
zE/1vn3qZXNmdMWecYWYV1OZ5l7Yr/3nc9iz5uaKu9p/uUALKCyLHudLUAtUYCV9w8UGC28xWS3c
frJfdYQelXwmO6KSTpFN0tMJdAI/ST5JOVlzjX6C8Sqr3OzltF4Fp1LI1F5gNqG1l4lxglWMwxpz
YSP7T1VyoA7hXzOdH7YZvNIwVpOGsc406R7pQekJ6WmpRNpMvtxiQxfSsXLAyamlvXYGw/Ns65T5
DXGZp+pc5lkQHZqiZ7bqTAkm687olzhlf7lF49a7z63oatk0yEw3rLKYdM4yEwv0bIPRqHWXqUwY
yJUYyFiA+T+GExGNyUwqAxZiYDHpraUmFhhNWhOrsS9swIRSiUBKzgLKaT0l7Efi5x81hO2eduyQ
dN1nKom0vLIv8hMx7HuFGId/0dDwBSOyaW/kNNHv2Uv0kdMvP/r58UfWnDjO9q5x5c4sNAC5JDNc
lqvUdk9BKswcQobTWs14gjKRTtHMIjenX5elelW6V/mJ7BPFpymf5H4tPaWU27kM7mbZIm4Vt5GT
WlyiWdqzE+12V6LPEptlVIY3z5tSyn3Z8dmEaNKytSGzK4SKmpDtVSnTvGQ5LwNPKCBN9mrlRO7I
z4AEwa1NHJQ4OnFaIp9oz+u6/S3Cro7N75YScQn/dyv4f7a4C5b2TanqHLYmyESpBxHoEyb13Ohn
m1P8nTIXJc42V83xFZ64jf2PFnXebvaAjbNveX9mpP3FLxa9LVrUtC6b2o98sHLV4cOrHjrMjV01
ctSsg9dti0RfiEiZOYmvoEIioJm07OChpcsOHWT7gSi79Sg7P2STS3ZAMHq2Sds9jSlfsbb78/C0
8/kANxRGO8bDtY7J3plwi+P6rDtgsePurFXJazIeyno2eWPGU1n6J/1kddoGYUMaF8P2CV03YmL+
V2V+M+56Y652KHO1HcAdHCmZtpCBgeyETK9LqWB7NCleWO6TJRG7wi7UK4lWeUJ5WskpHbnp3nrP
Uk+Dp9HDH/Sc8Jz2cB57Tsc2bte9mYHszSi6VxRqe0mZCKb/ujHzHz1pV8E6TLAz+iNkI5ANmDLQ
EJtSTcFmlGzaBZKN7Zt3TqUXijW2LZl0wQbNxtfEvVxxRzcyXdxUW/jl7kg74V46sfDwypWHGdH9
q5gEW1/rkCj58wVCtm2PRgYsO3hw2bJDh9jbCrZLyd0AQfgzbLolgWQoBiknG24y3Gt4UPqIUeaK
baR43oyvrJzmnfR5XIiEw4r4gikYYDUGpV6alJoaSPIFVQkm8d99lMg0xAimBJ0yKRCCoFRZpsMJ
D9dJbLnkVGplp2VU5sgEk5Ck9Q/2x7bQTvulfntG+33nJr1LdV/X4pQ3MLaoaWEvXlEosVdNDHF1
7/7PpvZXu9PHxbPNaEqwGFwdUChuWuLOZfy1heyf9jkpffKJqgG32Y3KBKO/wN5t9R4yS8TXU9ky
+sBqFnJjDz8wfILDaJcZ/Y7qDZECUQIGvZXu7sDaB6PHuQjaUiX5JXyPqcxVTg2XQA1MqtwobOz2
WPHbxv29Pjd+aPmw9GivH4wnC77t1WY8U/BHL4PKKLVIShW9PEazxVzq7LXQt6Jgl1Y1wnhF8aTi
yaE5xbeG7i2+N7TO1GRS3hfa5qFD5ME0f3JuuGdJgcOmTZCZ1d2hIC/Hz2cVaRPUnBI4vT3Us6dX
761QNpPCrZyQRbKayYNhV3KR1wsh2fDu3kHu0e5pbs7t6J07zB9KM3vDbC604KwXrpmWRtLsVRUy
Tpqs9KqujBsW2x0rI7H9ZxJkn8PEvlRqbwEmSfY5W7u+e3b85W0neBbfL3Vnb5UQlRR362UQXAFj
wFpq9kDI2d1DugkYGHrhpaXM5gGrrbRnj8QSBCyOUEmxp8gDpnK9CIoZRIoFJDZ/iUCmQ/xbQ6YC
pWt39Buwoo1WonGWmrqhjW7xWUpc5/ZP2ZpyRq2Ik4txJlXg4iBkwqCYzas2nRmvMKhkE2mlCafO
SpNKW+Zi7SBnWKUXGHwwsaDLRIpzePwtWVzdUuJvjK0Wdsb3z02xT4TiL9SwjNl9YUFKclJy7DU0
d0tszcnenxUPnb/40lDvnLs3VY4Z/e4bb8yTmzXM5A12q3/VtCcbhgyNvHHPJYeXP88FE1FVl7od
FntJSnH3YGFJqktrtPlv6Tvl6Qk+U4LD/RzqrznLk1M2p/LS7GyhYGLJNfOYvt6PmCrE3w8ZsD+c
1OokGqfDSZ9UblO+ovxAeVIpuT7h7oQVCU8lvK76UCW1yomM+QmeXBc2y3leJvcRnUlh1rP/LMEk
savTmskTYb07lJQkCxECUrXXrjLdwzeTZ8OmjAy5Qkj2vg4unUtwTXftcUlwnj+1JZMtx1CJToqv
M86Ir31w7i3RtbfEXkgyDbrA5Nl7DIdTqVI5FB5QOtUeiL3HEF8L15IOE9ebLnwVlFx4/nsNixmB
+5viFFo8e8bw17uZNDqbRvh9xvLnV4vLGCYMbiyz7vb3+o3NFzR2vVbjHbhgNs1mmX+wSoyPI5GP
NdxYSIFoWK3kt1loqoU45FqF6GfV2XK1WiH3aWMvLFXOS+MvLFO87DoTkkhSbyEpySv4UohFaxK8
IUhRWm0hj9utlStCOq3U5OVUggBgtbDVhCJNpxfkB2VExjayUy/cyC4piX1QVyJ+CBT//va/nvQ6
9qwNRl4qCRh5vQcMUlOMxzGDM8YN7kUwo6FZENwYol/G38GJn1SkdGG0KIVu5y47vqi4e+ObN4cv
i+3MTLz0nQ0iw38WVwU3r6monk3dItsXD528O5aM7dkybofYv16E3PaT0eHcDWSDYaORE5SCSlAL
GiFB0Aq42gqRYkMP41X0av0k0yT/Jqy03mgIe4hSx1hu1oBGp8nWcJpL9RqNTu9T6g2xSRFH6yFd
thwVnAhmpNJRVCrlqE9BSWyLscwW22O8tHOLUU8JEQx6E679TH4AwWgyGY0mo4GAMr6Z6NSFlFxI
qZD6Q6ZmMjmsMtJQtr5Mv0nP6XeSyWAkirAmbCA5hmmGBsMhA294kWwC9g+Je2PbhAzYfH2mtkV3
RtwaZHbC/spKsrPnS7KC8+fum59lY9F5W3u1F+7tnX95YTG7zs0Rd+a8/r9ssuVfmEMb74s8fbm4
DRVi4UJSECBZi8SMEvb6YTinEb8BY+LsE1vOdcyXxdEo/wBKMpXLCK9LtaRY7+bWW9ZZm+kOy1ar
HKiOzrMssWyyvGQ5bolY5A20kR6knJyXm228zZxK0/hUc4q1mC829+X7mkfwI0zV5mp7depVZAo/
0Xy19Wr71ak38zeaV1oetD5FN/DPmBus2+guvtncaH3B/kLqfssb1qOWw9bvLCetQZXFaQnSoCVo
nW+fn7rRssvyuuR10zHLt+Rb6x+01fKHVR/7KidB1/lZjsnsTWFZGdOTCCQJSeEk7jRLNSQdSuKm
J9UnUV3S4CSalLQqNSkpJdXnTQW1lN2QNloxT7GEvXT0KAYpuJ8VZJNij+I4yyAKxSqJQiGV+NQS
XnCIWpmYmG1PTHTYfYLdtoJarEJztH84z8xzgknC84LZZMKJJxWVzmZHfbSL/4WqYLNi2sr+Q1VO
MFuwhoXuISdw+TwLtekE2xokJ8J+HoYRwg3jlSkhryMkGEMaaUjtFQSNRi2dZiO2V+2EvZhOhuX2
cE6hPZwaLLCHAykYJLoxsDsw0OoL7KFwXSpJ3UWexjWFlSwMWy3DaTi3ewFl9SirR8M6fQFtJk+H
NRKhzkzMr5r45aaQhG1P5RSyaEtx9wLxMhi7xMeIMbYgxni/GGNjLA4bLNYCSdhcOE+yREJBMkhC
JS+SLyGti8Wcra3tnKVbTtp1J2sd8W/obV/bde21DltLrPDM16wQbGUlHdvtIjo9U6I7yRLtLczC
5OwzUwnaWGeCxTGbCwb/84Z6be2MGX/N+2umaH3ndhC2pcrtcl53DrqQ67wyjkvhOlxq3A6Nxnyj
8YI87p6JO5onPp/GjPEbFkxZsWV885LJbLf4a4ZvUwl1tZ8kXSz0Kmpq/5E+3NVKJ7D/tQKttILO
Ca/w6D0GaijWj9BTJ9sz8fjqyFTDNO80f13Fq+RV3buGd71v+9/Oe6XglQqtHGyw0sdBHjFU6A0V
fp3Pr/MW5OcRb0GeX2fQCSTPREheQYXBYBC8BSavt4CGSEgbQkdpDBlC3pAQcuSG8kJJIX8ovVeo
IlQYKgiFwhUVZcXFZX5/SlZWSlmNpKCZZG0VKh4u07EXM05CJGqv16JWS8BCLJZE8rBWMg1Vw1GV
h+Vb/A+nGMR63odTarSJ2fFtAUmivVKpdCjTpSHp1zuJDPXnfMh7svODY4Z67QNP2lBitYh37Ujs
nR0rPeloselOskyWEY8dYNO14HFBIJkff4ljiL7FXtoY4i9tMN64xZTK4rNbDH4Wf8n2qjD+vMlZ
UhqHnHFvz7aN/LoivF+XgTfrwninTom36dx4j86N0Fbn67xLvE2LR9zDxzaM86NfhhUGVZnerTKU
5ePjwv0xoVdarKV6nBpLK8rdhjLCgopuLn0ZYUFFN6cOUxhUmOzaMsICrzJRKC3QYpBnsjtLdQxJ
5zHojLEhHlc0R/dt0ZnYrvS+sAYT/hIMvCwgf/1nL6ETXpM8ywVvd85bVRdhRuzbqU7tJ+Q8c5D6
aQO5LdmkxdX1r0z5F0Z2RHaJE1XkZ7dDa0wmt0XWJxmx/BSbt8YTJ0kcz0zlFCtNIq9Flsgsmvhr
oO6RN2JblBqLDNeafeViCdtb+ZnoY9ajtsjRelZEbuVXovXkkd0IGsBmsPmCGq+1kBTqB2nC1lbj
v30qhXGAsb9vIpmov9F4o+8e4z2+HfoXjTt9r/s+8iWgCRryDPo8Ywy7uDWa7E7Q4vS5693Evcrn
dvt8Tp8/mMveo2bliKs9a1iVl5WVm+cL5hkVsc/nJJJVsY/nFAQcJnFqseZYiTXbaLWajD6HMS89
ieVOTUnJ9qekJPl96X6fMS9P8PtMfr9Pj2bKvuI3GIHkYYFBT0DulhgUDOI4naaQw4GWSxnESQql
54aCwfQEcA920+nuE+7TbK1ZMFhCQKKTCJLpkhOS0xKpxJ6fvlP01uLOzcnaGbqv0c11bA50ATnx
bxTZ1/6SuNf937zE/G+BT8el7sLaMrmuRF4imoo3rkz/Qb0ueP/opddE5tjdDo3Z8rW4QUdGkKEi
4D3lcehMWe0/3iHqnkuESjL0wQaNWSE64UF0c0yFULnO7fQwX9wCwP2E2mSF78LKBLa1S+QJSvpi
9Cxoon+AEni2wpBlczIZz/mUFlFlKo3ZWqNRp/VZEgg1UEGTYNJoEjRqmkAsGqomCVoBrIhuBZVa
SWr5kFZZppzG9tnsltppaqK222Z32VobGP9S+GTnb/vi34+yNT66NCK6FBp7EU3ZdI1uSYzRM2H8
cRP6pQ5XhIyOMRzYyuO8C2Q7W7CTIDGTjt8cyLyFxGuO//CA+7B9IS0Wv2FoB3pd+9nYcm1Ae89Z
jKVvDqCvXMcSb7Dfp0TayTr+G8iFlduOGI74qAyd6QvuQovP5StwYzpswoTfl5SlN+g4rSRjZLgM
l2XN1LYNBPnIsBZTYS8IDkg5nKU+zEuSENsfdmRnJXm9wmFw6BzUYc/7cweZ2/mFnvgJhxiyn+7Z
s7MReNgcLXaMajEm8Q9v2ce27H3fDKOFvY4zifsF8c/tCvUFbOcKB9+tqAgvOtayuJplP794LM9g
7ZXrUWoc9kGFfXrluywWV0H5jcNsDo1CyCtPJb8m+zJLI6u695NwCjV6rbyqcWRitwE8ZzEZLRw/
oBuZeOVcm8GgVnKS/t0iK8sGir/libTFeXUkbEz3kTm+t3zf+7j1PuLKCGQW2HCaCidgItGHgYcF
VhGsZRaYkZEstjCGejHhZjfwBpOBiqzVStwDLQNBkCF32c+vRO4GR4YZn8OJMe7GWeroZDL6Y2Tu
brod8skucgDE/YI4X2PRX5mLcQvjcAeDOzEgQqjrSHIHZzt/OxfjO2N7nLWdPwMQ2U74fD1yWlBo
7PbBBX0q8p1Wq7Og142X2e1qZQenM0rJxOL+PKfQGAy2/MrxkZUip40mkdORlchpo0H9v2q71tg4
qit8Z1/ep727fpBAYi7GgiRK/EhMnFhC2MQxsUKcNPbG4Kayxruz3iG7O8vMrBdLtImqqkra/gCk
SBW/6A8qYlpBRVu1VSseRW3V9mdBAlqpRdCq/yghqfKye865d3Zn1k6Alq49M9+c+e6553XvXD92
J+IPQtgXH5jC/zl6xfe+/18Q6QhrZ+OjW2O+O3w+f0JpSa1Fo0r8y+0xO3qx/d1OWLBfjPzMd/En
HQrL/lK8Ie0y/ofIJ/jWOXqzT0q8OxDWgLJ2GuiVd1+MdHdt2fxtOG7t2ro58I/VL90W7+zepvxF
ArDkPd/7gc3SkgdGk+G0EmhFI6J27GLq9Th0PtrWyWzlYsvrvnfBjN++KN8Xh/+pchl2bjP21N97
1UBPvbP63qbuzu6I7+Q7q3/evLWrOwqG3L2tuyNxm/KSBOIzESfoCXF+wqvySWdYl12w3BTYx1qV
R5jzBPg5YiEOuDj43s+8xCG2RfmaxC3s+8qzEofZPb4/ShxhW8KfSBz1dUccPTFWjPVJHGf5mNM2
Efqxb1TiVnYy3njA6On4SYkVFot/ILGPtSTCEvvZrvh7EgdcnCCLJ9okDrHWxB0St7DpxHaJw6w9
8YbEEdaafFviqNKWdPTE2N7URYnjbE/aaZvwzyWelLiV9aVPgiVKwA+2xdPfIhwEnEw/SzhE8hXC
LST/KeEw4d8QjsgcCSxyJLDIkcAiRwIHXByRI4FFjgQWORJY5EhgkSOBRY4EFjkSWORIYJEjgUWO
EEdd/sbIl7cJx13yVsJ/J4xvJ25NXybcDjjdHiDc4eJ3kh6Bu1zyzdi2vYvwHcQROre6OHe6cC/x
ewnvILyb8C7C5EvYZX/Y1VfcJY87vsywZVaBn+DyTGVZOHJ2AbYZViB8hBmsDJstWZwdgDMTMO5V
kOvE4CApQvs+QOMkV/9HTf11yzibhitFemqg4Fggm4Sj6G+Q7YevAbZLoiGSjkGLIhyPQ5tFsMGm
VsdBnwWbyZZgn1tn1QhZVYXrOrE4m4JjDeRLdG7VrdwNveyDPWfbQIsOtphwxYItD9q2U0+LoKkI
vpnsxE1ae3sTfR0Df/GT0z3X7uqhWGKkcnBeIq2nQIb9/fdR5iBFO3WwzSYbMCoczpGTJQnm0jlH
i8ogEVZZ4MUUOwq9T7IJ2A5A1BEfBSmH/QTsHyY5fub5NOwxLw9BbA7SJ4KjdIYlYFGKG/qgU5bs
dTXpyIWXFYp1RVq3XI/Ceu9FDRngIXpfgfbIVoElvBRVUaWa4PT55Bw29NLpE31eckWmSm1FbTj2
iMiViC8sweovUlVoVK8ayRZJC2ZPoyhinT4qeyvA9SXiGWCHE3PRp32LyDgVV6OKQIlGfhWkjTk4
Q3kWZEXyL0/RK20YL0P6hRHTXFpqUudG/eVk9WBNLNAoFVYvyMyUpeaNMnQveeWNlKir9VWxvmch
x1gvwR5nCBV6LcpoW6TNvmnfGP0MSIrUo+XKfCMXIk/ecYHREb1apCcL0jx58FlyzmUtlmksluGs
0S+O7RxFWoxSlWYw0zWD7ayzTVfdCv/sT40UWlci/U5dGR59Ncr/Kcqme67Iy7poMA3gilmkShFH
/YW6P8Iud3XjfIXVIOIvRlVF1odTpc01dCuPGvUxSb6vzxxGGPU/DnKNdDveZOko5rZyUw7Mpng3
NKN/Bs3nOTlrLtEcWHPNA58l+44+MSZxrC7JbDTGmKNvfR5FtIQHNs0B9obj2MmY2hTr/OeythHl
9T1kKcI4yrV1Fgl/sIJG6hoyMP+PgXQXwzvmPrhLD8NdksN+EM7wk9mHYBtguIbLsMOSOQBXB+kJ
DAIPsz2wYau97D641+OG2jFbNlg2AuuGfogXfvWBH80jPksz3yGqX4wp2nmYZgmb5gETVi8a3acX
67OvWp9lHD01qhFbzo2NudiJ+iR7ECKGY7V5NVGT2pyZE2eCmowjZmiMZLqM7QRgsepZrPfl7gFX
RhrZnZVjJ0tVo7nuz5y0OrbrlLciadLZE9LDCnmTpdrLufzfSSPXiaEzk4u1QI1qV4yTxh3VovXO
gsuKPGusJpxxV5H3Ppx/Lc9chLUn1kzODLBRxA2KSoX2jZiYpNmgNYGYKW2yxVmDNea3hr02xa5A
84ATmRywstDKGQWNmbDvc9ZZP/Hx+df9sLdpRket/bRWmJfrKac6yuRnX73NF9tXjSpFcLUvpBfn
Wn/TTFLXPbNc0fJqVuMX+ExB40eMsmGDiB8wzIphqrZulHmlmO3j46qtfgqpH5XxaaNYRYnFJ8vQ
bnD//oFdsBvq42PFIj+uLxZsix/XLM1c0nKOqpEDRtXUNZNPabWRJc20UOXuvn27+bYjetY0LCNv
bz+uLVaLqnnCdVk2g1bHpo/MyLMVPmOqOa2kmqe4kb+lydzUFnXL1kwtx/Uyz2qmreLRqJZtUGX1
TR2dmZyYPDA2M3l0ih+d4A9PHjg4NX2Qjz10/ODBIwenZhLRRHSmoFvcdiKJGLqsmEYF1C2jCfXu
IULGoqlWCstcLUOXEIqqpfGFZb5sVLFl1lgiY6rlHEQD9YBxJQuVqLyoZ7Uy0NVFU9NKWtnu449C
s4K6pHFjAS2HlrbHGAxcTTU1rumgzOQ53dSydnGZ502j1LDLgL6MRY0oNWA22uUgPKa+ULVBNZhp
lDW3Q/dajlEQq3oo6o0Bq3xJLVbVhSKYbVma7W7dxzPlomZZ5Dx5AT7JXNgGNLUqWlbP69n1nnOI
YtnWy4vUVs3ldEypWuQmFdhOFJsUW+jPbjaqqJd0dAg6IV7NME9ZtqiKPMSChEYNSqS6UNStAvYD
ukS4S+oyB/shVZVlDFwjQt6OKB6T+YZzanmZP17VLOoma5Sh2srSA1PaTWSrYFSLOSjNJV2rUQ2s
dx95kElNh0EkMoa8uo9gFnRgq1m7kWN0TJVW5zdWSybXG2TVMl/QHEXQj2qPICEzPcZ38W37hoa3
8+HBfbsGhgYGIpHMYRAODA4ODcF+eM8wH9573/779ieiBduujPT312q1vpKT+KxROmSApTl+WLPt
omaOa5a+iOWrYskgp2ZCikxOVYymTz54ZCd3poka0LA4TRWSBGU5ljN1sHbChKlnEVuJBnxaK0K5
m1BBMN/geOZ8DLXrWSiVvP4EdFjR7WyB56j/nZwsxCKHWaCmYU5ooFpFdYFU5GmawNxVYPTxjCWq
SCvBzIQF0DDcqNqVqk2WmBrMOViUtrqAMxjVG+m1tWyhTMbkjGwVU0BF2HeTmPUX7FKxv2SX1ZLW
X7LmsyIcZa3Wh1c+Y6uaVgSp9ulN8KxfFgmx2RTdnUt0Fy7TOhnWREoC7iiPwfk/6X7kXJ+m+zLe
w2kV53/W/yP/r/yvwvZz/y/8P3DpUunu5Jz/jXRrnr40jzbSF+gODAYOBx4K3A/7/cBW6SfMnLwn
FpSXle/5Gf3kMAZ8U/5WRMXHdfoVxe97LuBjfl+e9rWgogT8L4T8LODPZEbp+JXqayG/EgyceW20
BY8Dvw63BFgwMDc3dyzsV0IgiIcDLISCOQLz8DrXc+iZ3hV89f/h4+uv0um5ntEV8Xpu9q1LX52f
feujWECJhJ6iVzzEIqETzz8mvuls9tJp8T3jeyE4uuMMHVjG9RrN3Ji9NP/WaTq8lmhhsZYZFjzG
OpkCx9E2Eqy4XmdItGP2yvyHp8+v0uFMskWJh+9OfufBwfCb8pAMs3g4s+L9EsI171eqRUk0Ne5J
hVliXeuMkDa3P/t0T++hc+me8QY4k1n/YjvOn/5w/srsamatDs6kI0oi2jN+6Ol07/i5lAuMpuEn
mejK+bkLmXW7Y3Qtc/rS7Nq63UcdEaUtuoFJAEY7oqwtmnns+RMrG+3E1Q21wu7sNyZ6UpvOji/c
lWqGyQ28dV7Hdrx6fWXt4xfXfv/SWjP86P+hszOqJOPPjEZ62ca7rjhLxjNzK7f+Fqz5tVt/n4VM
Qc7OPp3u6R2/2Qm/hSeuYbDjQub0Kug8P7v2YWbtysYnf6VH9DKWhpFfgOMmJv/O41fEBf8a4vrz
vJhiKdVAQAGJ/4ybH/CJP2gFVhF7+cEg8b/r5gd9AfEnoVXEXn4oRPyX3fyQ5IdWEXv5LS3E/x2c
bmnwgzflh8PE/8DNj/gFP3IDsZcfiSCf+t/U4Iduyo9Gib/JrT/mb6HrsRuIvfxYjPhDbv2xgORf
R+zlx+PEf9jNjwfCdD1+HbGXn0gQP+fmJyQ/cR2xl9/aSvwn3fbHgxGh/xpiL7+tjfie/CaCUaH/
GmIvP5kkvie/bZLfdg2xl59KEd+T37Zg7Kb8dJr4nvy2hgS/9SpiL7+9HfmkpG5PMhSn68mriL38
jg7ie/KbCiXoeuoqYi+/s1NR8Mjwr5t+GnEY8RCLs3STvIvkrayrSb6TcJJtbpIfJJxit9flPnJk
nuEDH4MsFFy9zpqulRFDDiPB1ausSd83Gf51dTO7t6nNDzGVrXifvHGluc2f0G3Wy4a9cgUD3s62
sfub5IcAd7AdbNTbh3IW5akIi0eu/7upD+VNwLezvey4V+7rohyMsEe8unzo45aOGGuLXbvc5L/v
DXmt1XON9PlRH/7mquht4/864HtuS7BU4uon7D9hzJLpZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9i
ago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMxMiA+PgpzdHJlYW0KeJxdkctugzAQ
Rfd8hZfpIsIPQloJISUklVj0odJ+ANhDilSMZZwFf197TBOpC1s6vnNH1zNpVZ9qPTiSvttJNuBI
P2hlYZ6uVgLp4DLohHGiBulWwluOrUlSb26W2cFY635KioKQ9MOrs7ML2RzU1MFDkr5ZBXbQF7L5
qhrPzdWYHxhBO0KTsiQKet/ppTWv7QgkRdu2Vl4f3LL1nnvF52KAcGQW08hJwWxaCbbVF0gKSikr
SUF3fFcmoNU/ndFo63r53VosF6GcHmiJlCNxgcRYpHOkE5I4RDoHEvtVe45ahcSjT0SNPyFlOZLY
I+0ypJwi7U8Ydk0l/jLe/3TEMlrFPI/ozbLYCYPQnOHjMX7nGDROWbX2jZ3CPMLebsOWV2v9nHG5
OOAw2kHDbf9mMsEVzi8hzp2cZW5kc3RyZWFtCmVuZG9iagoyMiAwIG9iago8PCAvRmlsdGVyIC9G
bGF0ZURlY29kZSAvTGVuZ3RoMSA0MjEwMCAvTGVuZ3RoIDIxNDI1ID4+CnN0cmVhbQp4nOy8eXwU
xdY3fqq6unt69plMZsk2M0lmEhIgIQmEQCQdCBGMQFjEBI2EfXMJsupVQERWFVzYBCVugKAyJAhh
07iLywUXvCioUfEiKspVRIRk5j3VkyBw9T7P83t/7x/v+2HCt09VdZ1aTp06dU73DEAAwABzQIDs
UTeNqBm3rd9SgNhDADH3j5o+1ffjoYffBShKAJC7jq0Zd9MTwo8OgHbjAcQrx91429i1b48/CDDs
DED7jPFjRox+e6mhC7a4B9FlPBbYX7W9helTiNTxN02dedOca/8OQLoCOGpvvGXUCDgUGgJQinA8
ddOImTVGgw3rEjfW99084qYx70wIHwFYkAqQOKDm1jE1TzrnxgJ0DAFYbwQ+dvr+D/cZyH3DLYW/
6jw64J8nvi5M5PSFK+r2nz3b3GLtrRuJdRUE0SrgVe4R7g+9rHD2bHigtXdr+fmPmM5L8PozFMIo
EIGCFbKgGEDqh/0KQKVWFlrQik3QILwDNWwK2BGlciJUim/CMHIMrsd7kxC9hERIYM/CNVh/Guan
IH2IFkRasP5QxBOIXEQ/RBBxHeLaVgxGFCPPPsQmbGM4b0ejX8NE+T24AvsCxArECMTD4lBYjvdW
SgUwkpdjX/diGymYXo3lj0qb4AFMr8L7lbyuRjn/ULgK77fH9EPi0EhEvg9kLANMt2C5E/t/kI8Z
aRD7n8KmRE5gOgPb7ov3FyC9BumQ1vG6tfTXnEebK5/jIp5G+czC8gcQgxBLENehfDh/NvJ5MX8f
pg04LgWpEWFmAMlYp5BeASGkHbD/Xq3zBm3eOI/zc8Lxa2P6c3CZFl8IHBOf13HEe4gDF4ztUtx3
EaZAiZCrrR+fswnRnb4HPVEuYT4v8ZvIbxyomYdwXrsRIhsNnXQQ2YTjLBK3wSrM5yAKNUwBwtbC
LcIpXINtcLu0Ah7HcqCdEKchQH+AOCkA+Si/Cmz/WsQYbPNVTR9G8zFEfkDqZd9AHLZVjZiIfe9r
kxOXDeb74LpWYN1mvmNQrvMQE1AGqxC38vFh/1lc5rjuv5Gh4WewbhP2U8aBfXo14Nyj6wrTkH8y
tkW0fqLrEKUIvD8RZfo84iXEy3wMbdD0rBVaW5tAoJsivyCNQcQh3kM8wPUNUY2o5XWwfz3W12v6
ijrDdZPrB9cN8U1NVwfzsUfnoO2FJa175ibkvw7hQaRLz8L1rUjHulw+I7nO8v3S1jbXLa7XbVTT
6Ulc78l3fJ5cpy6gD4uNMJCPQesXdauN8n2H7d7GqRCrjekR4SAs4zrL9a2NcrlwXeP7ke+JVlp+
wVzbt+6R9sifpOk66mIbbZPFebofHsE2h0oPoJ5+D/3Zp9BfeBf6i7chfRDntxPLcD7sINqwTBig
a4R2uJYDkHf1JXQVh3yQTMS+lrLNKIuD8Kgm14M0mR0korg5clwEsk/cTGdp6X+jl4I0Ru9xynHh
vf9p+f8X0I/FzTAW09+JByMRnM+DfE/I35NshK+NYnkdYg4iQ5dJVukmkQb5GrBKeLYhbmEqdBNV
yGeNUMRiQUU5BbD8GulKze4uw/bfJN/Dfbhe8+VYSBGOo23EvujHeD4gePtI+12gRxfp3KW61Ebb
9PVSynWG212kIlIP7rtdiN2IT1vxJeIr1Mebtf2LZwO3z9r5gDYacV9UXyMnzuvnPliL9P42/bxE
TzMu0U/5Ur28lPKzhdt37WzBfYrjuK9t/tw+chvHbSS3c/zsa6t/Kb2Afznajn9odvg9GNa6r9sh
shFZ2MaeVjuyW2iInMI9+q30YWS3XBTZLbwd2S2tjqyXJ0XekrZF1uK8250/Uxujtozvp7azlMuJ
n4tt56gYhLGt9uwRrS72r52jQzU7ANJtuP8mwkhs911+rvJ9KKzFfYfyxPbmso1wI/sKluHYLcKW
aDkbDP25TWTTMY3laNP5fYOwTLs/iP0C01k7TG9EugZskgzTpVc4T+Q9rezr6D1eJg6Dlah3WWwR
PCVuhQq+VnwetHPkbb72uOfjdHPgURlQh7+CR9hZnHMjzvFNja7R9Inz1kfO8vnJ3cElCjg/XgfB
ecRHwdcqjxWaLBo1GS3XdBhlwduUPtL8DRAPYf11cKdOD4/o0tA+/QpxMtoSra+tcK1O1eTOtPP6
X7g/vkcduwYWio7I75r+PxuJCGdxD32P+4uD4L1Y8IjfwxrcSws1+UTpEr5/hO8hlusIzm+I5k98
jzr+NNwqbYZ7pUbUu4N4FhzEdfse5zIJumL6AbY5cg7r9sY2gPeN5QM1/4SfU2rkAN8vciO4ZRX7
xzp8DJr/h/0K3+B4H4KFaEuKdd/Dk5KP+zWEoO4lITpFoeVnI2Yh7o1CK7NGKfFjG3dq5WPgLbpJ
oKjf/P4+9gzuvTVQLGwAPRuL/sN3MJdmwQKhP+rdCTwzBOTDPGsP6cIJKBPOaOfPAlEP+Vo9J57j
30I5q0T+RhjN6mC0EMG0G7Ec9RH5xAYYJo5CP+sGbKcVtAvyKFAuLcF0VuRZXk/r40zEycFugxyN
7wJoY20DH/MTF4x5Ocr2LtQHPl5MXzhePtbz42wd45+NT5snbxf5tDqHuacewbghEojS8EB6H2xG
1NJP0Q9vhFlkBTora6GUfINY24rnoI9GtyIGQimbRRYiyhGMzYLHkHZA+h3iIGItYg/iR9YZ7sG2
X0Zaz+MCDvoi2i6keP9pxF7E5233LgTv68/KLwT7J1yUF3NgNgdtjz5he/j3+o9BHpuJdjgb5YkQ
pkM5h2SGW2Qd3EK/wnJuky7JY7yzkt0CSf/VeP4rkP2QrckwCvXCObatB1LnfwNHLqA+TnF/deDn
8//uGP+nwPWdjRinyb8WOmo69C3KXwaF7IEbSBPq31q4mqM1X63J8zHc963rhOULtfJL1g91pYsw
CNRLyzE9l6Mtf+m6/ld5bHfLhWjTgzbIOeiLINjnWB9xaR7Pg/kcEtex9lr+To62/Pl+/wpDIA/l
VIoUNB27JC9ZYRoHrcH8KuB6fhPH+fwQ9KuGRPWTA2U7gQNlCBxYNo4DZQccWHcexwVyreByxT45
L7StT5ueX7o+fFzsNax3FH3mIRB3KT2v36324iKdHxjV9/N5bku+uaTOH3vij72Be+Wv2vx/Cbh3
3ka8iXjj/3Rf3MpwG2HlduJD9DdC6Ks+iTHmO3AfQMtCgHMvAzQPRzuEUXXzc1h2DaaDSP+FcGPZ
BKR4Gp1DLWtGbQx/hHgPUcviYWarX+nBfO8ob8v61vYCUX7Odxa9nXNdovznFiDWYPrvCNSyc68i
fRjpr1g/hHyVSGdh2VykeZgvR5Ri/n3M90BQTHdDHEfgOJvRjWnOQv7HENO5P/Incej/v/Qv4o//
Lo0+A4AqzefE8V4aQ/y3adt6/hf00lijbf3/K9oWS/wbbZUD+nxvc1wQ+/zHGKeN4nr+3opTiJ/Y
okgL+pSy5kejL6v53Nx/bKWav31Q8ydJ6zNFjXLfmfuv3Hfm/ivStUjvEffjeKbA1TzO5+NC1Rda
kaBtCFAGYQ5T+gpgShf+DJY/BoWueI7NJkvJg+RxEiJHSIRW0jfpPvqZQARBUIQUYZawWLhXeFz4
OzOyAex6Npw9xFayR9mTrJ7tZp+w4+JO8VXxO/GUZJTiJa/UTRokTZJukiZLs6T50irpKekZaYv0
rnRQ+j3pnqTffRZfrC/Jl+wL+jr6sn25vm6+Ql8PX4nvFt9s31O+Db5n/aI/xu/0J/uD/o7+If4b
/Mv9G5NpspRsSbYnxybHJXuT2yVnJvdJHpE8JoWmWFP8AQjQgDFgDTgC7kBCIDXQPpAXKAzcGJgT
mBdYGLg38FDg8cCzgbrArsCewGuBdwL7A58E/hksDKrBnsHq4Kjg2OCkb8Vv3d92O0lPdjpHz/nO
dTlXeK7HueJzJecGnKs8d+e5JeeWn4s0j2wpavk53BxpjkT4E2qo1SRXS7aQ98hZlNwbKLlDApyX
3DyU3P3Ck4wwMxvIbmDL2Ar2CHuCPc8a2CH2rRgSd4sHxJOtkvNLqlT9p5I7mTQnqdZn9MX4XD4f
Si4DJZfjK2iV3ESU3JMouU0XSW6w/zr/svOSs6HkPMlJrZKrTh6tSc73F5IrPy+5ZYHawKbzknsb
JXcIJdftvOTGBCd+SzTJkZPsHEHJZZzripJTz/U6V3pu6Lnbzy0+d/+55uYbWnqg5OZwyUV4PLU8
4qBv071CVuQIfRd3hAU18kEyg0witzbXYn4C19lwZjgj3C6cjsk74HaYDjfCeLgaejR/1nyk+UDz
O81NzR807+c1m1c3r2p+tvlx/HuoeXbzvOa5zROacwG+rgL46kj0qX7TPYjlX17XNK/p9y83Ns3A
3A7EMsTipju/nPbFxC9ua9r1dfum+7/Y+MWKz1d8/sTnSwA+X895v3B9PvlztPCfZ3+ufp77eeqR
0iO9jxQeKTjS5Ujukewj7Y4kH4k/4jhCDv94+PvD3x7+5vBXnOvwG4dfOvziYezl8OuHnz685XDv
wz0PFx9OPZx82H84Ka4x7mzcl9YX0dN7UV4vPyqvldfIj8ir5VXyPvk5+XF5HZ5fx6Ue4n0iCKP4
3iVdLn5PQf8ZxUX5kxgztX6E0fAfPkJ/Yc5f3LkfgWcL688GsWqkIy+8i3EgYPym4a8+rJyDDWrN
9f9P47iEM8jSz6dT/2NN/V/eufqirABPwjy4R7gBVsA/YT7cD0vgUXgGnkIXYTGK9W54CE7Cv9BK
r4SF8AocgZ/gMdgEv8DPcAqegGfhLXgDnoORMAqWwWh4G8bAm7AP/g7vwLvwHhyDsfA+7IcD8DyM
gx/hAfgIPoAPUVePw/ewCCbCBJgEN6H23gy1cAtMhhq4FabANJiKOj0DvoWZqN23wd/gTtTzHfA4
zIZZMAfugu/gB9hJVpCVhBKBMCLCOWgmq8hq8ghZAy0QJhKRiQ4iZC15lDxG1qEtepwoRE8MxEie
IE/CafiNPEWeJuvJBrKRPEM2kc3kWfIceR5tVohsJXWkHs7AQbKYLCHbyAtkO9lBGoiJmMlOsotY
iJXYiB2a4EsSQxxkN9lDYomT3Ev2khfJS6SRvExeIS7ihi0QIh4SR14lr5F4kkASSRJ5nbwBv8NZ
+Aq+Jl7iI36STN4kb5F95G3yDnkXbebfSQpJJQESJPvJAfI++YB8SD6CXSSNpJN2JAOOwjfkIHwM
X8An8Ckchs/hH/AZ+YmcJP/Cs+pn8gs5RU6T38gZ8js5SzLJOdJMWkiYtMdzDCihlAqUUZFKVKY6
qlA96UAN1EhN1Ewt1Ept1E5jqIN0pLHUSbJINnVRN/XQOBpPE2giTaJe6qP3Uj9NJp1IDk0huTSV
BmiQptF02o5m0Ey6kC4SraKN/iTcJdwt3CMsEBYJ9wlLhYeE5cJq4VE8OZ8WnhE2C88JW4StwgvC
TmGv8LLwurBPeA/36vvCQeET4TPhS+Eb4bhwQvhJ+Bf9F/2Z/kJP0V/pafobPUN/p2fpOdos6AWD
YMTTheCknmJPs/VsA9vInmGb2Gb2LHsOT5UtLMS2sjo8mbexF9h2tgPPmZ1sF57Te9he9iJ7iTWy
l9kr7FX2GnudvcHeZG+xfext9g57l73H/s72swPsffYB+5B9xA6yj9k/8JT6hH3KDrMj7DP2OfuC
NbEv2Vfsa3aUfcP+yY6xb9lx9h37nv3ATrAf2U/sJPsX+5n9wk6xX8nX5Cg7zX5jZ9jv7Cw7B1uh
ji4mefACbIdXMTqqh23wGsyFl/lzK2GAMEgoFwYK1whDhWuFCmGwMAR+JcdoI3/OAqvhBO7Mp+FB
UgRLSTGZTh7A8+IhMgMayB3kBPmRTWa3srvYFKFSGCZcJ1wvVLF5bBqbwe5h09l8dhtbwBayRWwx
W8LuZTPZw+w+dj9biifyA9qZvIatRZ/mMfRsVrHV7E62jtWyx/GkflLoLHQRfhH4W2kJoO1FMUGP
HOglZgdvCkyUZJ2iNxhNZovVZo9xxDpdbk9cfEJiktfnT05JDQTT0ttlZLbv0DEru1NObl7nLvld
C7p1L7yiR5Fa3LNXSe/SK/v0vars6n79B5QPHDR4yDVDr62oHHbd9VU3DK8eASNHjR4zdtz4CRMn
3XjTzbfUTL51ytRp02fMvO32v91x56zZc+6ae/e8e+YvWLho8ZJ777t/6bIHHnzo4eUrVq5a/cia
tY8+tq728SeefOrp9Rs2PrNps/Dsc89vCW2tq9/2wvYdDTt37d6z98WXGl9+5dXXXn/jzbf2vf3O
u+/9ff8BeP+DDz86+PE/Dn3y6eEjn33+xWXf8bLveNl3vOw7XvYdL/uOl33Hy77jZd/xv+c7qqpa
1OOKwu7dCrrmd87LzemUndWxQ/vMjHbpacFAakqy3+dNSkyIj/O4Xc5YR4zdZrWYTUaDXtHJksgE
SqB975TSal8oWB1iwZQ+fTrwfMoILBhxQUF1yIdFpRfXCfmqtWq+i2uqWHPsJTXVaE31fE1i9RVC
YYf2vt4pvtB7JSm+BjJsYAWm7ytJqfSFTmjpflp6mZY2YdrvRwZfb/f4El+IVPt6h0qnj1/cu7oE
m9tq0PdK6TVG36E9bNUbMGnAVMiVUrOVuHoQLUFdvbttpaAz4aBCcSklvUOelBI+gpAQ6D1idKh8
YEXvkni/v7JD+xDpNSplZAhSeoYsmVoV6KV1E5J6hWStG98EPhtY4tvavnHxvQ1WGFmdaRydMnrE
9RUhYUQl78OWif2WhFy3H3X/kcXG7b0qFlx4N15Y3Ns9wcezixcv8IUaB1ZceNfPr5WV2Aby0kBp
9eJS7PpeFGLZYB/2Ru+prAiRe7BLH58Jn1V0fmNSevOS6om+kJLSM2X84onVuDRxi0Mw6DZ/XVyc
ujPSBHG9fYuHVKT4Q0XxKZUjShK2OmDxoNvqParPc/GdDu23Wm1RwW41W1oTRtOFiTHn72kprTpP
lQ06L1nCR5TSFxUi5Bvlw5FUpOCcuvLLmK6weFRXrIafSoJcodG4IhNCSq/qxdZuvJzzh8QAuoiL
f0XTXp1y4oeLS0a0lkgB66/Ak1xPzqsa3m9LhzIzQxkZXEXkXrimOMYeWr5zh/bTG2iXlBqrDwmK
D8pRtiMqu2Wh+P1+vsBLGlQYiZnQnIEV0bwPRsbXgZqVWRmi1fxOY9ud2Gv4nTltd86zV6egJm/T
gr7YkC54/p/F6ozpPb5biDj/w+0x0ftlg1PKBg6r8PVeXN0q27IhF+Wi97uev9eaCsX0qhDiaWuK
xgvaXVTK689X5pkKY4gF8J+kKfXokIBKqRUQX2nIWt0neq3U+/1/ydMg6y5gaoic5Fwa+YOtdZSh
bpkX57tflL9odMbFAo6XBWnZkGGLF+svuleKBmjx4tIUX+ni6sUjGiJzRqb4rCmLd9INdMPimt7V
bQvaENm1JD5Uem8lTmI86dYB9gqPgIUQ8EYahVX1VkeO2iCsrrfE5KjFVmE5lCMohIR+0IigcIvw
AMxGUKxeVtehU85OnqjXm3OsWH8J+BBzEALU4pVoeRXB6y+pj3Hy5u+us9g0vr/VZedFE/VWd055
sUOYCUQYI9wMKeDFgO1mSEI6Cmki0pHoQJu0car1FmvOHOyvCKsXCbHQDm8Xo6edg7REiIN4rdq0
OnO0n2l16Rk5xXqhl+DWqlgEE+Qh1QlyXY7Xt1tQcaSqsLBeMfDxLayzxubsRedBBgfWmoO1XF7L
XkEPWQg+kyH1iilnWbERD8VaBMVaN2MT67SrKtxchw1hf72FBHDivUlCIsQiLRWS6mK9jbuFh7Rq
D/JWsL8edbpcTupN5pzGYkXogXdD6PU3Inhvy+qDXXOgOCikQzaColBnY2o2/xK9sBhTi3GZFuPS
LMalWYyjWAwS+tmL8M4irJMl3A41wgxYhliHaYZNxtahBHdqidT0nJ2CR3CjJKy7UXYES+PqFTMf
mbvOHqNVc9cbzTlFe4UpMABBcfBT613unFt2CxnaVNrXu+M5Q02dYkTRuaJrgYxOvgZ7hQQhSZNE
oiaBULEX8wQsghcIBp4HuHToh/QgX1+6H/OcvtNK32ulf4/SSCM9UI+9qA30A06bihPoN9jYcPoZ
rMMUpbvpq5CNDJ/SBj4K+gndCUVID2F+NNKdSHOR7qrzv+VtoA31SHDsa+pMTj5Z+mpdZlZrwhto
TbjiWxN2Z05xgL5CX4YEbOIfSFORvkwbIRnpS0jdSBvpVAxTvPQF2hm6I93WSl+je7hO0x10O3RF
Wl9n5kMI1cmcbKmTOHm+DqK58izvHvo83QxxWPW5umAclm6sD6Z6LbuxPUKfplPrEr32Yj19nFSQ
U1ipFg5xCnb6RF0+b2RZ3R6fdyddRpep7nw1oHZQ1wvZgewO2esFX8DXwZfvW+8rttL7QUTh4Yal
S/CaDz6K2oNQEcvoojqWHypuwTnxeVGYg9daLVWN1xotBXi1nr97UksV0XtgAIJiG7MQsxFzEHcB
w+vtiL8h7kDcqZVMRUxDzEDzUYMcNchRgxw1GkcNctQgRw1y1GgcNVrv0xCcoxo5qpGjGjmqNY5q
5KhGjmrkqNY4+HirkaNa4yhHjnLkKEeOco2jHDnKkaMcOco1jnLkKEeOco1DRQ4VOVTkUDUOFTlU
5FCRQ9U4VORQkUPVOLKRIxs5spEjW+PIRo5s5MhGjmyNIxs5spEjW+PwIYcPOXzI4dM4fMjhQw4f
cvg0Dh9y+JDDp3FYkcOKHFbksGocVuSwIocVOawah1Vbn2kIztGEHE3I0YQcTRpHE3I0IUcTcjRp
HE3I0YQcTXTGVuFA8evIcgBZDiDLAY3lALIcQJYDyHJAYzmALAeQ5UDr1KdqwqCoNrMQsxFzEJy3
EXkbkbcReRs13kZNvaYhOG8IOULIEUKOkMYRQo4QcoSQI6RxhJAjhBwhjaMWOWqRoxY5ajWOWuSo
RY5a5KjVOGo1xZ2G4Bz/c6X8Hy8NvYtU6PBwpXNIO43Ohh80OgsOafRO2KrRO2C9Rv8GczV6O+Rr
dAYENYrtaXQqeHWkzptvKXaiCRiAGI64BbEOsQXxEkLWUvsRXyAitLOazCzyAHmdvEV+SRa3yE0y
tUgDpHXSFuklSdwiNUnUVxxPTZodRdMCS7XrbLz+hMBDBK9FWqqI5mG/eWhnO+NfHs1TbSd8P2WQ
/RnkpQyyJYMszSDFCr2SMM3S+SAfYy0vqVCNwR7eQ4j8YFoPtEz3b//B5a0LdvE2kD1R0k7NRPoD
YitiPWIuIh+Rg+iACCC8WlkG1q9Qk1ub3INIQ/gRPt4FOPljN7tNp+6kJrK+/nUTKLyftHTk212X
lo2koS5tAJIddWkjvcUK2Q5p3A0iL+DKbUa6pc57FG8/FyXP1nl3I9lY581DUlWX1hHJdXVp73mL
TeQa8DLOOqSVDsZ5czqozjsUqw2s87ZDklmXFuS1M7CjAN5tRyrgKNJAK1dqtKeUOm93JMl13gJe
WwdpfOGJBB204YkIToV6HNBPO0kFI6rBe8L7kPcHZP8eBYvq8YmvgSHZH2ggQ1W9d0+Hx7Bysbeu
WM/r4/mwtZWGOH3Buz6wyLsG2yKB7d7V3o7e+zs06LD4Phz3Iq2LOu9cjAs2qzHeOd5s79QOR71T
vFd5R3gHeasCWF7nvd67hw8TKkkF3bzdW44N9sVZBOq8VwYatCGWem/zqt40b4FvD5cvdI22m99h
D5cA5ER7b4/yzQg0cB2/Jr+B2NQM+aS8TL5O7il3l1PkZDlJTpQdOrvOqjPrjDq9TqeTdExHdaBz
NESa1Ez+0sghWTmRGL8yLW2l/MrfL2FwQYmOwlUQihHKaNngnqQs1DgKykb6QqcHpzQQPbrdYkpP
ErKXQdmQnqGumWUNcmRQKD+zLCSXX1exlZD7K7E0RBc2EBhS0UAivOieeB7fbiVwz33xO4EQzz33
VVaC2zm9yF1k72ErKC35k0t16zXzj4/7wmRiaEXZ4IrQpsTKUA5PRBIry0J38eh3J7VQU++SndTM
SWXFTlZDLb0H8XJWU1KJ1Y5q1VCbzVgN0jjBarqe4OPV0J705NVwjaL1gsiO9fycYD29CYJavaDe
pNVjhNfbesjXu2Srz6fVCQAc0uocCsAFdVBjkLdkazCo1UrxkQpei1Sk+LSBtdMa8nqxSgevVoWg
X6c15CVaZ6GsP6oEWqt0Pl+ls9aXQP6o443WcaS31XGkY53M/83PmJ6ZpL7TtFmv8gcK1Sm9xyCq
Q0umj3eH5oz0+bbOmtb6pCFYPXLUeE5HjAlNSxlTEpqVUuLb2unVP7n9Kr/dKaVkK7zae0jF1lfV
MSV1ndROvVNGlFTWFxVWFF/U16LzfVUU/kljhbyxCt5XUfGf3C7mt4t4X8W8r2LeV5FapPXVewLX
+/KKrTroWYkBrEbrqUGPOlwd76/s6bTW9OAKvbO73z0rfhcDshEMGM4bU3qGTAh+q0Nxh2J+C/cZ
v2XmT41ab7lndffH7yIbW29ZsdiW0hPaRAu8Ulmo88CykH/wsAquKiF1xJ+v2RT+0W67ofeEEvyH
+aka8O/CmjDlTz9T/+wzbdq0KfwyLXMKQFkoY3BZqAvG31tlGbuqLqnEso5tZYKglW1VlN4NkUa8
mYmDIFN5dzyVSTJRgqoeoy6Z1kq1MuWhwtT6uMScW/biCT4bgXEcnVGXpcXLdEZ9coDHL1PrszpH
KcannNbF+XOwh/p8ZOU0EKWqrQMmlgWWdViWXxuo7VCbL2Hp9vVY6F3Pj9K6rPUCTM2c0iYITE6t
RGHjsHh/j9clJGod1/JEZmZl5hSiyevfhU3ahH5esFNaW52iNT+1bUGi5VMgWjl6M3NaG9O0Vhbt
5jSNBZPiLkjQsAESWBADKIgcbUN4QuQov8cp/Q7NdGIUrZ86eBb+QdKJD+rJWXDBGeIhnaAvqt5v
6JdtgRZYjsH6EFhB7BiQOeEa6EsY1smEe8mayPTIcbgCHoQnIjvI3MgmvL8U3oAzOILP8RjMh/5Y
/xoYA8eFb6Ay8gjoYAEYMGAbRJwwAj7Gv19xDA/Bw/AiuSNyBnt1wFxsrxCKoTjycqQZMuBetkw8
pLwAD8BuIkVGRSag+5MMi2lm5OPIFxCESngSnsUxZZJG1gf8MAnugVXEI7yBqeXwFISJkVYJvcSX
sKe+MBRuhhmwGDbB28ROysVD4snI3yLHUMViIB3HNAGOk86kH32aGSM9Ip/CdbAT3sL58r9Gdh3b
IF4XLoo8GnkFQ+sdRE/2kJfFHPH+lrsij0eeByOOpxNKpD/2MxLuhpdhH/wLfqazI7OhDwzGnl8n
icRHgijxj6mHzqKzhA+hI862Ckc7DdZBCFdkF+yGvSibw9AE3xAHiSdXkZHkAfIzNdLRdL+wRtgm
fMQIewblnQIBlNFUeBq2a2/p9hMR288m5WQiuYWsJI+SJhqiP9DfmI7dzc6xFjEYbgqfi/SP/IoB
dRxcDbfDbJTtk9p7ir/DQfgZfoHTxEq6kvHatyWayA9Uocl0AK2hKzA0fk7oLzwgvMw6s55sEnuP
fSrOF5fII+Rw8/rwQ+Hnwu9HdkTeR90xY/tBKEWJ3oVa8TS8BB9i65/AZ/AV1x9svzsZRm7AXqaQ
heRh8hx5nbxPvsNZgvaXTLvTEuz1FnorymkufYg+jL3v548x6Kf0M/o9/VUQhWShizBZeFwICQ3C
AeGfzMqCrCPrxAawYSyCK5MjXikOFjeKm8VXxJNSoTRaqpG+lefK83TvtmS0fB6G8PhwKFyPuqtD
TbodJfEYPIF6vw3X4G2U6N9xxE1wClchjvhJGo67gJSSMtKPXEuuJ2PIXLKAPEhWkTXkCfI8zgDn
QGUceyYtpoPpCDqGzqML6H10G/7tovvox/QQPYEjdwkpQqbQSeirvce5GecwVfsmxQP4t0nYL3wo
HBO+FU7gqrlYEpvGbmer2Qa2jb0vXi3ehH9PiC+JjeL7YrPYLFEpTkqQsqSJ0kbpK1mSu8jl8iL5
I/kXXQ1JIBk4ct+FL4qpB/dgEt1EHWw2OYEFiRhSWHDmmbgOg3FX/AJFQhjXxczv49hiqYfFcE5J
ZSH+QILshs7kdZgtUQG9PtYEdeQIbWKv0ivgIKkmHrZBuFl8m/phM1qjZXQP3U16wjZaSIfStQKQ
b/DI+wb1fSY8TCaRKbCZnCDdyJ0kn8yGj6hTGEzmQWHkCcqIQvqSk4AjgLvYaLjhP79TJwVwBI6H
H2MmdgfapwZYgSv6LHxBnoGzRIz8gNZNQGs0Aq3Mvajv9wC3elW4z2bjfvSgBblR2g/b+Hen5Hyp
B7sdTsLvcFzchRrVEy3psfAE9hj7OpIf6YA7DHcZbMR9Nx6uxB3zDWrJXszz3PW40/VoS3JwV5fD
MBgNd6LVeyASiqyN3B25LXILvIO8Z0l7cpbU4o5oQI5CeAv/lsInZAnuwyv/8zz/6hMeDY3wHXGT
AMnB/XBCnC4uEzeJ28QXxfekTijtebAGNfor1GY9zmAUvA/fwW9Eh2vjgfaQh+PtimOvgBtppbAX
epE4qME9m452vGfrTKZgK3NRemtxP+/FvXES7cT18CIcIpS4cEajsH8dtlOGch6OtdfjCt5N6rFk
NFrtDPge520mXTHabg8qtrQCrVYjjukI/BOlHdHG1R7tQgkZim39BtfCaOyhC5TzXyFFtqOl6g8l
wrso71RihZ4kmTyFfNW4Q82QCAXi14RC+3D/SFc6QdiLZ0wEy2vx9IqHK8hkHIUF59ECsWQAdA4P
wjFEPzf+O4jxL7AC9d/3J0DdpNsAhAbcD93+gNgjCunmS/DWX0OXE4UyEUA/BP08O+L5v4ZpxcWw
ZANYH/4Dtql/gW+jsJdfDEdhFLEzAZzjAdxY14OIzwNI4Pj4DyT2jCIJZelFv8PnbkUzQMqPAAEz
4nQU6XEA7Q4BZA69jP+TaJ9xGZdxGZdxGZdxGZdxGZdxGZdxGZdxGZdxGf8XgfJvbYv4BwLI0HMb
JWFJbqBFagyILCyAXmZhAh6dJIapsIcEQSEh4gZ3pvV0YUthf+upwn4thVCEaWszXjpl+21+WwAv
BBg0+4TGZpX/4MrHGvnvhGuErcIYcRd2Z4BJat4CcYHhtHjawCRRMowRxximi9MNEogCkQx6nSxi
G4LhlE4ngM5n1Wfpi/SCvoH8TdULPq/2HkogDXRFvfHpXnw8VSdaqlpwKNYTNlcBsdkLCjg6ZZNb
J8cInf2xQq52fbozyel4il+ErcR25kz4p+iVf8dkUnggHS9+CFYoVc3plg0C1SkEFCvYdXtJMv+v
s/EK9GFVr/xiXONj2YwyPgLb05NaR3DqhPUEFBVZC60oC1JFUoK0szWmS34upbEOu8tJx7y8unbU
0HmNi8Zd0TklPPAY+fk48RPatDf8fvjaH58Kb1wzlo+kF45E1UbSV3Wn0TT9ODpOv5JuoBvNsqKz
Av6zW/mYAFdEG9M23S/iGiMfjX2iJo8TLUcvHkxMD6FzHhVynfZYh0yF3oNLuiWMXfTSyg09y54N
D6x78cwX034kz5Csf4STzrz/U/hU+BwfyUN4eZZ4UD9S1VjaFfQ0aAEv+CAbV9jDxk13Z6IaVPVD
0fc70Sk7F9f/If5CM3wMGSMtkWO0O85DgK5qIoqvLxUc/BdlBEv05HsaJwrfYysP3ai10u9Ef+vp
fjjmwqLCBWLHzDutr3XKlkkuLvSkD8MPeMQfzjq4Hg2NHGNmsRHMOIyH1LKZ+oX6DWSTvEnZYN6h
vKXohtoqnZVxQ73jbOOd4+PGeXUFtEDqonQx9aV9pd5KqWmD8g7dJ72mvGb6hB6WPlI+Mtmsbp+b
uvl7+4DdmederzN5LVkWalExZ1kPYuKhAYywuGTHIYPH/+Erf4x3Mh/wiczJHFzMUFVFclxOm1WW
UpLBZs3v4kqWZMlmdTpzc7rkd7FZg0Gac3Dm0mUzDn4cPovX3HJnYt6A3CgRG1dtCw8PV29fQfqS
9eSx7SuOFw+5KYyfl9XiITcSSujLxbguT+CWDaIMFBiqKpPo3+gS/kO9BtKufrhIxAZ6ww6dgjvI
qMBuUoEyI7RKNYnAvMzHQowxj34X2UBqIbp8hf34ftYEf6rqBO4aqPL7bZLcuUtqfq4QDB975P2b
Cc0+ylKW9Y6k7pvPVyEIwEpwBHowwT61wOgzFShGjzHTONg4yfiVUTphIhJzsgBLN/UxXWfaYNph
esOkEKoDo2SSRb3BJIPRaDI1kOfVOIE5BIEJ1MhMgokyPciqqdF0ADO7STro0FBt2w6MIQM0kIpt
4lI9QVtAVbtVXie/JAtynKWIzqaUesy7yNWkjzavo5NxU/bD2fGpFaGxaqkq5JYB7QJohCsZQy2z
WCx86XDtMtF2dSa5ttzYFBuxETqrZSO944ft28Mnw1tI2mnhyeYbfgt/QpPIr2EDyuBa1MQMlIEL
UmCn2n2iYZpugW6lZ4O4QfeMeVPMTvN2296YRtv+GFOs2MVWYr3d+QL9wHrAIe+G/cjOiOy2W+N9
8TSea1486lr8eovJ68/yUz/XPP96VTmgRBRBaSAD6rcQQhqIX032siw0PbwCWx8rkkMwI+nQACMx
xgXch+ye1EvU8xQqaEvm5FNVaKGiesqFwCVQFVVYIgaDKaikXXJz0DaApraQm+MkDq6ynfP4TWYJ
n9QP6VX5N+uEtaFz4TP7Pw9/RTJ+3HC45fFZA/uPrxkysIYNThpSXttyR/jUR1+GT5JKsog8REbv
bj6+aPntS5bew3/6sA+NwlcsqJ02HdV4oSuRpK5Mr2wRKJWCxCdmi1Tcontvs2ZP+bFSeBp3VxFa
lhi0LASxj9sW4hFMnDb/ErU02v9BIb6EZ4uMdiVnJ8iRQ6qSX5AnpeNF5sJV0jvnSSpeMHdILfen
4T28tIMMXMF0fZaxK+SLRcaJMJGOEcaK43Xj9N8Klqskwg8BQa8oTFYI8YGMJkiWFMZ8ouQQRUmn
V+MSe+h5F4a4xDx9gAqCxPgXV1WzJFORMQI6o8sVBw10hGrwEu3omqMdXqmq4lVItjJHocoumgoM
ayg+3L8eww2j2gyr53QVrt1kd0v/3mNK/ol7FIVSVNjvBK5fVmFLZqZmKhfc+dqCjm5OZGth4YLX
0HCSspBhcFkoaeCwip0gRMJ1OqbfFQmjaJq3Sqwr/1SSyVXR7/74/QL+EX+MIIgvhV+c07L9tvAb
tDspyHj7DdIvXC/ual5MfS1NaHlGRI6JN6BNj4OP1H7zlUWORc51sEp6U/lI+Mjwq6AElHRjuqmd
o51zmjhNmS/q5BjZ5YpxudrRDCEgyuliERlAVosrlX3C6waZDLLy/8fyJK4h//aUzZ2nUb0JKRmm
utwdmM6smu155rLhFjLAQixqrDvP0kDS1WR7B71g+ck8FH4CbJKSuOwEkhCbVisTi+yVs9EsNNB7
6+NnDY7KcjLfEbgLWrfEqcyqyUczOeUJbvPQBOBmkFiKj+8Av8/ldEW3Blpv3AmsiHh7ht/7IXwk
vJDcTvKIaePonPDhuKenP/nOW7XTN9H4604eJ0vJMHIzWb7uhlDprfO+C58Nf/cDf7ELD6OGjkAN
teLxOVvNTUelu9I1ho0xihmuAlcfZ6VzvFMscHWJXxC/WlxhEL22AAEaYw9YrDpP2haZcDWuVwx5
fFJqzBw/8fmz0U7Y7D7wWbOt1NpAl9T7Og1uM+kthf2sVZNPZ2onFO6lIs1Dg6rJ6Av48YjSHAGJ
/6X4iS03J78Hxb0eTAumPEwTd1Tf1VDdIX9sv7tHPtXyIUn/7I78PsMLC28c3OMFcVdC8JXwsb+/
cHftqLIML3ulubPZPvT1TZu2j7Wbuc/A/wfjkzhTAyxTr9CJTNYFJLtXJNniFtzeoiKwAB5jeiVg
AJ0slQm0jx4MxBDnM2WbVDT5TPER7mCgRuCMjBfOSFu/wn6nCk8Vnp+TrSCrajL/1hyIkca6xAKx
ITKnLk4jW2MKULkrsZIg4r7Q/JNYfyuWs6Lm47SpxSfkirvOhHf/Fp78G45+JY5+Ho5egVvVIhy9
JAZkny5b95LuCx3L0i3TUZ0OolNQcPxF0gCJSoME/mP5OJ8h20ANF49f/2fjr4oeti2Fdj74Pxvf
SuFES3c6umUtH9vTZ1oe4JLFi+TBsRnJs6rBIAR1QQOemkTAqapKQrc8va9b9zylIdJU30rVpxI6
YileJEWn/1r5Qc+YotfH0ARmVbz6FNqe+ZQsdC/HszHKRP0MOpM9pWzSv6Ds0p9Wzuqd69gyZZ3+
DWWf/h/0EPtY+UR/jH7LvlG+05tmKDP1d9N72d3KvfplVK4wjKET2ThlvH46vY3JJbSMlShl+mt1
1yoVetmtzzLn0W4sT+muLzLL/KCXFEUfS+OYS0HF7q52QBvrYzpFyYn6AtSg1+cIFJPUoBMEI6PU
qEczLOu8ZmJuIKZ6/pvwXeiS4qrXX1eVJ3IT7Bo8JE/MkVV5to7o9s5G0ew1+AxG2kC7qnYMdlSs
CCpWghwvHpi8GVOnaXjanJp8IjPTWvijtTDOY22Z3DK5MM5tReuKBehH8LhCM7t2V8HF5jZTM7Qx
g1H7dJGmrQYft6pV2mfyrdHva06uwlUlhIdG6OvbHiC7iZ7IZE/4RPiz8Nfhz9G2uoVvz5ayuedm
caDeVEZukpLQxsZCOtq7O+cnLvA/Ao841jrXuqSZ1jtdM3zz9fPNC60LHYvidVKiEoiLdyQ6/J7A
JNftoJsKpFIeL8+Ub4u7Lek232J5kW1R3HzfavkRwwrbM/J25xvOj522/PgK2wR5gv52uE2WBHI1
XA83Akt1JqelpTplECQaTOhgEdIa6NUvBAckd1Aotz8WWx5tIINVi/CRogSDXk8aLduSQeyttsnO
bZMvO0PNqM6oyZiTUZsh+TJOZtAMb1qtkViMXmO2UTByq9xu1qvnrXKbnTragnsZik6dyLS2hPHU
Rz/FpTkq3COdjLYZURVwumQ0UmlSm5UGG5qxQJdWRyWWm+r8YFq+U+x005ybeqnmHcu2hJ8P34Vn
bl9SSmZ1Tg/vKihoeuGFL798Vi0YVjX4wV39O77vSJH/VkTuJ+PJOLI0PDm8+sVlN6u9Xvxb+Fxz
SzgSie3ufyaHW3E05eIe3IGx4Icz6twCS1/LtfJEw0Qjjz5qU7abDyl6SSfpXTqnvou51FxqkXVW
xeYwOywOaxdzF8uVlmnm26wf6g0zlZme6YkLlYWe+YmS4nQoRot5sHmaeZ75YfOTZtHsMxkdJpPR
Yow1uZyBGKuDVDtqHdThAJ+fGx+T2RwLOjN3NNLAZDVR00fxabVSSGqUDkhMWlCTQnwp2Sk0xR97
oTlK7jTqD3PE5V51Al3+NrfiD4OkhdALOmZWmdFBJjZtGbQzEtcA9TnH6Yx1SLLT6YrxCx1pSooN
TxBtDfD8SFlBb/n+4JxXXq6+c2J9+LGPbx1yw9jCwwcnFg7ok7rtmLhrwNtzn/5HQtf5m9GHLNpc
6W9ZK/RPreh51XVGUYs50cNIRRl7YLHaVdbJimxFcSpX6q5U5GuVodYV1pW2VbFrnBusO5z/iP1G
Oi0ZTEYjHpZyIEYxGnym/dxC0CVqshpfHl8dL9TEz4mnvvjs+Nr4xngWTyiemJ5sT6NH8HCRxHEL
cOGZeevpquiDjROaWLiXPDnGb3O4tBiuS2fcyVYzTUnmh2Xnh0i6IWbpHbPmxJH07LsOPf/BJ7Mc
ibin/7m367Cbxq14XshsDofPfLqicsSaa2ad5vN7MDyKztN81XI1R8oWVTwV80EoYgPQq88nGNsL
/P9bYaIVD/1T4hoA7jIeQJexWjfujqhrbD1xooqbJPyHsQ0GNlaE5iVj5JIb+yD5+dix8Cj52s/O
jvqM9xnEPt1anyVqRpE4QOsym6laj3bAaFWiXjSXp4jI1sAXGGlUK09OP++GY+PRnrDXEzxswDAp
15bSmbrD5mO4omee+UxcdxhVrG/kW9aR9cB4KIf0V8fLcboEMdEZd1V8n4S+gcPWL2xKF0+p59rg
WM+44Pzgg56H4tbH7Yx/M+6teKMkmWKdkseZJrWLrfTMoPPpeukF6Q3J+FLeJ1aamJrTydbelKpm
dsxLVZPT8eJJzLsltTmVppYmctufbbbkXZFIINGaGEr8PZElJrYnuaBiKX9iQeEav5pgK/Kr8Va8
uOPy/A106gtMNpr07bn1wnsaxdsaxRrtsYaqOgxJnYK6dkq6qdJrXGekeHBE8OxQzc48Y9yAPJJX
jfK9PxtFltvOP9xFvnCRAa7hrltcgsuTO6G41crdil7n5BNV3AHIjOaOahqGRwR6AnjSZJ6qyjyq
7b7ME9wrx/0mmHGBufpNruJuW1oXjNBw3wkOp8uvmUAJdbBzXpcu+V3yo9YP4ylZiuVxGxZ16UzG
RDI/2L+noUyID4S/M1hloc9TVU/tHbrmwdevLr+lbAi5oct3qfkVJVf3zrUa6FcdH3m4ctGOcMO9
91ydkO/RlZbWLRx2X1lCwJcwsHf38Af2HHdaYfehOcH81DFcp67BtS7CtfbAl+rACkulHV1YywT7
BOed7ts8K+lK4xvWN9z/sH7sPi4d1x2POR57RorpGtM19ir7Vc5Sd6VxglHuZs935ruFGeIMywJx
vmWRZ6N9g3OnfbtTMWtrEJ/H6Qt2R54518RLPEl5ptZzyLSLMNDjCtltBlCxKqhYD3KX4UrsIgSj
qamqzyUTXkr8kGXiCZN/ABqHuHjZ7/DEVRT/EShjVJCJBw+PC6qOZkbDAqRRh3lyW4ysibZLvihJ
56Nk1in8vXnUgAl3zp5UPjaWODJPvXc8/D1xnnjlG/pDzuAhD2zau/a6W7JefIUECQb8JLCBnyND
UHY8GrBAAnrJHeyVUqW+0j7UOdRdmbBKXq2cUZSapDlJtJuQZ+wWm+e5SigxXhVb4lmtKA7+oxPR
EMeV02yQzRZcCr2rndkUJPz3mBYLxC1NIklWv86TWFF4foaTT2PQ2FL4T83xjMbUmjXvVaGaJkgT
9BPsY51j3RMSpKpKv79z6wTtuTkudF7Q8v3xJGBE+Fzx1mE7wufCr9TNJZ4We1bJ7SMWzhs3esHa
6ypJGtERM/E8TK3NNZuuvvnpp3Y8vg7nW4zzTUNdcUACeXInWCNn1FJDwWrlEdMK60Zxg363stvU
EKfTOUgfeqVUqh+QtNG0Xdoe96b+LePH+kPGM/JvJlOCJSFWjU/Mi1XNtjxL7Eux+2OFWE0bkoo0
anYhpfepeJTay83VZmp22wn/2Y0nPo/k2rXIMtEXjTCT20VpZocodSdoVLWgwajlvzi04rCH2+38
pz7MYHdzcacaZPCTrNioEmUlDU+6JWldEkuy+HWqyZKHAm/d75kXhZon+E+NHG413VHkVpMseEEj
4+bWiHuIlUUtWvRix0FgDc2Vwkr2VmPEaV1bVTQkWryuMQDesBfwQde5OAnVK/oeWrbYX6T9UKjy
KDcjVVr3ZhWlZOadmnn3GFO7irRfAlVqjxHQWcUzP1c766Aqk3AV9+HxxnUcBL928sXwPSBLLnqW
uLsc3xL+/p4JxPHhCWKXWlRh7oiew9KEmUOvLywkZFDWI4+/8MBnqAuZ4TfDe+9c0ofcePvsXr2m
cLvh5v/PHnq3TmhQMaomGcxn9dkq2Ry3qGMvuWms00YddqfNHGMBqzmG/xDUoegsBjLcEMHwii+E
XiI2i5NEnMTJs0n896In+c9HYxx6JbdIN0BXrhN06dYs23AbtTUQpprMMUHqGA61zkYndXKdUIx5
To9r5k46IfoUNHNyYT/+FqO5qvBUlecouHGbcFcIgQfs5IIcS/Q5ITfGMbnc7OLmkDWrEMufF/pt
Ke61BaunzZwS7NXjis4ffBA+tpYFy+fPG5z6mrVgYNlnzTuEvtreDw9k1doZmUVy1OoZiQsSqd1o
quk03zSnE/MR9NmEbJJLcwWV9KK9hEpLpaMyMLTdUFyqM7YzMbbuplxn9/Tc9mWmEmdZekn7k8YW
l/5+PJMMRpMhw2hKMztdsR1MRpeTuVO5/r+g6b+m5mabpiL1BmOUpmdE1T8lEKWd8qLbQImN1w62
4SI3N15LGidmfQcubkOs7PZIGe0MwTg3NzmKxxMXt7QT6YQGqEHVQ26q3+7JPm97TrVaH+sJa8tR
iBoftK+3Rh89Hc38w83nQH+5UHP3URE122SZ4JgQGNdubOaELLRNUOUSna62A64zmqlWJXV1Rg8N
vTIfnogxFzy5vI0U6xLTh96cH4gxzWr8+M6RhLz0+hwi96jZvTT881fNd1ePu3/h+DF3l6Z1jU3y
Ozul3LDm2ReWHiQGEvfc8uYr9+yaWLjzfjO9+5lHH3/s6dpHuf8GwCrRdjuhTs20EC8p4Itl7Ul6
2j4nvxNFFp1iKq2wjbeJhNAYh80eIzgosXDRJQoyxt+OWL0TwKAP6hTVl5q3RSERhShx2vsHZ3Jq
3jJ3rZvWuE+66U9u4gZH0BmrmSasWxtLTsaSWI+rKCpejDJbHyxg6nRrTrPx3KE/gTJ1aX6ErrD1
Ya8N1TaJxqK65mlHmsSTZPPCvSPWDkgMH/MNvKL05tww+nQt36zrU7NwacsDtNOGYZ1LFs1v+QEn
jfqrvRPCJH+KO2MnKDiyIpu+SFXKFTpHCSmNygHlJ0X0KtXKbKUWC0RBkkFkAp5UKhyAJuSsorhZ
RUlmeirjuahpnD81j3l0rfP6Yx5F2hbUHpBYW72hWzPbHgc/FH0czLYTFm4+dxULnvu07a2VNsLB
2lMhtR0fn1gu0jliSGwUD4g/iaJXrBZni7VYIEZfSFEhSKBtJOBh/zaS1r5bX3KJu86WRp/JsErc
zU5Yp7rlGFfMMN14HWtgJE+XZy3RlViOW0VJW3qbbDZJRoMBj2tKgk7Qlh5IBBv5q6XXG4JGDPHa
1WEkeF4DjOQk7vWLNYDvrX9XAi2mO3/S+y9acn9sVBFYZfhY6sCCvlMzUZDikg+rHhngpUnPjula
Pq8u7GXBtdt6jZ/3N77ug/AMfwRnakKPb6Xa51tyTPdbzG+x7E36rUjtHtGj0Err0Jihzkr3SrpK
WqVbaWxQDtLD4hHloPGYeEz61mTdoHuHviu9qnvDKE7TLZLm6QQbNyx6g4uLyMFkR4EcVx1fE0/j
zX64yEWbrL0bjDoubdZBmWAdi37LBDcj3DSQqpg8O04LtNcYqcHABXZg0OKWtf8ieeF9PzwY/m0x
8a24+ebly2++eQVNvpdIi8Nv/vSv8KvzIhsf27ixdu3GjXy+S8I3spU4Xyv6aI+oHbvG9Imh9jyh
wFQQkxdfIvQ19Y0pif89XhkqDT3vu52Wf4/XoWrHaU6azH011WkwWC1ml18XV4N+ma2d2WwJWq2a
s2aogTnYkyexKDrPyf1OYLBVaD3aNt2osWzbu9wejpXGXuir4VmEK8nnjO4ohgNp3F37Y9ZLiJT7
/MSdhIabd1YsHYBL7Lx/7Mi580eNW4hLWz46/Hm4JXw6/EnpNS3HhZ31mx+t3/DEOlTIBQBCvjb3
jWr6SpEoZjJYHCtOE4Use4V5vLnGzvQKf55DlxojRlpkHGCkxgY6Q20ny6jfGMDq00GxKtlKjcKU
uNn2dXY63D7bvsV+wM7sVggSQZs/pXNILaHEYyvaSRKiB/HkC9T5dJWnX/QoRkmgdhfkREUxGcpC
rsH81+jDKrbqc7pWam8so5KIHsqSjdRyje41qaS68torr+g+KIsFV04q6fxrx+JN4X/hHLNRn604
xwx6s/qYZJNSdGkumytllX2VY2Xa8gxFdpQ6qH23aaf5Tf83KWdMp5OldqZrTGNMyw0r7RuSdxrl
4hQ1tSQ4Lnl0cIF9gWN+8t2pSn6wt1RquMo0wFLq75ksJ6emBfONnf2dkzundE6VJb1oU/xuU5ox
OTk5RU5NVttPMc503BY7vd20jIWx8zIeiV2esS15W4ppDlnqute9OuOZjFB7Kbkh8g4/qf2tNJk/
4k1K5fmmem9qNO+J0/JqPCYmmUiX5NLkVaaHk19L/ihZ8icbTYzFQasvALncK6h3dSgirW6jlk8O
5HGqJsahL0yyiUrKCasmc8hJIgCxYq4aQxheM8aJNQlRa4CR4ewko6w03eBUsWlnrkvFdl0qNupS
O+fnuXjE7lID7fCC7VpcXi04Zq5r4lS0d5Y4Uh4XiaNxpTGyy+9U/Sl5TjXBm+d1ki/Qu8vV+csD
SwM0oLoT8wJx7bWHvGjMy9uT7PYkqz1pn+TPthJrLkZ4WiSgFEXfI+mLoqZcMaEpz5zZwDWrGd0N
LQxvNZT81Qg3n5n8dRB61qeq2lwSnuXvh26NZrmD0up5Z0Y9wMn4qarS3PDUyD5VMdiLLOl4wRX4
YbupwOgwFvBknbEA1+a7rYYCaP2lfiXarpiAU3NgOudhEI8Kgr4kBpLRd008fEe/jf8HqDy6zyZx
9ptH3ZQfcMT2DT973axPv/n0o/Twb7bhFbdk+xKC5OXKilM/fdJCsjIHXZOekOWLddjKegxdvXjP
/Us69ejpdaYkxSaMvaps/oMfhID/h4Hf0gfER9F+v6e28wG6mvp2lm7mq8yVFtkTC27BGQsue4yD
uOzUQdyCIutlo5svtAVcta6QS6hG0ugSXOhS12Gwy4MjiOXfGcJY1GhQsvRZgF7tcNzR3OlOdwtB
l/2a2CLHOscWh1DtmONY5jjgOOkQwWF1+BzZDoZh+MzatmckZaF83NPdtVeWjkhj18qoR36qqtB6
SvPIT2jfNcKqR9FVtOW2euRVBN1vhyZTl9T6WM6W0jm3c8BGb280pCWkXeUeecfVtxcYlLvuInEs
2BQeMjczIf7TjNyBvTstJ/ubPnwqvAjlcx9ahMEsiGf5WtV1rW2cbYUoKJJHKqSFtjJaZjtGZc2L
szGDE/SxDgw2MOIIxsYCN2Zmp3aiR8OS/3CiK7rzR7mOnNQR3V87c9Hj4JKTvCoangeD/EGk449n
kkL/bnsnTNp0NfF4BxX1uTWDeNZdM/KGTStobdjdNKb7gGlHSSO6RzhPBUDqivM0km/UTmAgepCo
XhaVeHDSJGYT42SHkqS3GY32TCFTSjEUCAVSH6GPtEpYJWlPZtSZ7a/M04OBMZEpBj0zxkMcc4oO
xaOPNRpTIJ2liR2UdH2asRPkiz2UUriSXin2kfsqM2AmmyHOVGbqZxgXwEK2QFyoLNQvMH4Cn7CD
4kHlE/1B43fwHTsqHlW+0x81/g6/s9PiGfm08rv+tLGD2BD5UFXiu+WxIF6UhsinWk7Pc8a2e8Bz
kva4qFuewIdrwoRBxcsrBib6GiL96iW9gvRqNUcAo88gCYIRKGFGQdQbZEUn6WRZFBmjlEjaayfQ
Z5mLzNTscsXpihXCv3ok0ZvAgFBBIOZtPuIxvbaTxEWPsDhPv5Y4d0tLnKfFrb23rzr/Csna+qc9
YOcxT0H0CymuAs24wB//oQe6OJnAbcw2g2oqwPmcqTMV4HTOoIExqEZechINjBAlmGuqM/BcU5u5
0aJ7flryN/sx/B/xCwKpDIeI7c0dxLL1HRIb3hz+ecc2FmzpQxs4zn1KN7dcgzpiRL+2GnXEQOao
S9LltxhdJe8kR8hB+aRJ1MlxzC2lS/nQVdeHVJI7yDRZHySZchfSTS4lV8mrDGekM7ISYEE5Q5/H
uul7sf76V5nuav0QVqkfzW7SzyR36h9mK+Rd+oPsiL5ZbxKYjLGRk/lYhj6XFelLmRLLPPpu+v76
SfoNbAfbpz/N+MvCk/V2dx6GDIfqY12cNqmxRlseYXqZ8TVEogNFJ3BJbG/XIS+ivSBtUi3O1Dwh
SBUHpYooGQytt08aCE+qLrxtCILoABAlUUQPRqcoBsDw96Y6KVdBohp0YwaY1pmaTIJJ4MU018CL
7Sejj4uiX4obY3wN7ZlHM2huHvx6+lmrTmspyIruY7zwt4iZk9teJEZTbXGwqyCqBlWTJ99K+CWX
aOtH+OoZyezwA+TaPW+Qq8KryKLwhkOf0hQqhI+Q1LDS8j7pG97Bd7g5PJANwtWLIXnb7OkiieFT
dBsteTqnyZIn84vEL6ITy/ibPdUb1y1PlCRmMpglK4UYicVQhtrCH6pU4wnbQLaodoPFlGVOB19s
dmx1rMADUc1vCOZp8ak9ISkvFncIKxBUtyePv35tIGmqQrUcJZTn7KQA1IQuedFXUh7Ha63WP7Nf
iwev+K/1qy4olVv/V2tXFxvXUYVn7fVPHNtx7eJd09IOTWnS1l7baRI7KW2TOk5qUtvB3qRNRahm
787uXvn+bO6PtxsE5Y224g14hhdEK6SKtkhAJVQJlRd4ASTeEBKoD22lCgSlQoimnHPm3Lt37fxQ
qFZ797sz5/+cOTO72XhXx95/C878l2bNuslB0+fvbgEYGKVPCni5XDr7ozHYPI7D5vFqfky8/hFk
5aO/vtI7lqOvuvAXBN4+MTpyyyMTYxNTcBkvPtKH5QQ3+Poq3BtZF81iGRjt3X/XgQP0ke9o7v6r
/8ztv/r80ueWnnj23BfXph49UvnyFCyc0Z6//bvnZ5cqD911yx9Gwov4zsHuvdh7mb4BURBfOzHU
PzQwPjmxrz/X/9PcHSf2DLy7d1HsG8+N4939E+8WFmGtDYuBu8VQ0JPbK3KL4uWRibuHJ4PRkcLI
ohyeG/4LHLLzcL5+8LXi982/ysDG8Pn3xt4a++BDDMwqQPyO24cfvHeJLthd6F/scp+Fg0T/wIGj
Rxf2Z3HPk7mp++OLC+WV3DeuHsxN3Rc/tXD+sZ7n+l7/1ZVvXpbx7dXN3FQK6W8ZPJ2/IsyvKQpx
la6I4bSfe5hxjxjs+6NIfnXxSfzNeMJ5cWvf7xj3iWLf24z7RbG/yHhAvNk/x3hQ3DPwdcZ7xAsj
LzIeyv+CNCPeKyqjhxgPi9rotxmP9P+4/33Go+JLo/9Kf67o2X0XGOdE375/MO4R+fFlxr1ievwo
47wYGn+EcZ8YHv8C437AFcYDojLuMR4UExOTjPeI5cn7GA/1qH2/Z7xXzE/6jIfFA5PfYzzS+9T4
bxiPitIkfmM2l+8F20YLI4zz4tOFHOE+GB8qHGCcF5OF2wj3w3h/4SHGeTFemCc8gHkprDOGXBSW
CA/C+HDBYpwXxcIThPdwfg02+TXY5Ndgk1+DTX4NNvk12OTXYJNfg01+DTb5Ndjk12CTX4NNfg02
+TXY5BfxEMXqK4wxVj5h/JbmeOE7jPPijsLzhIcpJq8xxpj8gPAo/oHmwm8Z58XthV8SHiM5rzFG
OYZ+gmL+HmOM+Z8I30r2fMQY7fk74U/B+K3FKcZ5IYsmv5NIXzzGGOiLM4SniH6TMdKfIXwb1kAx
ZAw1UKwT/gzZs84Y7TG5vpPon2eM9F8lfDfWQPG7jKEGit8ifB/Gp/gTxhCf4g8Jz5CcXzNGOW8g
HszEfzAT/8GMX4MZv4Yz9MMZ+uFMXoaTvJRFWzSFFjWhhAWvUrwEz7JoEF4VvvDgGTGVFEtwFwDG
q4JxmygkjDjAXwJ0isbV/ylpNrVMik2Ycej3aAxNCGMr8Gr0zYtj8JgTM4wO0ehJ4HDgdQN46mBD
RFwbIC+EZyC24VolGzyY08JNLQlArwQqxZoMvQ0RksCB/CjRE9OkBWcUabJYFv4tMsPpkkT0oAHW
uyTRhpmIqBukC6MesYaQPLSIN6J5j6TgK9rkkw02+9Ik2WiRRVaFpA1nkL5Kr8b+mLRJ0pC1yib5
Ecx7dN8i2Q3WrpnWJ1lGdzLukOyII2LBnYnMTroIZGqKig2vRrbFIzFFGnPVqRKf8hJQRB3iR0ux
OlzmSjRYxL/NWm32FOdMNDtRqAElSjOjnbjaHF2fPbGJPqa7TlZDqliHrLt2TSQrJ0x9wTmX5HVk
BKBni61VHH+Lalpy3Scxq5LuOo0a/hbM2JxDpHEg96ZGfLjWYW6bo20kdNayolyZ6pAUQ4v9tylr
DtE0aZ2ZavSI03iSrW47rSwJ889wZlyyBmvT5C3kleykdrh016neaEe/CXf4Z7GOCkmIKdLVrtrU
4jKMJ5HF2rZSD2tU25Jq4BmKbUh1F1E26mnW0Xaz3nEtTaerKeQq6/QjM+tSRpS4QvzGapRr0Wyn
0oz2KkWrSauknXqR6Eb+Fs0rikTAOnANmShGxJ9YnEhvUg251EMT20q7+urxrqw9Sp2zCqMXWFPS
ZbFLLsJVioMgA6Mf0EowK+jejJSZVMoq1HZn/GWq9YDXvkv1s5Xm+X/t+yY3de6Gmntcp1cZqedh
T5DiHPFLcQ/pW4XrOuiuUfUmUcP6DCniDZZWEmtAV4Yd5DQ8l8AjxOswivyn4fo4jS/DyCZccR2c
gZ1jGR6rNFoWI/Q/c4bIS5vX4s59NBk3FpvsNTm/nfWwOz5m3/MhBgFVSIOoE3+S7p/UVIVm20Af
pzqttI+a2MXE2+l/mlcIdqlOzza9wub+HHL/qJMUnfZfjO1F1oadZJv7diXd+YzO6AaRSaqslXZC
zatbp+snoF4Vce+oce1fK17JiseI6YyUTsfYra/K9YW1XKEubKyucGY8lnytDB0gr7ojZbr/7qrY
rTnpo9gxFZ1qFGh1ONoh96vr6S5R7XuZnt7elQvNJ5rsyjE7hSKLmhRZ3LtsWm83z7nkWvQyfTTR
i6u/SpG2MztWkDl1TafUQaZuO+eEG0cKrXNJflJXfpe8FuV/i7KZ7SZJL+5Q+kBr+kxMEUf5jdQf
Y1e2ul3u3ib+ZlU1uT46Xb67hm7kUac+Vsj33ZlLznm4v2k+DRpvzNnSoqx6O3IQ7Ih3RzL659Pp
p8p9dZvOYS2RPcndPPuJPLMmNZ83unflRN7uPJpodU7HFsncvY6TjKkdsa59LGs7Ud6tofts0W2R
5hNzBHtlIgF3mZMwOiNwl1wUh8UC7IwSrvNwNwPvOQ7Dc07g++zz4ixTzsHsPMwcZrwgHsAfkIHn
UXEE3p/gE6U36FzSBH2z8GjRo0T7e/eKt6jzXW+fQHSKVmcrrQuzC9rcbdGmDerQZg9d47OWz6d4
XJ9mJw1oxqYMbMK1s29gVeG7KzwxfDy7Z4kef110Fq4RdQjM1SztPU9TlZjzRCml/GQ1tOgMYGj1
J6IlmZvdUY+p7HK7qWvK0vIlWW5ouep7fgRDcskPmn6gItv3ZNOxSvKUitRNiGZRmNz0nRhHQrni
Ad/8sWNzM3A5VJInHUdu2PVGFMoNHepgW1eXfC/SLgoJ2jJUwATjdk1WdWjXvWl5MrCVIy2gUjZM
un6gZSN2lWeHkbQaKlBWBAxhZFuhjBrKkzDXln5N2qClGeiqtnQY+kEolVeVCuTHVkPaLMr2ZBR7
WrbsqAHsGkb9KnIjdhToAH4FxiRjUUt7ka2B2gIQB+2SpJD42zpQ4F4UaBW5MIUMVgwuhqgs9Gtg
JplQix0HINkK6l0flNheNQ4jcjWM2o7ORgKTE6IWHbi2RxSBvwViFdhvxaDII8uqtqr7ON9q2OBh
QztNiIgv6/a2JgLKspIOhEO6GmLn2RaQq2ZTQxg9S4MSE24bgyX1M+CMq522BN9CSLKDMlzbofBG
XDch67OAo6JlHOqqiaa+HKOxsYXxlzUfXAaJ4FQU2V4dXQ805D0KpzFNIYSM6ghuXVVXV2wPROvI
mjZBA/aqHTYd1UYVyO3pVthUTTANSKpgYmSHKBjJm4Hv+iStlNTqcePao75TPX4BmLBkD5UWD8mD
q7YV+Jige4lkBklWy4RflOUAsu+qYAt9vlHtgzd1KEMNFUdVBaTnN+U5Fcl7ZHlVrtdqJTJNO6Fu
NYCstLZeXjm9snSyvLK+JtdPy8dXlpbXNpflyTMby8ury2vlkaGRoXIDkpHEGhODgsE98DuiPKT2
wNrz64FqNtqkB8sfI1Vpy7YfI6eFNQrWxV6V6g+qAkqKKhuqwoZ6BnJVD7TG+i3Ji8DWUFA8fgUX
H3BGXcZgyFpYhBrSrTE/gbYiqI4aRL9jFyber2siocJI+SChUPOVOALRYKYP6zDj0IEwMQrKPw1F
yow1KreVE6sK1KUKoa6y3CV53qNKbydegE+cHFgUSoZNbdk129rtuYQoelSjyKuqVRtzDLUTUOua
xuGAYks9YYdRju3a6BAoIbqWH2yFprSpimnQb0HNxBXHDhuoB2SZcLtQ3mA/pKrZlqbkOULdiige
K7WOc9jzLsc6JDXQLS0deOxBwHYTcdjwY6cKtbpt65ZpcrvcRzrIpIa+Ue00xtRHMIvasRV1coyO
Kba6dm2xZHLKwN2CBYEeFR1HgvObJ+WMPLh4eOFeuTC/ODN3eG5uz57zZ2Fwbn7+8GG4LjywIBeO
Hjl25NjIUCOKmsdnZ1utVslNEm/5bnZNaHkqUC2MBSxBMAokbfgVWKFr0LV8aPHTuEgD27KV3FS0
NkLYsxYPXUf2bCNynVk38pSrZ93waYV9ooSD/yVDSzswqm/OgnezHEei7vq4ZI0+egjoLZjqmolE
nBuBbf6drtEaHRuzI6f546bMWO9zvT/vfbP3Dbi+ck1t9i5tjwMybwt8mo27Zs/QcS95q4hviLot
eAdet8QHwP0OjGfnLhBHduQxet0mT7pnzvFHEDEdHH16a3I967ssyN+Zfzj/YH4pfzS/mD+Rfyh/
Nn+si7N8zViexdfcPIx3j5qP6ra6deRuEX/u3Q9Hre6o+fzh6X8A9j/7RGVuZHN0cmVhbQplbmRv
YmoKMjMgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzNTYgPj4Kc3RyZWFt
CnicXZLLaoNAFIb3PsUs20VwvIymIIIxKbjohdo+gNFjKtRRRrPw7euc3ybQhcLn+f/jubl5cSx0
Nwv33Qx1SbNoO90YmoarqUmc6dJpx/NF09XzRvyu+2p03NVcLtNMfaHbwUkSIdyPNTrNZhEPWTOc
6dFx30xDptMX8fCVlyuX13H8oZ70LKSTpqKhds30Uo2vVU/CZduuaNZ4Ny+71XNXfC4jCZ/ZQzX1
0NA0VjWZSl/ISaSUXioSqfw4dUg3/+JeANu5rb8rw/LAymUmUybF5PtMXswUhKAnUAQ6gjImP2QK
PaZAgo6gPZNSoBPowBRCqaAMkSVClvAZlDMdbMy3v7VtbfXv/7q5d39gk8zRxx618kikh/T+CSVH
IHQVBqgOkgBjUFshUIbIGUGpkFNhfBFyqs2HjmNMUWX4CHscbw2gZLsie0q3/ddXY9bV873xzu22
O023kxyH0brs8wsAprohZW5kc3RyZWFtCmVuZG9iagoyNCAwIG9iago8PCAvVHlwZSAvT2JqU3Rt
IC9MZW5ndGggMTMyMyAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTiAyMiAvRmlyc3QgMTY3ID4+CnN0
cmVhbQp4nMVYW08bRxR+7684j8mDZ+d+kSIkCCGhDTQKtHmI/LDBW2rV2Mhe1PDv850xxrPOcnMR
RWY9u3tuM/Od75yxdiRJezKKdKAYSUdSHl8Jo0RGklIp8GtltSOjSTkLcUMqWEPGkkpek3GkZZJk
PGmbcB9gDkqGDTrYYVNBkoWIkYYsXln4sBqPHJ7jkY6WLD4m4MbhI3HxZINWv7x5Q9Wn+Wx0ddbM
6dXJP+O6+rR/QBdOv6adnfz67exq2pKh6rfxaEFfSWnM7DOpfHX5OqTq9Pqygan6vFmsFPeOqDqe
zS/qCYzsQqH6+Bbi1cdf8/ULX48+kqXqZJfa+VWzsvLue/v+pK1bDM9q6K3s1YvmYIZYqt35uJ4c
nVK13yzOmumonrb8gqPD3G8iejc9m43G03OqDkfNtB2314MPcHX1rc1O2BUCOJ39MR1DsMH6Z82b
GLKjux2/Pdw/uV60zcXh9K8ZsdDv81EzZ3evVu5eU/W5OR8v2vk1vdodzb41r9n/5eWkuYAEvO3s
ZEuns/eH+0f15TrSpX+e3Xx82c7mjJcc3G34UGMRDlZ3Yq6+YBUk/oNjHYAwBBGNlhmJt0PjrEhR
WkDSOS+U0wZYGQKVvMHGGCFliBgqC1suGkgDQa5jYy3V7wTmGO6lB+zP164Ipga0Fx6AeaBMKieU
8UGR916kpFUM5TBoLZQPCRMohqWsknDCNims/RWyRRRO8koVYcb11EpHa43CkXxEAGsBSckaEW3w
zt8xtSFUyXeW2kM2lQEG3mIOu3hWLnMxt36BYh3WQzZY3BarMKSoCERSrhHvU4GBrNzvV3bWaEgJ
KAtLdyokUlF2IBc1g6RUGK5ycZcTvqUknQARAi9IhfryQzM+/7ulAMxEdq5X1NDSQCslkrISbFod
TOrzBTMOp8re3uw7/Ay8t8I5dk0Do60IIFTGsdRRLKeipAlCyWR4b7LuwXjS5NzIWclPjuuLpiCI
w7aejM92p+eThnnuBFTxJ0UsTkIgrszYIst/4pv39VVbX4z7iM7orYkuPEx0t45fnOjMk4mOUdSD
EI0s04CTKxHivRTeWodNXSMEQsLdAQ5l/Q18VnKKkYzkhWGlDODC4w1c+E1c3K5nPy6sQDXOdh4J
jIyzwdJYfyE0bmt8pEcWwsL/i8PEP0c9HPJOdTgM1BsZUmvukv+FZYcUPMUup25Po/ImmGemQwTV
gbxTQciY61bJh0pGJRyaS48hHieJoDZwH3v5sMBJCf8Bx7VMAA1+DUnz+jwyAdCVzsfN/Lj599PJ
HQkQt00ArR5OgE3/L54A6ckJ4KUUMuW+42cEAW3CqZSJcY0gF5TQuWQVCDKwo282a4kg1wWQVsIu
W7kBMC98xMhjhz2b14weiVbHy9RFj5ab6Nlc5F7yVLDmpbOPx84SlHuzyagfOVZtjRzzWOpceX9p
3Fj9HMSJg2WwQmnuiXoPDYG5oFDgc4D76RzQIV5QOkBdtIk2g7a3nx6SZZou+tNliKHkdme4jy57
c03elk65pe9wO04bX0s/xatSbS3QiemG69cxMNd3ZJZcHxMiwvnGP2x/Y0q5b+6cA7h1vrMFes4m
WQeRcz6AAIIX1nOKI2cRtmdNpLVFpE5leinTWvcXhVUG9Cc16EIv6879Sf3QbwzChYRTLv62/bGh
JKH7SGPrfss+rdr8f9Tx9J5rm5KTNEpOhtETSo71wkQfmCYGAeljLXMGslsJv0w1pVGWVEZqB57m
vqLzAEhxmFDu3uPcD/AHSFdlbmRzdHJlYW0KZW5kb2JqCjEgMCBvYmoKPDwgL0NvbnRlbnRzIDIg
MCBSIC9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gL1BhcmVudCAyNiAwIFIgL1Jlc291cmNlcyA8
PCAvRXh0R1N0YXRlIDw8IC9HMCAyNyAwIFIgL0cxIDQzIDAgUiA+PiAvRm9udCA8PCAvRjAgNDAg
MCBSIC9GMSAyOCAwIFIgL0YyIDM3IDAgUiAvRjMgMzEgMCBSIC9GNCAzNCAwIFIgL0Y1IDQ0IDAg
UiA+PiAvUHJvY1NldHMgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gPj4g
L1R5cGUgL1BhZ2UgPj4KZW5kb2JqCjIgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xl
bmd0aCAxODEyOCA+PgpzdHJlYW0KeJylfduuZTtu3fv5ivoBr9aNlAQEAfrY7X5O0H8QJAYM+CHO
/wMZg3NVrUlpirWr3AfobuyjJWlSFMXrYP6W8M8/ZfxXn+Xb//qPP/7vH68u9tfrf//p/ff8jf/8
z79/u/7Pf/7bH3/5e/r2b//vj/QtJ9FvI+v1f/7zf//xf/7g7/mXmnV8/8vjsJyl2B+nputvnD19
XyhxoYmfZPyXlvKtyDWKfytSv+U2vuV++9us32r3f6u1fhMt/m/4bZni/4bfSvd/axl/G9n/jfPN
5v/WuZfq/ib4rSa/rtSHvwnX9XsWzFdv45IdCahy/R9Q5c9//PGXfwUB20vtP/PbP0i893kazbR/
+8d//PHfUirtv3/7x79//m1O+pLRSm/3Ua0vo7K8pOogmYJRpb0axmCnt1GprqPGSzQ3MNNtlORl
VO0vAc2z39dYRjXBN0spfq6/LqOkv5JK9aO2fWl+YdUyh5tL11HzVcZoScN99f5qFZTwu1/nGqDq
TFqyW3Gl6kyv1nNRR9X2z+uo9pJWCxnvNlfxo0qqrzZlaItoX3J5tTba0IheJYNzCj7KUTUv/FXA
E9qzgCnvo+YyqpbXKPhE94153VfV15hNpYYrgidSk66OqnndvdQXJMlQd9r5X2zU3/7xkztVZDyQ
5vvPSJtXtf/sV7Hk08Zz6q+hYLDmRs31Ks5XL7WO4Uat16fgYrSZaglXtEuWevH7Wi9Gmy/ci0Y2
/Yzaro/IC3cH9+w+qqy71/GqBbffzbUxc6+4sM0k8G3Uv+6XbKSa0nSj1qs4Jo6w9VTD3U+7irX1
+6j18hcIyyKt+RXXC8vrkwf+7lYUWUdRkJQ2JKIEr08qaWa/4nYx5DUGyerm+ut6Mfqrt1bTiCjB
iwF2n1Ii2uMCvFoadWi4e8UlazpKCukFkQoebG1E51hGes3a7GUNqDrGK1UVdSu2VUTMCUEycJTR
N9aEy19V/U1beaLiaQQPdkkRVSskAuRb7TMe1V/QglINTwhiBfTqOns8ClRNtYqGo1p7zTJTjkdJ
eg1p6u/jPkpfHReytnCUlldPMmd4H6FrgPZZPRduozoePehHOR4FzmmjzB7KL7AyOVprfI6zQLK3
MuJznANyYs4WnmMDf0EF0BSeY8vplfP1/EejlHw/S3iOEOGvqbi74TlCGYQ0gWgKzxGq72tAUY7l
KpSgV4cipOEJtZsaF4ySTBk9RniOeDXwpqm08BwbJFMDOWZ4jg2SqWofEp9j58tXJcejBiRAnrnH
5zggASAJa3yOkxIgtRmfI7hwTs0SnqMkSoCMowxHgQtH62bbRKMgAXAda3iOOOeXztFneI4CM0HB
g7FclUoJkHIKzxHMABUaKuFPRlECZFzucJRAApSeRniOIpQAsKrCcxSFBOgwJsJzlA4JkGBxxOfY
IQEg5Eo8Clw4YWWO+BwHJQDWjM8RXAh9r6f4HCclAFR3d471b36UJkgAGclrCqvBBOUYtC9puH3J
sqKCc/KoeCHDUeAJmAnNvwqrHg0l9IWHI/tXoS1arUIyjQlB4TXRf15HKd40KV4vXLUOhRlaO1QY
x1+rNqTQkKH1QehEuokOnBCeIa8XrvoXzHoYX5J6qFnpVMiJDpsi2j2YgZJ8+Nd9pURPvGmteHto
3RdsXpw2NFGvY6av2Vr9URx/fhZ4S6CU/86vdByuQE5gtZ6nqU8/Ru2emEkRK6YinufK9QVrQMTN
tfkMcofoz1KzG7V4A/Cv8NhAK3UrtuVqZjz0MJ+6iZ/PqM0Tg4PHM9L9iqtZClOyd0ip+BthgoyG
103C3eOi4HlLWt2+NoMTYlHHpVKfV6SIbTSQwxU7hPqELlbCFQfYFmrkjFekulnfl+58jjO9xF56
t+Kf66hB4ZlNZBxPiMbrSNAQJdpX4UM/cAVS9I0F92AKjBqN6FVK5cNVi6fqarJB3Zyjze5WlLQa
rzihCYXfjVr8Ncf7eemy60d//1kJr/X4HWFAI/vnwiAaBc3APIjxKDBkFojlcBTkaIG6RR9yNApv
q0AtG+GoAk2qwmpp8ShoZbhyZcajxks6Hv2YEhXaYut9xJSo0DxJ1CdKfD+xejoxXP0X1NFePYWy
+3X7tV/vAhLaOHRLMvBn1CYg6aqe1SzH21ybE7q9GvQgCo/bXJu4Ki8ax55ym9Me1jGde8OvuHrk
oEnMgbs8wt3DOs4VBoe7AZsfCjegjGJu3M+ovF54aIRZ+f67FTdxVV8VBlNy57772qARTkl+xU1A
4jmsDTqmO6FN9FXcAJpLGtGr4NHUDqo63pY/f8qPsBougZVfVBFyCjgyfxuQ6PxPXsXd7de5nMQz
dNsBTqNf9zZq8weCP0Yv1Y/qy5ecdiLUU3NhsOfz6+07jm72269/+VYX3KWaahk1oGHg4n/69duf
jV//5e+ZMU980n/+bB9KrzGk9OEsf0RPv890psc10xhPcvXn9ICSA8t1jIinzvR4/rX8Bj16f5UO
C+ZwLr9Aj/dMjy/bz+kBW7i2oTPij6PUf/61rJ5m2FZtTot1B7JutlcdVyjtLPUrbKuehgwn61Zl
sNKMkKn+nFYPOF6FF7YxUo3kJmxtSIjc/Gu07p5eayj1aTqdYPOTV8hzXKA8IxlcG2685NpKRFWY
vbAfS1MvXde5ZL4EJvLysq2jFLvHq5jdK7m+bLVDVuLm1RaeEF5JvJRTnr7xC1K/TtqykkKJdbwN
16/b9O/XV28Ddg2a6iz5d6TD4de/IR1wrtBDpff/snQ4zPRFejT6KCBg/Il/VTo8/3rl0IZfC0Sq
11pXDQ2aHjQ0CJEU3UJ67TUnLRrdwlZhuNXRvV2x7Qu3MA0YZV5fmuuoDg0N+mMLR+GuQhsy98FZ
X2piqSPTWwxf15egtr0GtiLRaR31Jffro77UlDYGROmM9CVIkpcm6Pl+rv7FnXT3s18yOctvGart
dCRzgrbvPJ3PqC0f5pY/VFe/2c24TC8VLeIWXB1gmUTp1W7DyQV3tuH4VvVZTatov3pfn3+9uXZg
IcAkr4w2nAmHf/+CbdYYNbqNWrMX6FbTatG/26gnt1oGT0lIXsbPBr4ph0cFbTrBDM3u2DeXEy3Q
oX2Za9EMzPkGA6f2kBIqr1LqpbF85lqtxg4brjfLe7nNtSZxQd+SwhBBSAlLqeq9x7Qf4DSpl9/k
vHtas1BZekyvqXjzYa2W6BxLavRSX7blkarQoV6waEfS6J6UDMtE28z14Ru/YluWRFetOU6PN+Ws
cz/+ekvVYtrXrOZ2PZ9WKePVVcztGoxicljVOR3t1ggSk8MmHi11tKvrvvBmtVnNvXk7h9UyFmZP
tdpGdPIF+mXPavk0wckrs7pwU9x9ejsub5YM7lPFPyF3F8b4cq6e19ZAQsEd6DBMRMO5GPUR2P/+
DqzejlmxrzSXb1y9HROawOipl+jW1ZReIGqpocQDOXGDW/U3ZcuwyIXcWUuKJF7N8zVna02ic6zM
sVJt/tbtthD9d3295wslKni1gOuGRhKvNtjS0tZ35K/rKFAiMakzpITQy9cXztloD44eldpwuHtw
NK5QLzmkF7O6NOsIJV4FR+OULu/umarg6DyrRfnPEq8OSE+cYnuSeLdR0IAhrlMoc2glaS+qnqNX
K5oZYuDU5RVcNcLUX7NDErdoXy1TA86p+9NetXzwah2QrqG61YrpoLU86Ug3LZ8+O0jXHp0jbYEh
rbSQEmYLQMvtOTptavlZ8CiFkrwxRxSqsbTwGxUcLSoLvRaewFWE3d77Qq/VKhrlNbNa3kqwe/BE
0i4aalkNNm6GoVv867zsXmB1NsWrFnIO82lgOnWvNq9yQjLfxzlmeI7MpxktDwnlqoAnaF+NFK5Y
J/OPcmrhivTSQJfR8LQFb20ZUNhadI4Cnmi4lP4dWnlCmDWIa9tDWSiw0AYkodfit92Dc2bOedaI
78F+4AncWw2pCpkDja3VGe4L/IVXuaXwtRKGcfm4S8Q5oDoo0XTRTdb8EAZoocr3UItX5pJPrSPk
aGVWasENDyWAVtxtXKEa8oSCv2rrMr0luObTgL/aO8nh/FqBCJDk0r0OsOXTNOgAeJBHe9j9T7Vd
lafH5GuWtZ427izrz6jVsMDjggem2LU+512wMkegHrf7qM3EKhXCEuqLW3EzZejIHW9373H3uUJY
Vhyh39dqKpu7d4oJ3mCu8WKqUynhN+KgBfoGk7ACegnPAja82/2eWzKYkHoZT5+5NvOWlSY5mSL0
oddWptAspbNpuOItaySg/S1rpAaZHolVUcWUqjO9KEhUqv/GL4dF8ID12i3F+fbrr4ZFHn+9hUUs
ywSi2vHQFhYBb+P5szTE29euRRng7TQ7q3ECykGQv6DplO4pt+6L4mlOS4+s54yVhnMfDAaGu4fg
4RvpV9xKSkRfDaRIKTrRoixFgCJQQqr2wkSElP2KT4UUjW6GcEWYh2myVCeSKzT8QI06WnRCLKTA
HZc0H1b8Slgk0wGO21ECjjyHRa5fS3dfsjosKlOXmRlborsMe9OMeX8Oe0AMfNvGQuFtVKUjZfSF
dqsZBQnZ+5ypR+dQISHxyKVYQtIITAO36kkuOCMQsjR76bGtqAyPS6lO9q3KCsNmDTqBzEj2wcx6
SRmXMX+mBM27DmveS+41HfQYoHo62K895L+VAdY+OQNboifYA5oSdey2xqVuoz7poO0YXbmng7Zj
dIXpoBlT+RU3r+gtt6sd46WWtTXKZKw62D2ztqRN+nraMRoFa+o18az7ubanEeIWMth8ibdR65PN
/KoqOlpICSkvvNiDFsJtrlVd0gQttcyW3VyrR1rHCwavJWcGlGAWlqpZQQHtGV8uJfd497RJOi5K
DenFKDTM0DnDc2S0OGXzegVUvXm3b3OtD8/Nu33+xgKFlpnh6YleP1dLMjPLs2VUtVOE75y98vjr
smWAZdwAtfya26iHDLDKMnfHHX9uqgSU6dy1OvrWrVgZwjb37kdtc1FJaDLUrVh/PKC/kovUobxD
Q8jPVPyVXKTHmdYz7/lFNdrTavdrw1jozfzHN15c8wbp16ap42/lqujRYw1TZ4RSrEJNTVDOUo+4
H5IJqtIbXeI8F9TUNEtt+jt8TR91hsHr7+GX8y4ef11+gzPMv03DKP1XOeMw01MVa4ZB409z86fr
q+hI6qXUqmC2+pKpeYZcVhsUCB0Lx27KiGQob9hZibiMShIMRKiVIWfghYD1UmX8Fmd0xh/5Igec
cTTEnn+9K1UJ9JXmX7pN2Rt46bKK+ju1nsKk2tvUS8/dZ86aJBkLfTdvOO5n0+nl4pY1YrXX0HtT
tHscAJTQVvyrub7moNRLkyy3eMuyqTTXZE4vqbZ6VpprPXkZtEqXBtkvlP0pOiHWs7IGfdn9mmWj
xrV91JBeMCPnVMsuv+3r61k2nRVZV9HKkSPP+VjvX+dQc2xdYYLr9G9BWqMSrKbtXT13b7zG7EuY
WF4SbefA7Ms0rVI+2NccePWzIUScNSFhOkwtrYccKaTQgAyp0Yrm/YdmH+vjwpwUyMfuX7KFb82v
D6uuj4hvzWOPc0uhhBRhnuGQRWv/53XUMC4YPfxG+vXr0BbaCfTY2yeW6LSFjrbcDaToNmrz2IO/
FM9OaE2Yx75N9XbCFuuZrGCBLRfKWPPYl2F162dKKF1iCSKjRCsqKxkKa02j10nBE3RQzRTxqtZG
e6/kGlHCPPY5LzrxNhfzKrQud3vbvTQ6qPJiFa71qOCc8XaFBlSl/pkh1fPD7n/u1+9PQuhrhn05
sWnG0wblJzOA8xm1e+xhZHToi8XNtSXDTTwhsBeSG7UZ4x+PfbBiFShkRcTvfqvNhJkN7ZqJPbe5
tiQy7B4Wy4hXZOq1kk/vo3bErYpvbKM7SuxJZB9f/G3U6ghhUE9h8/ZwRRgaoOnsNaSEpXFrGp72
a3mVpVv37Cmxp4cxMZoh6HBfEw/VgLrmV1zNJBjQWktp7hv3YqcCtaJYCfb5hCyNS1nyGnG01WZO
zKjhXJV1xLXUFlHVvOazWWr/mV6lMSKkNftzXBOOWBgE9dDz6mZ8soQngxDzgfY/dziwEB+WZHVn
8mWHw+Ov3+b/L5bLfLz6T/v4lXKZx5kekswGblLX6FYyipAZ+0oh/ww8C9D7NF4RN0nyLJ7LNs4w
iK5sqVW3fW3lLxWKcLmcTEeOxYMGmVKbl8FfN9khT1Wqv2FfNswef72VuJQG+qpk97V7pIEQLz2r
l41b6Q1hM6T8hHK4n1C+DaLqNmorvSkvLV1SiWRQJQhPGtm/S9vuofzBtOwLJdbdq6VZzhy+OJVg
cDpSyyFVBxMoIY0dP26FQ5OwLKnEb5yVlxRCVEZSj/BNuADiZeN6Qi0Tyi6pPHHtVwyzIkxM76ME
HHk2zK5f6/SSbk1jq1DCIepH/p07w2SzNEVbtMOjNH3+9e84QM0073PW/LyPXygvep5pcwXQiMsW
uT1L04ZbBd0/SahfNmhVuMv58QRuRn4lkFmO39kG9bkNXMkSyQRCW+EtLrFG26AvgfWqv+1f5gyC
Db2TYX9dmj7/eitomsokxkXer04nQmFl0SuYdpRakibzX0oKXz5CYVVI+eVEN+O9MbOlLTJ3rqMY
chutxqMYctPU/L5WThPaAt9deZ99fdkFZKl/3518vyxpvv+6PHGKc0MQ+29ZY03Qs1DeqltsTgEL
5Y26aOmruW+FKjOlGu6LcHCwqj3tNhcQsX+lGEDY+V2QgZuV8H6kcEWCl0J89BTdP5m4A0XL8o4u
fEsHQ6qSFi19c0MQPEsNS+YsPbQU8AMMFj9qTdArsAKhSrYnLevmYKhErykp1AII1zWHVs85W3Ik
w2m1N8nRrVOxxFTpLeIJhXZiaoe/deu+lAXeveb2cEJfcENEIjN2QxzzNZ0b4pjf6twQQU3ezQ1x
rgYzMZbm0HAuE1BXnXiwe+YEzKtOvB1zeM1ZoRjk59rcEIXZuYaeHuz+hrnSjpmrBg8OBa24FXd4
8FtOwHlfMLEUTCqOXpsLaNBbpkX9ilscv7AupfYSrVhSxjeONvw5riY668+IDz6iEzLg7967+Q3P
K4In6PUsKaIqK8Cg+PaFozc0FahHkL7Nc/QWl1fzjZqj6LxiY3Vmspz6gBJ0Q0CIJ7fiXiemxDm6
YoXnOjE8QdLfUZPzvpjiR5hqN2pzAZkJP1bOWV1AnalSY6SYJwZzTublLz9yNOPp+Y3MeJ6L2BTQ
wQyd+UxVYlM0TUU1olfNlTGUyx3wodcaGc6MSZbh+X5P2CsvQ7J3+3pCsICyZgmKwVyV2SFdIk6t
1eoeVUMpURv42UIV4XpNKZeWBTeQi0aNanjm2uxeWtpTpr9mm93bwahEwpjhJ3bCfl7AOLe5lstY
B7spmIs9eBLqMBB0wym8jVoLuyDiBKb7IiQ2ezy9oJaO5eFY7fEEgdPwBoVXluHnmcv0F2iziCEI
58ZcT6DL4IArgPvZ/RqEhK5UIAebP6HVTqwML2rqoYhrEHH0Xi9P+/qNZpnOLCF/NYg4Ot+7P8ct
/EztrJQ6Is5h+BlDWgqFhIWJx1VmFcxFyxSbmyk8xz4tCUtyOBeLxDo4NhT2LBKDojP9N267Z3FH
1yul8cg5QhUNj3EJhZewAiTPOUJeFSpyE5pQjXYvVOSYJ6ThiqwTYe5gqMjhur6GsoAlnMuiTrAR
/Altth6jTlfJ1vlBEyZ3Ku9axKsiLFRK09+ObUXaen1VQ7cViQgqpfsn4SnkzCJ3v/stTDzMizIl
3v2kF6Wm4Xe/2ht4aAkHnzQeNVhUV2vI98qkyCltUQBWCOTMRGS9Ui0+cy3pM2qRot5bKJmUipzO
nkLJRFvPUJ7Dp9aKxKw6MjpHNUWuq4Zvh5oiN5YHebf1qgER5BbdRwamiVLfW7j7buZEqn73ayFc
pzlRs4Zmjg6aE83KfW9KzhexUQ01ZDuyr9mgv4Wo2tZ8+pvlKi+C8NrnnkdhbmblsvwmGMWyoIRL
4OfarE06XnFB47kMT7EbkO1n1J5bnujEvZhonK4TQ+N0u14dy45WMDMHczYQ69uohw44CVrWcHNt
FqIFPa6K0dtcD4HqBCM3+3094JgklhKMiF5E5Uz5Ktz6jPrzq4HXQu04ieXmftbwLkb5tV//VuC1
phctLX+eQajgyPXPM/3ZvnZnDKxkI/aXLqj8VoaLnPM6zEOOJ73fR0ngWpKj5+wO9xSsaJBLw6D+
5Oi1vFebytFrSddSxjlQb5GjPzIbBCGM/xbORR91gcmY3O5XSrC4HY8PrSA5eowtDwY2e9ZwRbwr
yuzNHO4e7wpn0h7OxXITGBOthrsn6O9s1tooOCHCJDWxJinBvqZacl5tEU+wP500MQBFOXp5rZgD
SsTyjVsXO+otI3eJKMHq0VlSjr/RHFA9F/+Nu9OIekupGp7jPQ9Gjv7uIsTTL81/4yZoCVREgJsS
0ot6SxNZvnF1n1FvAbVayF8GVATrLOXwGwlUBANBS8RfZbB++mpHFNB+WmV0TyF/lWl4+gbrcptr
AyqCFfQu/zqfY2UjPhjkohGvMo8Dt8309duo1XdBNxXMjeZ5YvW8FLpUqVu6uVbHWKVLdVr16Zle
dC6NAepLOJewij/3GlKVFaOZfaVGxKv0LrHQoNSIC827NMr8CSU66/MJJepGrfklkEzfYfGCE5rp
B+R6QK9plc7T88TmU0kEPboam5zvEAGBCj5BWsSFlhMym6UgnzmnQYmC6DXl7rx7a+kFHTBpuHtm
eEB/XSTTBg5aWRJY/QuzAwJlxjett+n5TWNxgybe2/AbpRCs2BzV0Shl8vrU+Bs1EYTMQP1uc61+
NjagBGPE8p5FCA1k7TFPjMQs1+w5Z6PEAEfDzpCQ75mhMPAedy8BFitbaCBBqfD02pL9M7iwtNJC
zsERvmqX9bXaAIHwIhfYDv4+rj4oNhKdo3nNaluxsUAIWlqJJJMIC/ggACSiPX09FvzXcC5lSKh2
T9UtC4M4HuxsVCKZQ0AgkN66G5/vNiQc86MNHC2g6jTOMXC04LSncc4soYxWIm5A+xoj2r0yd1jp
cIhOCI8GDJVuIMJnbVupM+nwitWGu1OMCWcsJogaVDsEhSfqFvxnz8iWNXz41LpUSvHqxJYGodZb
No3Q0KF7prAV54yOUfu0ZOUamh3swtXYDCUUJqAnY+jmFzizl4JxYE+0/KSIfsHV82T5fM0mPIfi
bw1tPqM2W4KtamAH22t2Dowza6o3K+SUoxfRgArYqMPtawfrZVLClQcnRw/ulZQwi70HxwiUVVDg
aIx+waibfXlekZZjfUuuz6iHnuUzq2UXytGLaEkJvVqlghw9uOxZXkuzSgU5enCtZ3mX4k97B9jN
jBGW7va1XrJMXzYRLhztd9gA6i49S7h7YgVBZF+2VzAK/AU1TiXiL2vxgm11x4Vb+NywgrLFQWX1
p95GQXQRC1oiehmi0GAPr3AUfdnE53C0L1s9A0tUhzX0DL6RsLTsCdWjW2s2Yc0Gxrrt6wu1EfRx
1zzdmXy9NuLp10V/w0VH//jobfTnffxKbcTjTBtoLqEpp9Vb3U5g5R8K6ZzE35Hdrh0/2r2fVyRQ
AUwT9We+pUzgdac+n0MZbBar6GXznTMKCq2AbmATwb6YMtGnNQ86S7EKvXBqM/iHs0RkogP0e6sf
uo16ynTAYyvuhHagWzyjpYjf12b9qrxAB22OXltaCC1WaWWm6LTNYk1XS9WAqgP6vUBFCaWrWayF
0bZIPrHQfqRpaUfnFWmxTk2GFXeba7Vh2Kw+W/OAgKpWaP/GvTrLcxbaiyWPulGblclWwmqd/ILd
V6tssdyK8zlaCwrYJiOkqrWgYMC3h/uSgZdtGgjJmVetCQTbNniqbjkMhNbNBr5wvrUNnEMveQ/v
IzPcU28t5XDFyQxmubzW5xWZnTAh5cI3y7IT6FaUiBLMO4CCLOp3v2alE58SqlOZ4YrMTtB2WZnn
TAdmJ/DSes5Z88KZnQDjpIf3kS2h0zunKNhXYxVWWnW1Nb7Pmtg6rEVhQC/WxI45UyjlhO2IGhNu
IgkAE5og/N3PteUdwDyZbQ5P+x3CdrAx05QSUoJe/l7mInPW06aX/52NdtZa2RKaPbtrKMnNriW6
ayjlmNU+YVWUkKMNDnekMsJbS7v2e87aWcoptcN3ztpZA7bshJkv0zDIO4BG10rz/LXlQ1Cjm9Wg
4IJvpEanItWf9uoHAOckWE7qpdyWnUCYXsin39IOzeDNkPC/pR2+f9287fA7AVyIsNfIKuWwj69r
h88z5V8yu38rw0I+7aJXY/Meig3ggQuUuVLsSQ7aRd/M7l8GjHXm+Ame83jcz78u/deP+wImToZl
9LSPrx/3YabHoDMMRbfzDUr4Hk4+n5N1tGsGcRqseA8nH0FsXTj5PNc9nPzhjA1WQV5M/ly+catU
gODsYy7fuHXd+bS8vo3aOs1aiM7QmuQIZZqnhegqy+t/nWPN8ZAv1LQjxwYQx0+/XndobguYbdnR
ZIc4xsPUCETn5tpgGAod1Hm4W7xDHOMmUdMq0VmVSswatTLB27lvEMc3h0QAccxgSle/4h7KFsJR
jxxKKnNIZHri3FwbxDH7To3k53qCOP4OThCsCMWn9FTUcdoOccxOftkw8s8ndMEOXJiQ24pfgjjO
FvSoLeDIo7x6/1r8zdp75jAIeJWin98CQhyDaayTx5nXCDwAG0iXM13T+6t1VO7+HLYVm3VU7imU
tgZPQKCrHN06gydo2UCVbyuuDgdlx+4y47eT6H0wgpKXMVvwuyvTiS2NPtj9YBkqA0MRrxnOHhRx
U+HOu59M99SqJaIqyyE6BHMJXxS8OS92hh81Okcrh2gXVuxtxadCh++mXjCKNWZVpUS0b7W/Kgz2
LuG+mjBdaMwRyTLYi7jBBDkMKcEOlHNI9Stuhfowz6RdGt3xHJviptFn/UT7nxfEK8w2trCrgSw4
QyVcv17e9d9xrl7hbfZN/6/qU88zrRDsbRA1sc4cygELp4O2PR4Fc9VI6E6gbgX/+dWh5+mIZB0L
/sfIMp9k+82FMV7sy5RDLmOvHmjuuvD1VvCv0Kfo64x4ERcN+lQZ/iVftS6DBRjDitaD3Tc65ZIV
rQe7b+wqU1IbkURkYX5p7+SJo3wS0ZeBz9Xo7goDXJPB+ZASirvbhjX1ON9Kc5rwo/xLvgbdwatd
mG4SUgK8OtiaPqY9eDV1OnTD3V9dn5v/xo1eBiSGp3RG56hMoJQhnu/3ZAArDymxHaGs852p+rk2
N81VHtJmaG1YykAeTXrEOeZaaQQDiO6jIRJCxKXwbSAiIWzuUUa4e+YM4P7N+BuF1eY5S3g7iFsI
ds6LTrTBChCbsZVH3fQLgAFP4uVrroRxYgdG8JkxaP7eY+p/NtwTGITVzbUVZ7AVZLmiR+fCBWs1
MBNrw26jVrOSuCcYZF70c6mEIZqMK9vpvHsDDJhV/L62HkKFkQJr3SvnchCILlhZzRTpcTrobEIJ
97o4em2Q/rd87fOK93ztcRIRbA8wsbmFXltW9zAw1aIhve752udCD3BOYc1tivirJGbKgkASnTaL
Rir0aPXfuILAU5Dg+a/hCRluIZ7/7OdaDVNG8JNMP9cWKae46f1KZDp/I7O6IXjVc/Saf0yhlJtV
Fd7mWk3Ou8H8mWulxN1gPlOC7Wfx/GeN7qPB9ENPHvHuOzg6sRVcSC9G0nu94o7nQiLWrJV2xR3P
VCUyIMRzbyHnMKsblNfwGy2STr9SfqDXzzH/ktV6Xy7SU1HSGab//WsvFdf2E9aDSGZXR7m6NaLt
NCWTv01rywgDIoBZ6k+0bKa3sBVdU8ePK9JSxSOZa8/ZrVi2LHAoToXoO26uFT2AkfdUDE4i2Bfb
wg4tfYbfOBhvBincir+DCkfEP8LXzPp8ur/Q/OBxpq9GCup8Emufn8EuuH6Wtuedr/ebAGsylqVG
tUEL4DNqT4Srr8T2oMmN2sqe+HBLVzdq8+E2ZdGtiabbXKtvWSa71lsq9m2uVQnoH2yhYF8jW7pc
03BfBIujgZkjSrCFHaFxmS5wG7Ue4eEsSnY/+xUNTcHu7yPcIJ0+LaM+o/ZMzE/LqNuoVS/JBsxj
mH6fUU8toyCxDH3kNtfWVxL3FCoOFfbbXGtmYWW/PBXm0XxG7eEUVmrjBXWU2DTHln9UfgS7x2s8
erpY/kwvogq860Nuc22hmQ88VEBVGKp4pmS6FXdmhiQtYq7O4Bt7ZauBIW7UBjVFQzVNw+kNqEoQ
qZGnn2vb17QssyQx5zDoAgGfJKIXtb2pzXSv874sPFLVcMRvc60hDUOj68PfjsesTlgTKaR9qeZA
tqyp2zeuVXDgr8FSph7xF1Qg5uRYUOB8jld4JJlL8bbihmUtxL9TDW+HZXVCjVh4YguiUNvL1lb6
zDlst1QgUecMqTqYBZQNo+Q2akNlJnZzyU3C3RO7GfpP0ug+3vW426jV/c3qvNQNl++8oiE8Q2kX
f7e3Gj5D3SmLlFtXpMYFk2N6CbD1cyTmPZGK3aiHJkTYu/XVPPMXNS5Ik1ZC/rKMSF7aUH5dKMu5
+/u4YzGz9UepXgLs2E/sPzvadHNtYYzO1h9TcyiZ6ijMdJLeI15lRuR3xJDgG+f4gRhym2sNFySm
OeRVkq+hB7yPArL2HK3YCpQEpky0iBKW68hUoR5xIXMds1TLeAlWpFIFI1ololcT9lQoGr+1FsbA
Pvzt2HMdhQU1vbvT3rGf5ovZ5rWFK3bWkk+d4YvMjEgQXiV8YaDKss66d3+Oa53ipCs0zVTDFfGm
aSmWZ3rePQMFbJtUWkQvCxRQBegRvcRadnYLPgYrmv4FrXdEp201fJkg1OG+oNrjlLK/j1vVYGNO
dB8SvrWszhtlzB5KX6vOS8k6L5zllzn3pef43b5Qd6Gv9uimXai7sy7yfnPu4xvzVf9xlgCGxKQs
OI32pZYGUnqe0YqGuqt1xHebqLt4Q6eGr6ih7sK09K/Caq2z8A7/WmOJaYV3UK0WK2DdfTPOGV5i
bvsyVzv00RmdkBpWQZm1hFQ1rILLu3G+tYaxlDV5K2DD+TUUgm59mM9arVo/7G5+7WBf1g97jP70
In8hA7A8EPBrRuE8XR/mcgtR2IobtXUb7owbFcYuPqM2Q45p2uyt2dxcqyHHBGzm0bsVN7whg4fD
n1O4LyZgs1B2hCtChc70A3lKbCYaY4n1EvU/Rq2ge9bVd8gw0TVPzGxue4EYFLfi5mpnLHFYA5pg
XzTRNFnx123UZsjh0RvDSgrOp23thlqrTUKqspHQhCj3J7Q55JtV3c4RzWWNhIiU52i/Ke0WJWQA
xs21GjmMEuLtqNnNtRpfFF2jWjr0marmtuegFp0j3fZQ+Cwd+kzV0gyT2pCZAkowSgjD13Ph7rYn
SGGzBP8zR9NEA9tbgv/5DpmJpldpZLAvS5UepddwRZpoirc4pio4p7PRc4rukOW5zdL83d6L1tiM
pbXmRm2mUFYDM/B3aCt2KqD9VKvEvo3aTDSIZzzrqUSUYDlaxmtWJFyR6LzUz3JEe5posBLysvuH
FjdQ72dt4ahu2M+XY+V4h9jiZlrNSsSF1uJGroh2QIkJ09FC2uE50qzqMLbDd6hBEYL1UlrIqy3R
2yt1odfWLoceWm1Do90bnMmgAIvuEJvG4O3vNXwfYXVZCHOR9+uKzCHDJ/i3YwfLZcC6ZM+FawjE
GrT00luPaM8GLdKaFWueeaJ16xq5vHx7ORokE252CSU527gkiE1P+0cY3E6PfLh7lqNhc/7lW0NG
hDMZeLjFz/W31RRqbKVWF5mzjirMUZxWJnfeF94zIm9b7uRZMhG6Fi+8lcmd5YSVkMnVffhML0LX
4r21fPYzf1k2lFzdh4MVYTDRRaOhZDKDaVzdh88yR1jIP2UssnCDrrUSxSmhvGdx2JxiHb8/o7bG
OXQfd7o6o7nMrALl/e3YDICkP1Aeb5RYTaHMRl4Q0aFkollVoXpIDVekkxmqbw61DmUOPvT43sIV
64AZ2vvs0WlfJWSj5VDHvErIptSYqjC+ulmY4TdehWZNYqrS+Gpt1e+fjK8p/VEy/dxgGk9k/pLB
RIP8oI7fSqZuo9bY0c1g+ozaS6Y+GJe3uTYkzE/7lGBfty6utxXX6Mutfcpn1B5F0x/4abe5VpPj
1j4l+EYaX7VZ96HbqDVwzGyoIVbFHOz+1j4loARFF9ar2Y3ajC82G4ZCPkNKGFJJMhUnOO1bk5Xb
7lfz+NZkJVhxEo531uUcV4PJWrHgNGvEOVcrltIWSqxKe2aafJWYEqWAVyEBPCU2o7BYsUbWkFev
KFov6r5xM0xoVkGf6BqdI82qPiHsHe23IiP6jQYh7iIuvOOZnM/xQq8sdfnGLRtK2KdAiqfX1gEV
5rGq+dAD2jPPCTp5TtF9ZJOVCblaJaI9M5jYelk87bdSJBi+TeaoERdak5XcZ2vR7bCMJJajj4j2
7FXKug/Pq5thwgSTrlVC+WUmGjhn4dUNMQQnBM6pnhJrD5LGzL1scbtgRanM0zQlNKAXcUUytL0Z
3VrLbtKrdjk4R3ZQgQ6tEu6LHU3ffTBu+9qiaHhmIe7bjO72hSuSy4ypSiTMDs737+NqChHjElro
wtFr0U22QgdrVHSWEw3GvYFW+N0vEqDh5WsKUR5Kue+9Ufy+NoOpUsUphgocrGj9OJOlEwW7V+sR
kRYuXOml1iPCcv/OPGGIk9LKCG+HFdIUtQzM8zmyREZ7rxq+yFd8jII1XJHxsZost+K8expy0GBy
8dL3IfKVrUIsnAuvVSEioETSxIpfMhRazxNb8QvuNh2KIecYeqVI8/y1rUj0Slb0xrtnfOzdb+I2
12ruWW54nuLl/RYfY4n2sCKT8zskVqK98sRGiW7xC8vKDShhhdwp+91vEczRqZvkRTJtUTShbrLe
7a0UBRKg17m8tZu516CbwBj1+9rMvULdJKUZnRBU6JelJ5VwX0Vw08ZI4dvBDpf073ttewNtrES5
VUMYPvOXWpOJqwdwQAlmHo1kBdDBN4IL8RznFspoK1jJ2Yr7zy+MFaywuWh8jpZBXkVCOUFcESJA
99C2Uss8Ul3k6jqXZR71rk+2wk8txZ6e1LavGZj19CA4A7OeDvqOyXGbazVyWCID+WVmQj0xoIFc
suR2uhU3o5DJKmr1u7dRm4FJMdiTiefPqA2+kmJwXGbCZ/ergQkGTFUNcOc2ajP3MtP76nTf+NRT
E6qXsKwlGHUrkQlWvLU0CGh/a2kQ0P5WInOey2JtOqzh3G33myHHWFtKfl+biZbpmrigkW8rroYJ
BZzoaBJx4dV5s09/2lvsqLL9xkz+tHf4SgOTt8rKM09cPTXnpQgd+ct6ar5xcG+jVqNQCY08U2kR
37MNAXEFcg/pRbQISLjh9rUZhRRKg82rIwlgsTbYEurv45boyCIIsUr5YF83gMgzvQz6MZeRQ5lj
0I9aZwvP0dIhcUQpRbxq6ZAgawlvrTUrgDBsI/pGA4iEiZZruHsCRBaiBkS8aumQMKFlht+IRw+q
hMU5z7x6B4gMaE9DrkB1H+HuWZvQZcwc0mswzQlGjkacA1FJ0HZL+j5LOYvIsXed58I1QY6tMEGI
+A4xImfAJD2STMR+gHY2Z/haWdyOcA3xitVA99ZXdF3RACJTX+TEagoZQGReZOEe3aM7oczlHLfW
AYlgy5pbJAHM3LPQVyS/zJDDFenxKKIYNBxQeIcYa5vvOMGZC4W6yTtOcKaEmG4CK8dxzlfLl8Qz
7y8pVfJbv/pUzGw1zcqM88JATD9mdVktTJXK5JXPqA2L27Isp6FA9mMWXC4sS88G4XWba6tW1peB
pXc36qHMqs/cl7k2aDEKKfYbcd+41cIwhEcHvZtra0tHlNFpkBP9mA+Y2TuzsvIhpIRlbF6ZkX3N
lbspbMRSHpbhGuyeal2Wy94506vPj/g5V/Iw0QrSOOWQqvT1QyttGnGOefFhnEuLvtGUv6KX9+Rc
j8F+VtJymRFVYS+8etHs59riBgVPUu8ll3D37GcFjcYewXMtDCufRQ0H9kxVq2mGHJaQJ4hdLtQ2
/WmvCu6tyiVY8VblchsVVLncvnFVN29VLrdRq7rJ+hWdPeYvS44q6fJSnOseoLAZJkjIXwbW1erU
kCcMrCvLrP4ct1FMoiRGdUQJA+vK7P4RzkUYLqbxeqpuWN3Ep2XWQ3Q72F3qe0JAQAlthCC0mvnz
rTWwrjSqSEgvyJw5Ul1ov6SSGFhXGq17LlxVV1YfGw5XJFfxIlAN7uJl4abWTXZUHv4deupBNeuw
XPLzOdLznsD16m/tWrWRoVJrtlzyYEX652tdOHqrOYFBIDju7OXqml5Us8E79fBNMy9+burl/aMX
HyqWlxNb2hMk0yzZGtWc3zR2l0odDD1CSlD5a816OJ852lK7WGJYw92rQt5369cb0Kuznn5eyt+5
FqYPYrfUHr5pTO3qkHI5vGlM7Zq55BS+21Q32d+oh/LekMZbMkz/8zca0nh+5yGc61eYawHW8Tyx
V8xARtd3HsK5tgPvow5tiw6wpj0RABbqlb8dm6+f/V6gFbZQRgsBYOuVrHjWMa+6mry8VhsUmVUZ
1+W12vZlVcYt+3d7r5hhcqcUDfme/axgphSvm2znSGjXPK0mM9j9bC8mBOVw94b7XehLjvbFBDA8
x3VKdI6WAGZ9nMIVDV61aPNcuCVtEUYQB9kj/lKDV21jxis2pS53xd6CihlWsffsX5i9Kzl2jzuj
oc6E55+6XB0tpCoRXqAStfA+KjMf+myeEusLY13JIcpLyF/W0MqemIi/iL8N5bH6m7Z+YyfCS9O2
vDALF/bMiFOT+SR9fx43yE8E/JqxeszivVfy9GMupjNpz/Ur2by/Fk87Jn9mcPxQMRSW26iHQh62
BLcTPBemEN2hF+s31I+phYbu0Nrl1j0SwtAd8OfkCLFmBBFepMGMa/G+Gm0J2trhisLU1Xq5t87l
UQxUNBhCjvRP2WuwFETd7rcyJKI7aJc6wmNkjhukW/YrrrbqYHcNZvKF+2I9Y2P3Bjdq6718s2jP
JSfMS8N/+W/cwxnsDlQs/fvM0KW0H71UzrsvFj3NNdWIXhaoePdSua24Wns33IbbihsGBN71N8Bu
sCJjrGwlPCK+L9LBE+lycB9TaosK8wGuAN2ZEuCc771UzhxtQY92IRDd9rVa2iNTu6x1ht842Gko
G8z6ba6VXuCvXKbhu513XxP7ZoBAI9oXkbIockrI95UlAdCys0a8Wgvzhmrz37gDXjNvSAwQ/UxV
FhgRTkLdvrZCnmZ5Q7VKRFWGM5hnVTSSORbOgP7cZviNRHfAa9ZL+I2wOFpTqTW6tSxDMvgxDU+o
zxesjupl9N7vinX1hM0JKUHrOOXqZc4e9CD6Ub1yAo93yKzj0pq/j5u9ROu4Q0Y7ibnm1ECXhR1X
1cuJ3TpmIQ99AG7FJ7u3aF9k4Wq1m0Xbx3JrHy3amTzf/7lhQDCsLob9dqaqBT0E+kwOv1HYO3Je
PtPzvhSv1Ujrrd1sVXkpJKF/a3d0B7xWjKqlkKq0VZm0Gb4K7KpMDo75S6yDaV/e2h3dgRgjwzpa
n1d8B1Bkjkh+iSV34EUO320pg1h5o4V3yACeYXGkePfNkEisO3awL8YKWIfoab/mfzG5w6CUImli
xUp43avf12ppM7mD7ZRC3YQ5buO79XIufBoNp92tKCg47QuU+bJezrRncscbW+fMhZaX9sbWOZ+Q
wS1L1R6+aYRbZmtSr69unZmIf4oLWULdRME5/KYRamnQcNgPMiWJTsjKkBhdDN9Hs2iht3td7tGi
ndnaF9/m+uvXjCjVJzJ/yfYax/S2e87WOKa33cGPxzEl7Q5+HKzIcGK9XPvBijUREsSizbdRG2oj
zCr6Eovb11buQ+gN3J4e7l4MesOSUm8rbtlYn5bD0ajBFm+WbhrsvtNFUEw5DijBQh6wPF2v45iK
SVMI18cqrYN93YDuxjEB0Qp5IASrRPuiwTQglYY77U0dJ/gxGL56em3ti6tlIFT3jVs2Fgt5iHeq
ESUKU1eJMOD3tYYmISIYJ+zx7m+BwjO9aHzllIq/aXugkBDJMHLC0zbjC+s1d0I7IgPMqlGtuXfw
jcosi2mdmgJ6KeRGzkV7dIesdAhzzRJxNHPJ0kxWahWcNjsPtazLaW9FQVfQUWtEiXvQ8XxC96Dj
+YTuQcfz7lnuk6YkT4m99w+7QGhZKLHu6xZ0PHOhQevBbG8por1B6xVpnl67WfUJOp55Aorljyrk
4Bsh5dKc2sO7bR2CoJRMf44rJYaBaxtQd7CvYeDaw9NrL/epr0oQmBKdtmWJvZtGn/dluA3vptG3
FTezykAZ15dvNRNu+V/Birf8rzPtDbdBc4nlquE2YJB/t3dTqFHFWd6hLfBF0DzCAntKbME9eSXC
GtfoHAmaB0koGuoTrdN5hLe0h9846DwqBsJ/liZXR5w0a/gi0xSCbpn8W7ueEIHuUue9jW6tmUJl
GmLRefdmCo2rB8/55TNTqF49eM5UpSnU8WpLCVekKSRXD54z7QXvEDll+tPewnaTDtjkT2gv5Cns
kVL8vvYuNvqjn2Sw+96sn6SXhXtT32L9JBdZuKE70EVeDIQ3oCqkCQ7I2rmeKXGZQjMtb9pqJuAd
0ibW1Pd8H/Eav7oBN7i5tnIfJk1Q3Y52bwYTDBP/8v35YDCNkqaXmHXtA0NXNF7REb4wVsjTmKfv
Vtz60wjdVTrcil9uKSvp4aO/Zgr9Vn7m+JGfGWGTf0Ztqj5RL4loVdyoLS71wRP/jNoMlRue+G2u
p4jTG0/8NtdTxOmNJx7sy6Lz1WCJgn3dMMBvc22m0Sc7cqxZrzfTiIneTf1ce3Ykq8uTeYgCShhS
eBk/WZFICL31KeGKlkOZZou/kbV/DEzFKxKsrsIA97Tf8MT7C+Is2xN+XNEaqbJt+ohOiNmRSa9m
nrdRTzB0sNBNmTnvqwobOTX/jZsJwnyAlqwnz5kShpeQy8o5q5nVcNrsoZWim1boY6nQ2OIVCVaX
oAc7qm7FSwpDWEbvId/fMy2DuW6Zlmf+MrwEiH57UD+jnvASmlQvTXbTCMbrVMskOVP1ijiNuvD9
Zhox4jQlvkNQiZgD3voM98WIUyuG0BrMVRMlk0WTb7tfi14aG+SNIZ4SKy4BkRDanF0izjGMg5QN
FvLM0dbnRbq1zQ3o9c7H9Dctysc83+17Pmawe5pGMtc7tCGFk79Sz46/tnw5mEZt5rp846pSs4CG
cOKhzGGm5WTHyhxRwpqnwj5qOZJMNKAyGzXl6A7BFsDbkXR5+VZz5opLjZrD3V9xqSkt3H2j63Ba
j6zzTbvnY57P8Z6PGax4y8cMdg8uLFPTiKkKLgS/pp/QnggN0OpSqJuwiSmslFwk5BzLtJxFQg3m
KuxhQmZ42pZp2etC1TVmw+ShLpJStHux3jCqpUacc2GTv82Gz4pbe1JWzSRrynk+R+I4VOjwvUby
yxAaap1eE91jXEQKkpzDF9liXC0b0sb5tRLr+lJa6uHuDdWqVe3ROYpVzaj1Ogu+0bq+QH0M76PB
9tUhPbyPb5xza/V95kKD7avDir3OVCUgXxqze518M3oMr4quz4gSmi3fd2ioT6jhVdU5ZrgisRcY
uSnhipX5vj318K3VyrbO7HUaUoImW06GaXOWE4q3FrfD0PaDFdlSFIph93rOhoZ+5Xb6W7vNRYQG
NpH00mSN44G/FHONUL8nbN+g2pFC2oO/EhsZ+Vu7ugSYF6RVZ/gO4V8zd3jok2T6Ao6DPJDmaybt
uUiPaemwl0yIn4vODCgwGf7nbdTWbov4ssnKyT6j9nZbTF7XMf2KW7stMvNI5ls8F+kRf/3d5Wwc
E2+vtqn58lydi/Qsxb2XGu8e5ktjEm9ML6ZtsgDV7WuPQhIL+WpJGFCVfjfY0KZwnMs7CaADwWUm
R1CImCAGm5VQfEat3clZiPi9DjqgKmF22Ha8hqMIsyPJiqg+o+rqMmG6vKQ6Y0rcjegjTzgj+lwW
yBLDWos/oR05AsoeoTZGxBNmRLdkqB23uf5lNY9ZTjYMtSOYi+K5EG4z3FdjZOdCLwgoIVZOltKI
TojmsVm0M6SXWmQne/7a5mLqvXUncnNt8UXwKjOyHX/t8cVPQuZtrg1fohLvuS2n/QQnmNjM0Y3a
Ui0J0dY0pgQNXxz28JTYDLli/DX9Hdr2VclfYsnDZ6oacoRcUKG3Fde5iBwB9V9auC9CANar3eiZ
CysME7UMw4gLWa6Iy3G5HY9caIbvbNZ3IPhG8ER6Q0wGtAdPlNytTVMw15jEOe/V88QKmTjNSXO5
Hc+UMCP6AqI8y1UramROUMiFNKIT0wLCF7llOhRr8TJ6i72xKRdxYeO5aoIkx/3wcz1EIcE4bYSv
lUUhWeHt+WuDEzS4t8tEO5fMET0eV9tzzt6Ui31HW/Ocsxur6WXwJeEdah28mtiXL6TXgJyoam0M
g2+cBtF25VoceRUCDjqAGiTnmXMMThD2o9Z4FCN0o5dQkhN0MI1kfWbO32hRSDZhqRHtGYUUmdNr
Q1vio0E85CvH6PhuSyP+erakwPOrYMZqnn2RvhvoIMEb3tGrMyWsiOUdvTpyjhmrmdHwSAIwbbP1
vLyi2wmxuT3ubC/h7gneAC1t0X23WGVnx4pWQo4GRdmxoi63dt09NSswawtXpOE7mLkdrqhsd4pn
xr9DmyGXKU2kS3jaZviyZcWMRw2iwiQvc/YGXzDkZjVIzts3bq27hLHK4uXEDjo42bOmeDmxgw6y
hSQeGM85W+sueRkgT6hHw15js9aWvaawGpjUmfA0tBTdWhqrUB1Vw7utFlKofejD7r9ghj5dva+Z
occ2FC419ViP4VJTj7nRLjX1mGdtcILvZtvjmEGdKQZxXy0yca6su5uh5xXvBua5gq11polZXeo4
Zj2DVtYoxPx/Z0rQdGwQhJ6qW5SWfpB5pZIEVXrsHZcN1SSgBJ5ZyHBDvQyoynpsnerPcTcdWY+N
uzjDFa0usFuHzOAb6f8rYs1jghWh7M3ZL6G05mzfDEymuY6Fc3a8+srqCOthMI5Z4pbmKvlKEjnP
ZdirpZpQOte50cDk2yIRT1j8lV0T/B3amoXB+JpsHxOP+lQP3va1dX1WPKBQ43pEe0tgbdD2ekgJ
PMZKSKkUfuOtLvDME2WwZQqU6JCjy2B1ajGM+WBft67P5xMCPxDdu8c3rSY+2WrIU+c7VBMrZkb3
HL1FColqL3MUDVdk4zHIVX9CezLsoLd35pD2hmoP/qp+XxtePZ0hJUtI+3cH6VpKdB8tzVWnYTcF
+zJsHTDBCKlqaa5X3en5tC3NFVb0T86RsdwMVbSEKw4mk/XLv3ys+KuQX8J+aBp9YwN/wc4e/lXY
kigZy23JYFrPu2f14Mxlesm04+Ekpncn/8JsMUBDzZnZ02vHw4HB1OaVhniuHmyJdfMGMXmWTBal
JcCvxKPYoJAOq4gLmVhbraYkpCpN2nebpjOvmkn7btMU0J4mbaviv3FHzWnEixPJEefQpJ3vNk0B
7SHlRuvVU2JviPaBX7yN2hDyP/CLZ0rc4RfPu/9ePThCXhWDhq7dc/RmorH3UJ9z0TG3DtI0cnLy
J7Qn1tLIeTuZz98odJnU0kPpaw3RsA9Pr716kN3O35la593TDB2tLbz6YIbOKhpr26wxHFC//FxP
kVXiRaRQYhr2PTSTGp6jJdaCU6c/xzXqyBrDOttC+zW6R6TBKYaudeYJGqtz4689SstuDuWK+J6r
B4mas3HOGlyB7vWyeEgoAd7YOtPf7W2U9R5iu/P7qLLSi3iEc0obEU9YQzRhD+mIJ5QFRO+65rNk
UkJWQwNII7rbFn/FRao5pD3jr++65mBfw1AxyyJXv9yz+snY+pJJO48523eT9jZqM1Y/CPmfUau6
dG+uNo8Z5wZ1M9T8pfOYs21QNwas7ObaIqtQ7cewmPM8ZpxnAn5psrrA4BuFvp5sSTTBXFDjrI9W
c3OtpqOJQTxXxY1ajWgTg9B7UziXicGe/L52AxOXf1Zrt3UbtRmYbFdzddsMKDHZruYq+J/HmoBC
WLDWTKE9f2PJ7BYsBkZ6/kZ2o2ZxhOaI9oxz5nwV/N/2tRpMFHAN19Z94xa3o+iCEa2eC7cKSRZR
j9n9ihtIKhP3piVpnWlvCb7SrXowoBe7UeOsh4aUYHMPBgr8aa9p00wDFuY6RJxTOiuDx1x4dUPb
B69CRlcNdw8BN/EYywx3T8/eGKbQBrsHFyZN2d+OHW2fPR8uMKLzCdVsLf5mC/d1x+Q/3w7cMRpM
yZ/jbqx+MPnPvHrH5D/ftApehdVrMJDBN0LKQYHuItFpM/46wfyx9KWxStyG7HliNWkh5UrRXEPp
C1UJStVIUyL+goB7ieVgh7u3Rm2plRbSyxq1Fct+OfOqNWqrVdIIqcpGbblZvDrgCTZqg6HdNPrG
llh/h8lCKdcS+9pWy3657WuN7mWDIrF66/M3gp5Ql6qBfp53z8jqTLDkesQTNFZBnrbcxw3qBmbo
qBq/yBZ/xaOgGp3jZax2A/08azCXsTrU3+3tG2mGFgjyEq7IvtwpW0w+2D2N1V7NcRfMBWM1NVHP
OU/Gap64tj0aZbCsrVsmzZm/mFKs1nswOiHGX6Eo5BHKQskGWJLFrZg2w5e6XOvqb9oawSzsWQON
QsNvZI/vBLMwlHKEeLXqipC/zPAFKWIJYIZvzrpIgPUbGZ6oc+GJvcc3W8OlIRrdWousEgnar7gl
C4P2AlLk8LRnhk4OoyD+RmajCcPtEb0U/CWVRlm0okG8Ds0zpIQZqxDUWSNpQmM1MWnNr7jGEyv7
q09ZdLktsspGD0m9zrTti7D4EJspXpHNbYn7EcpVVUNmSf6tXWExzcBkJUBod5iB2WUscmLdFx38
0IZaKMmVfYzeyBnnO9Tp4Kc29KSJfiGy+iQ4vmaGntuA3c3Qcxuwuxl6bL9iqbuCN6jdR+39wm/G
6rm52q0T+Dw2orl3Ap/HhkI0ViejVfM+Km2pu8QYTsPvfjdpWTNRht/93vSNeejJkOfnsUFOZu9L
KOP07c9juxrrDvKGGAj2xfrXJpaRf1txAxD69PgOeOLW4ztY8dbj+7b7rWZV2EfTEDHPJ1SsX+WQ
kaJ9WTu3Ni2B6cyrVzs3dnCJdm9Yqr10/407SirMFyrtKTohi3N27L+HKxIltenUGt0OwvngrK3H
5O0bn1BSIU1qjviLKKmKd1bC+2jptrNmf7d3/FMzQ1OPz3Gwt2q1Ko2AqpNdU5ulhp85pyZ2TRVr
M3eWAJaUS0j5Et3HmjsVtJJ7xF+WlCticfQzJYh/OgpYx/PqGsFk6u6c5nE8S0yLhmLF6eXEaqI1
QrcQny7cPSSTWBljuHux+L6lmZ95ggm+LJtMLeJCS/AVXKEecSFNx5SYxhyuyATfkcZPaA8uzFL6
Qvuta8kgkMrwVN37kRAxoCT/KmxmAt7H/obXuo1a43ZMymVIPpTRhqX6Bs4608uioW/grLMkh9FI
JGsDzgp2zzjnLNYZ9nzTrMd3YzuV6IRYjQomNISF4BtZjTr6SBLOpYRumX15H1cDEy9fM59cxPfW
QO7dcyXY12g/eq6cb5rFOWGHVg1PiFiqLV/OtrjNHD0+fsWnOCcOc6HXhn9KxbFpGdG+DBqoifWC
CVZkUi4eUS/Jd9CfRh3Aao/PVDVooDyt9vjMhUzKzT0nr8Hs6baZWRNWexysqGJOwFQi/hIiizAd
okT8BdHFrIk0YkqwghSXKMWUIIAQLAD1PLFFQynlYOWEN43ptkT+Xt7trV+4ceHo4Qtj1agGLBDx
qrKdLiwT6RHnsBO4gvIjlNFWjdpL8ee4mbSVGXdQo0OLwnBZ3zgfAb0aC3NUavg+amNhzoXzEVCV
WtoYdZlrq0bNP2LMwTcyGvqOMd/otY2Csard0OADqkIWEpnDy/sNOReyEJaOxvKe0dDccn+U91+I
hj4pGF8zQ49F5s4MDaCTbmbosST33i/8M2qFBmcFKSw0a5Eyj0XTzgw9w/cwwVfq5R3/fOPf1lGM
mUIbn+HumeBbi0HPB5S4R0OPkChM3U3giRrvnk2SWL7rd78aq0zKJZyDo9duYBIaolxq73n3rDqY
tfp97abjLc55hgKCGBywpFnDdP5Gi4biWk/HX2Vrw4Fr3YslOdzmWs6RcU5YXjpLPIpxzmSA2J9R
X0U1K60+fM7XLtlD7v3/+OP/AwV7ql9lbmRzdHJlYW0KZW5kb2JqCjMgMCBvYmoKPDwgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgL0xlbmd0aDEgMjk3MDggL0xlbmd0aCAxMjczNCA+PgpzdHJlYW0KeJzt
fQlcVVXX99r7nHsZBEFQHFA4F7ygAl6cFVFmzUhRQAOHBOEyGHAJLpBWaoMNZEmPadnwqI1alhds
QLOyx+ayLK00TbThyWbrySau3O+/9z0X0PR5er/3/X6/7/d9nsN/73X2Xnuttddeezh4LxIjoh60
ghSKL6osrM5759A8FKwi6pNaVG/X7v5q6XtEE+OJvL4tqS6tHHJn9cNE2j48h5ZWLCm5+7qYAKJL
W4n4qjJrYfHLJyfNhMRdwNgyFPT4mt0D+mdgcFml/cpy7yn1RGw8kW92ha2okPy2biZKG0jU+77K
wiur/Yt7n0B9P/BrVYWV1jvufvhHornpRP1fqa6xVvfziQwniv6WKDiNhO38vW+vinnni4UBiae8
fbxJXA/OtqWI/OlJ23u6Nv0xy3C/zyvg9QGYZEBq3HJ6PZG617XJFW+4Xy/vuhRRYohCkkQ1ZCBO
gWShS9Hr1dCrEFf3UqlgRC4E7mLetJQeob/TcXacD6KfQGezTbSLvUtbaDNQRTfRerqBDtLdePqI
7WV3uv5JQymX3qenXO9TKCXTIAqjYkqhOLSoQkm662PXSfAspSGoW07ZFOJ6z/U1hVAM3cU66DE6
TY+6trGHKN/1DeycTKm0FhiA8XRQBl3rOkqjaI7rB7qIKuguuhPyyeVE6xhqZnmcsVl0jet9aE+m
MKkphPK73TWQ5b5X6Dekdd5h+v08i4Ylk6mIjaFrqL/rD9yPs4fYYBrq+gAS51E2epoLnYPoMkqj
fjSNvFgvFkARqB9Om9ku1yG6hRrQOoOmUhmVSJuGuj50fYi2e+gB2sc62BD0/15p+33weCBbCu8c
pBfgySG0j4agRZgA7s36PVTeIfJewcKZH4tgkewL9gBbz0zsSRZO6ejTcnjmLmrmzHUEtgr5S+Gx
bHqb5bARLNm1CaNPclxSIVNwJ8MzApNd2/jL0JkvgN5NhoQwcAmk07UewLOjBGDLHHBVSAg52RgR
gRC0EIAVEpMx3lk0C5HyHtXTizTXtY3uZUGwg7NrPBApomQozXMd4mGMuX7kg/ggkbrhudk1fJDg
dj+djz7/zUuhH7nQTgE6nqSrKUqMNCxJoVZ4kaNPGzCmc8nP9ZHrI96DjcNseB31sSyWnmRjpI88
nvN4SSClG+IQu3FYjzZDYndUIZ5DER0jPP5EFM2Q/vT41O3Pqzt9qcP1tR7va+U4fSAjcjjbK8o9
EPWYTf+E/rmYX9+7vnX9xn5lj7MNtB/Pp7tu2i1nqp8cKzFLQyFRzNFy2DEE83QabIjBLP2dBtKD
FIUxfI9q2Os0nb6kYWwser4KT9dQPGxOYxpsfxyrwXT4ZCoVMAXULKAAdrvQ02T0arNcCzhmsi9k
96BoaQHWBugLIx/XL3IUssng+hgWDQWWop3gjEVP/TDHvnbtdx3DTIH/XEdcBzAKFbJ9BvrrD729
cBeSN1a1ONgTjdivQfthmKsxaJ8s2mNM/0CbVNdnNFquL+nguUuuCA7Xr4j6AZAwjKJRnk5m9C2f
m9nFbBqbxgezZ3Hfze4GlckH87Ho592clCbawd6mJlqA9S+brmMJ5ELPTYiaHLJjTsTSJdgF3qQ+
tJJeoD20imrpeqwN5XQF1pJJNImth28TEGM5lOPa7doNvnL9bpJ3d8ldci+RMp+iHV3ywLEAdXuo
mKexVayADWYvsBfoUYDYflYG7GcrgdXsA7aBXcQC6R2k4fQNNLxPX1MdODfz0ewfWItC6Uf6lPl1
bSVodVLeL7HdrJnNRhQQpC1m0zCi7sug50cRM+K6mUq67UTuaxz6vAX2bsFdivsJ3Fvpd8y3uXp5
GbsaulazIrZab6noeYzE/9DF7mGPyh1O0C+gv8fZTWwJvUZvsfvZW9JOUXMMtN4/VsUmdvbVkx+l
jefKWR0zC0gfdPdDlz+UM/Kzr210+Izc49tKcnvFm9yHhEbMTqFvLpsrn1cg9sXzXtgqLvRH9mUc
Iltck7BzVWI+VmJVBtg3GG3EBWZTA0bzA/g9FBGwkpVhxQ6Vo75aH42rEVM2ZkOrSnYAUfAS9rqb
WS3bg9XXh0eAmkNLsJI4xWos71mIDnebu3E/Ra/QK6ySVWKHfA07ij/2uwaay65EBJ7Gs/ueTVXM
l76j7zAK9zON2tnMbt72eEFESqnuP9HbLNwLMD/a2FsYrztQJNZTrJusiV0G3IO7CTOgid0IxLBg
rOaXscuUBpxZNrk2sdvZVlm7GLc/7hj6jYUAX3beTazpjOeuO4v1BWI8++dfxRl7x7ng2TM8u8Nf
xVk7xxmI6bqlDR755+DF6nCUDgBiLfTBCpuNCBKIw+2RIk5wEVin47CTJcHmoe7ok6MiMNB9IvWN
dZ9Ee4wk1TcQ41WNBy+qpmVsOWLrb2wTc7AjzMXz+Wv8Df6JwhRF8VEilWVKo7JK2aS8o/qpWep8
daG6Rr1LvV99UN2uPqceUr8y7DDsMXxt+NnoZww1hhsTjNnGy42VxiuMduMy443Gu40PGbcYtxnf
Nn5g/Nz4e9jKsN+1AK2PFqZFaFFavDZKS9AStclaurZce0h7VNtqMpiCTSGmCFOUabgp13SZaa1p
cwSPMEYERARF9IkYEBEeMTQiJuKiiMIIaySPDIw0mcnMzX7mQHNvcz/zQPNgc6x5tDnRXGFeYb7B
fLN5lXmNeZN5q7nFvNO8y/yy+S3zu+ZD5n9GJUYlR6VGFUQVRZVEXX7CcKLXieAT/U5MPMlP+pyM
b+ftWvvY9sT2ye0p7ents9rz2yvbr2m/tX1tu8vp4+zpDHKOdKY7s5z5zkXOxc5qZ51ztfMO553O
R5ybnY85tzodzg+cB52fnI4/nXT65tM/dTg7XDgjuDAUGm2UHt/ItmGN+AMefxUeP4hlyOPxG+Dx
25UHVab2VGepl6lN6jr1HvUB9Um1VT2onjA4DM8Z9hlO6h43GZONBfB49Tk9fjJsRdhGzU8L1vpq
mvT4SG1Cp8cfhMcfO8PjOaZ5pqZOj/eCx/tHhOkeL4golh7XzuPxmZ0ebzJvND/W6fE34fGD8HhC
p8etUYtPMOnxPidGYktTTwa0M3h8WPt4eDy5Pa19Svuc9sXtS9sb229vdzq9pcdHOJOcM5x5zsvg
8UpnrfN26fH7Oj3+Bjz+MTyeKD2+wu1xnDRIWePqDR/vUuJcR/ibRB1402R3sHqsNVc4sVt0lIs5
0hHTMaxjaMcQkEvpSuzji7FrXEyJzk+cR5z7nG85jznfd74rOJ3rnXcjXePchHuNc7nzBud1znLn
KKeZ6LMFRJ8ecS+Sx1YeW3t83rEbjv1+fPOxhmPPoqQJaDx2zfG6tsVtS47t/Czm2O1tm9vWHV13
9IGjt2LzekS0a+t79IqjC/EUfzT56Kijg49MOZJxJPHIhCNjj4w6En9k6JGII6FHeh9hh78//M3h
E4e/OPypaHX41cMvHn7hMLQcfuXww4e3Hc44nHo45fDgwxGHTYfDBuwe4BzQPuCPAccDX5AL+Qte
j3jd73Wf171e93jhDdbrDa8dXk94bfLaANriFeM1xMvX2GE8ZfzO+JXxU+Mx41Hjq8ZXjHuMu4zP
GXcadxifMf7deJ/xXuM042TDL4bbDKR2qBVijWFVZ220YW6c8TxEmdH5fN85919P7Y1Kq8wPnrP2
VeBDvD3fqDaqd59dq65y43yXWi+gXqk/2f+dHWe1vETttF+9+D9yx6pjzypZfKYV/41LwVnvBlqp
ltI6vHncSLfTrXQ/9ueHKJAaMRzX0xo6ibPkbThn30z/oCP0A866j9G/cPL6GW/EW/Fu9SrOgIuo
CGfdYpxqrTgdvEHv4NzyNu3F+0YJzsfv4s34Sez432NvP4Cz6n7s/1/h3HoLZkk5XY4zSQXeLjaS
Dafqapzpa6kOM6ge54sTmEtLcS65Cm8rV9OztAlnn2XY9a7FefdbnN3XsbsYZwpTmYHayYkT/nqc
Fe7FiaSDGZkX8yYXuw8nkb/jxLwR+5QP82U98Ab+AHuQfqFf2UPsYfYIe5RtZlvYY3jX2sqewBv5
NuxnzayFbaff6APWyG5lT7Gn2TN4g2jF6aIn28F2sgC8+/fC2/AxnDyDWW/2HNvF+rAQnJiex3n0
RZyyX8LZrC/eHraRg/VnA3DSepmFsoFsEAtjr7BXcWr+gz6lz1g405iJRbDX2OvsDfYmzkBvY21/
h0XiDcDMoti7bB97j72Pc94B2smi2RA2lA2jz+kL9gF9SG10iD7GKfMofUSfsB9wwv8Re/FP7F/s
Z/YL3h9/Y7+zP3BmamdOdpp14OTkEi/wnHOFq9zAjdyLe3Mf7svieA/ux/15Tx7AA3kvHsSDeW82
nPfhIczC4nlf3o/35wN4KB+Id/wwHs41voqbcHYcwUbySDYK71VmHsWj+RA+lA/jMfxmfouhpyGA
/6Bcq1yvrFRuUm5RblNWK2uUtcp65X6cDB5WtiiPK08o25Rm5Wllh/K88pLyivKGspefVN5TPlAO
KZ8ox5UvlK+U75QflB/5j/wn/i/+Mz/Ff+G/8t8UozKI/87/4O3cqfgqPRQ/7IQMHXsAZ4yH1IfV
R9RH1c3qFvUx9XF1q/oEdsFtqkNtVltwAnlKfVp9Rn0W++IOdSfOI7vU59UX1BfV3epL6j/UPerL
6ivqq+pr6uvqG+qb6lvq2+pe9R31XXWf+p76vrpfPaB+oH6ofoRd9ZD6sXpYPaJ+oh5V29Rj6nH1
U/Uz9XP1C/Wf6pfqCfUr9Wv1G/Vb9Tv1e/UH9aT6o/qT+i/2Gftc/Vk9pf6i/qr+pv5OzdTCG9lo
epqeoT3sC9qOM/fLdB29RDfRKfYl361eQ7toPU7X/6CH6W8siVazFOxDd+A8sIY1UCvO+N+x79Vq
9Qp1hVqjXq/asT7doNapK9UrscbdpN6s3oKV7la1AeewVept6u3qapwP1qrrcUK4V70PJ7N1OJ/d
rV6t/l3doG5UN/GjvI0f48f5p/wz/jn/gv+Tf6kMUsKUMcpY5V/Kz1ivjdT5a0smfkPFz1phUKmo
BqOXt49vDz//ngGBvYKCe/cJ6duv/4DQgYPCwjVTRORgc1T0kKHDYmLjhlviR4wcNXrM2HHjJyRM
TJw0OSk5JTUtPWPK1IumXZx5yfQZWTNnZefkzp5zaV7+3HnzF1y2sKCQFhUVW0tKy8oXX15RWWWr
vqKm1l5X33DlkqVXXX3NsuUrrr3u+htW3njTzbc03rrqtttXN93xtzV3rl13193r77n3vvv/vmHj
pgcefOjhRx7dvOWxx5WtTzy5zdHcsv2pp595tnXHzud2Pf/Ci7tf+seel1959bXX33jzrbf3vvPu
Pnrv/f0HPvjwo4OHPj585JOjbRdOxRdOxRdOxRdOxRdOxRdOxRdOxRdOxRdOxf+/n4qTL54zOzcn
e9bMrBkXT0uaPClxYsKE8ePGjB41ckS8ZXhcbMywoUOio8yDIyNMWnjYoIGhA/r36xvSp3dwUK/A
gJ7+fj18fby9jAZV4YxiMyKnFGiOqAKHGhV50UVx4jmyEAWF3QoKHBqKppzJ49AKJJt2JmcyOEvO
4kx2cyZ3crJALZES42K1jEjNsTc9Umtlc2flgb4tPTJfc3wn6emSVqPkgz8eTCa00DL6laVrDlag
ZTim1Jc1ZhSkQ15zD9+0yDSrb1wsNfv2ANkDlKNvZHUz6zuZSYL3zUho5uTtD6scAyLTMxz9I9OF
CQ7FnFFY7Jg5Ky8jPdRkyo+LdbC0oshFDopMdQTESBZKk2ocxjSHl1SjlYvu0K1ac+zuxlWtgbSo
IMavOLK4cH6eQynMFzp6xUBvuqPv0s/7dT1CeFBa3k3da0OVxox+5Zp4bGy8SXNsnJXXvdYk0vx8
yEBbbp5S0DgFqlcJL/azwBBhvuiKu1PWyAxRUrBYc/hEpkaWNS4uwIAMaHRQ9hJTy4AByTtcx2hA
htaYmxdpciSFRuYXpg9s7k2N2Uu290/W+p9ZExfbHNjL7c3mngE64effnbB21klKsgsqM7vTnUxY
FDkNYeDQijRYkheJjowXiXU8NRaNBxuufIZWjmIMQ7nDJ62gMTBBlIv2DoMZh9jGU1jUCyK/+/bM
kkK9xGgOPEWCFMHRGWCo99COmBjHsGEiLrzSMJCwcbJ8HhMXW9/K90ZWB2rI4D6amYdm+QkW+Nxk
EqN6a2syLcKDY8WsPPezRotCWyjZEpPv4AWiZrenps9sUbPCU9PZvCAS4fuUfJ3t4/CO6vwJCAwJ
zihLcLCQf1Ntdddn5kRmzpqbp2U0Fui+zcw948ldP76zTqccwWl5SijXKR6qyFpE4vxOZvGQ5+dQ
zfgxykgubvXyRijKEqZNcQQWXORO831Npr/YqNV1UrSSWVcz3UxHQsyZzxPPeD7DPL9GBQarUTwz
d25jo++Zps+IcfiZHT5mRIXD3+zoKelgc0tIz9kxmqNngRkLSEBnKhIWODvvQKgpX8vTHLnDsLIk
9jtpOZnomInp7uhhRryK1CBlBcjUXwrtY3b0NfdjgYnOxAmTLP2OnRRsvmahPkCm3mZHoNnRS9Ih
5pb+vYQFvaTuoM5UJPQnC4QBgYn/2YYA+dPX7Ohv7keBid5O0m2R64ODuZ0/M68gtDBfzDzxYzDP
znMYpXtNYhnV/dVTqgiUP26xuZi3jqwY/GCW5l/rnpkmd7NuFyQoUSxw2sS42EhQJCktKhI/KBFB
qRVgGpobx4dGmvJbXa4CsapKB/ACsyaqGwtARjpyhonaKC0Uy0FBVD6aKeCdgq2ksXFKpDalsaCx
sNW1YlGkFhjZuEMJUUIaqzMKPJO01bXz1lDHlFX5iMsylhBHO1y7lVPbExJH7kvprZzCdGqSaQBS
C5AEZAGrgW2AkZKVn1t8/EaKdj+3TEgYmeIrKEqkUa4VyHOQ43n7rOyR4SlhKEgCsgBRuQ8wQO7P
VAA0AaKpCm0/Q8PPtAH4QZRAxE8tYxOklp9aZuSOTJkhKBzMR8l8v54/o+cP6PmNer5Sz6v0vEzP
5+h5jp5P1vNJep6o5yP1fISem/U8Qs81PQ+X+Y8tOaOa0Nkf4bgC5SuqBlYACs1E2r2kCdgIOIDd
wD7ABxJOSgmhykkp4QT4T4D/hJRw4oySJmAj4AB2A/uUEy0+QVpKsnIDxQMinwmoaHUPWt2DVveg
1T0oIaSBgAbEA8nATMCImo9Q8xFxOqbsp5MAR9l+lO0H935w7wf3fgxe9ydF2cMX4oUqXHmIL2gp
DrfABy0Y8BYMeAtsP6YcgKwDUtYByDqA1gfQ+gBaH5Cyup4UZW6LUhzeqvyjJU1kL203FYcHpIxQ
0iA+DTGThg6loROakgon7UZ6DOCInVTUpkJIKjhS0eVUMihTlRiKQstEPofGIJ+IZ5EnKLEyn6Dn
45WYljHQE6HEQ0o8ojAehgco0XiKxlO0fBqMp8F4Ggwz45EORsto5KOQD1YixTMGUWsJ7i8jVmsx
mXVi+MiRzysmPpsmShbT9oypIwtSeigDYedAWB+thNJHAEdlaMuIkbJZaMuUqToxK2dkSi+lL6+Q
uvrwUwi5cKU38qHIg/U8vCUsNXwHS+F5GAVCHPnB235wlR/86wfX+GGc/eAeP6j1Q0T4ISL8EEd+
iCM/ONMPceS3vWdQUHIrf6Nl8KgNO/nr9AN/PXk210xsg+EHA9+AtwK+AS84fAP/gfMXjS968XBj
knGh0WZcbTSEeyV5LfSyea32MiTxJCWLZymq/B1otBarTTUEhgWaAiMCowNjA6caF6aU88sxiAv5
EWL8CLd5E7q1gh9GmcYPIY1HmgxwKkBaLakVSJsktRGpQ1K7Jbdos0I+B3a2E5z7gGOAIstlW36I
V0htGj8ILQfBfZAUfpBvlqWB/CPUiHkg0nggGZgJqPwjfo/k2cw/pFbgIKDwD/nlmFjh/IOW0QHh
Kaf5B3yOfH4b91u438T9Bu7X4dAAiTdlr96A7W+QC1AoCeUFQDXQBOwGDPDOm+jbRv42UgvSZKAA
EPxv0mrgRUBB3evAmygVshYiZbScX01LeTM0LedXAkuApcBVmEDLuR2oA+qBBllSDVwB1AC1sqQC
qASqAJssKQPKgcXA5SixQYdV6rBBhw06bNBhkzps0GGDDht02KQOG3TYoMMGHTapwwYdNuiwQYdN
6rBBhw06bNBhkzouhg6G9EpgCbAUuEqW24E6oB5okCXVwBVADVArSyqASqAKsMmSMqAcWAwI+QlS
fgLkJ0B+AuQnSPkJkJ8A+QmQnyDlJ0B+AuQnQH6ClJ8A+QmQnwD5CdzWrCakuKAgAQoSoCBBKrBI
BRYosECBBQosUoEFCixQYIECi1RggQILFFigwCIVWKDAAgUWKLDIDlgg3wL5Fsi3SPltUn4b5LdB
fhvkt0n5bZDfBvltkN8m5bdBfhvkt0F+m5TfBvltkN8G+W1Sfhvkt0F+G+S3SfnLeSkC6XHgSQTX
cl4EFANWoETWLwQKgEJgkSyZB8wHFgCXyZJLgTwgH5grS3KAXGA2MEcOfSkthh6r1GODHhv02KDH
JvXYoMcGPTbosUk9NuixQY8NemxSjw16bNBjgx6b1GODHhv02KDHJvUshJ6FfAvNhS4xWYqAYsAK
lMj6hUABUAgskiXzgPnAAuAyWXIpkAfkA3NlSQ6Qm+JCOhsQmrKgKQuaLpaasqApC5qyoClLasqC
pixoyoKmLKkpC5qyoCkLmrKkpixoyoKmLGjKkpqyoCkLPcqCniypJwl6EqCDgyoCigErUCLrFgIF
QCGwSJbMA+YDC4DLZMmlQB6QD8yVJTlALjAbmCPjrpSGSR0W6LBAhwU6LFKHBTos0GGBDovUYYEO
C3RYoMMidVigwwIdFuiwSB0W6LBAhwU6LFJHG3R8LHW0QUcbdLRBR5vU0QYdbdDRBh1tUkcbdLRB
Rxt0tEkdbdDRBh1t0NEmdbRBRxt0tEFHm9DBr2aP8KvYAMySdsyWPzBrNmFubMQc2YC5Uow5cylm
xlTMkDTMlETMmHjMizjMj1jMk2jMFzNmRQRmhwmzRMNsCeOlkFkCmVZqT4mE1X/A+k2wcSNs3QCb
i2H7pbBwKixNg8WJsDwe9sXBzljYGw27zbAuAlaaYK3Gc5L7h637rTj8FqAGuAIYAQwHWtmA5DE4
GbUDG4GpQCIQD0QDZiAC0IAwgEJC8IIc1Ms7OaUvn8RxDiB/9rxMV8v0dpk2yPQSmU6VaUJy35n+
z8/0b5zpb5vpv3Cmf/5M/ykz/RNm+j/HOmgZOL5MHrTMf+0y/xuX+c9f5n/xMv/UZf4py/wnLPMf
u8zfAlpj37JEMD4g03UyvUOk1C7T32R6TKaXyTRRpppMw1hiiz/5tLJTLaZJ6PfPLaYsZN+1mBYh
29JiGh2+iz1CJpVROHuoxXQZSh9sMWUjK20xjUFW0mIagSy1xZSGLOUpU3z4H6ZWlSUHhB831YS/
b7o43GGaEL5JlLWEb5BVPcJrTDHhVtOw8GJ38aXuLE1kz4RPMj0eHucuiXWXzA72CfZpamU7kkd5
Nb3m1VTg1RTv1RTj1TTMqynKq2mwV1O4V9Mgr97eQd6B3j29/bx9vb29jd6qN/cm796trmPJseJf
5Xsbxb9Zk1EVqSrpQC5S8Q/4jIgzb04XU8FOPgnHhEnNfJwjWMnkmTmpLNOxu4gyF2mOX3IiW5nv
rLkOQ2QqcwRlUmZuakxtv0xH/5xMR86suXmtfJJjRXqmhsvRP1s+7k7Pd0RJspUR6JE6nQw6QadX
gJ6q0+DPd4yLyWz1cmU7xsdkOnxmzstrZuz2fDw5+M2QkpvXylyiaGWo+NXdDmIsfOVtoSJ3rbwt
P59C6pP6JQVN7jVhSvo5kgI9jem6+nWRQvfMJcl+4U96hWd4hY/yCo/0EuWZOShsetKrKcOrCQPh
Luw3yLEuMyfP4RqEjulEJkYtR5uft4Mn8UkZ6Tv4ZJHl5+3ov5EnZWSL8v4b0clOPkzOJPBhbibp
fGQWfGQ+iy+CTxZ80SJz80VIvogz+JqnmjLSm00mD89UyTP1TJ6NZ/JslDwbdR7FzWPqxhM8nkyS
xxQ8/k88EX+BJ/qcPDHnu6yp563qfrEdlM3amifWi9+yFkRmWIECx631Zf0cKxZp2g6ayNr0X8BG
FSwqKhN5obWVtUVa0x0TI9O15uz6P9c76kV1dmR6M9Vn5OY11ydb01uyk7MzIgvT87dnlSZVnKHu
Fo+65qTScwgrFcKShK6sinNUV4jqLKGrQuiqELqykrOkroxyMftm5jV7U2p+2nx3vp338EXUF4Sa
8lNDAqsnyykw0dRvWehOldhm6hGT7/CLTHX4A6IqLiUuRVRh4ouqnuJX6HpVv2UTTaE72Wa9KhDF
vSJTCVPgT1dG+v/8bZdX7V+4/goneert/TLK07v/yEkdY4+pxU9MXacgPEEw1eoF9toYgo+T/Qqi
C2ILpioFYQUmXlubLwqfx1uVeOsR71cMZcxOCD7dNWioX5DiJkiII1EC2cydCRMhaieRsgxC8lmt
vQ6MSM55eSokl/olkfo3CkUepiyS36ds0/FpxzIS9X06TmMR/wiL+V4d7quE9rJoPIt7HT2GNB+4
iW5iN7L+snQNbUG6lG6gO0UXabl45WN5tBVv/nvpEMXQHPldxd/xFESvon6v60dKpf2UK/mHoOwu
PL8svvPHw7Gh7FXNtJ+51G9YkPIw1bPl7F/KQsi/CxI6+Isu8X21lXSfd6zrSYqiZKqkq+kOup8F
sAhXlesQGSkEujNcD7tep0LUNlMre0KZqV7j2oCWOVRFf6On2HC1QH3j9Gcd17tsrvfJj26hR1gP
ZhJfGDQMc11KA2k8JdF8esvde6apQ0+7Oj5xNUN+DKVA0nJovYP+QfvoR5bO9qtRBupgrnDXW66P
yYsmo+1apuAOZBFsCnuc91XeVf7Ai3M/morW88lKpWSjGnoU91ZY+QMbzcawdJ7OF/Cb+Vq+R1mj
XqMuw8gsp+cYMZUNY8ksk+Wwx9n77H14a4lyTQfBHg39TaMMuoQWyO8MraPXpdWH6DRjsKCE2dg1
7F62ke1lx/nLSq56kfqNq8R1g/x+ZBD8ZaJomgQJuRjfJ2k77UDr49DYH7aPYkno33X8El6vjFZm
KvOUq5Um5WHlgHqp+mTH6I7vXStdm1y7XB+6Dru+g7xeFEFxlAlP51IeXYWRu4MegNSX6CP6iUWy
VFbFrmN34twlPiewi33IOrg/f1wZq6xRnlGZmqyuVV/t6NXxYEdrxw+uDFe+y4n+LaLr6WZE24P0
CCLuKUhrY1PZJWwWm8sKIPFGdgt7lO1h33KVz+dPK1HKFcpS5SplrXJKNatL1Q8M9R0LOtZ07HDF
u2ph8c2ur+X3QvvTOBxccukyKkdkVFM9XQmbr4bPrxOf6pD3bejBE9D5LD0Hvxyjb+kU85GfYhjE
4nGPZ5PRqzxmZ6vYevYQ+5R9yX7lDJbE8LF8Bi/FeG7iL/P9/LiSq2xVdin7lf1qiDpdnY0ofFR9
0kCGXsZJ3m+3H3JuO3336Xs6eMfQjgUuL1eoa6Brqmuba4/rkOt7zFyNYhGXMzCnrqYmRE0rRuot
ROA+jPUX9CViyCA/UzGYRbHpbD67Fp6+Eb6+jz2IewsiZxtrxb0L9272CtsH73/EjrEvWDtD8PIo
boHF83kJv4pv5s/zPbxD6aGEKpHwZ6JihU+vUW5SHkEf3ld+VH5Ve6rBapQ6UbWqf1MfV19SD6nt
hqmG6YYGYy/jKuNqfeXY2/3jMiyDj4Z8zvIx//3g8af5qzwOM2Lv/4H7FvYrvc5S6Qt2GlF+C+5r
6QTm0aU8jf0TkfQAGyc+e8kVvB/dwnbTRtqkbGUf8utpFWb/cPoGKeNlbDi7mQ/EangH306fITL2
Yr78yKeC3ouR7kd7lb2sGm8MP7HbSHwPu4D3oVL2Po1nN7N0quBDKZLsbC/JT2YZklVmmIf1tlSs
vepa/jVfy37AG9gGafMqVkgb2VDE2142j7bxNnWs+jyidApm6QBwZ3MjW4LYvI+r9Ch/FbHbjHk2
A7PiLszejZgnKbB6CNkpjc3CqfZX5kO92C2I9sswM2+BPY/T4+y00gFdU1w7JU7weMT5WhKf4NpB
g+kx1+30AluEefwU86X76Dhdovys9sGOcVIdZMhw8Y5FdNA1i97EihWoHKWL6DC7FevGRfQxC6F7
XRWu0YjGva582HkDldFsQ4ohDKtxId5RX/LaaDxqTDSOMDLDUkOxIduQaUgzjDOMMAw1mAz9DQEG
X/UH9RN1n/qC+pB6HebucLWP6qccxfrZrKxXblVsynQlSRmOmBykqPx3/j3/ih/hB/luvoUvZw5Y
edj1umu9a6ZrkmucK7ijo+NUx56OJzvu7VjbcXvHio7qjoLTLzs/ce53NjsfZr+cPoj16yX2Zkc7
9oA611zXJa5fMN96u9a4JnV8xFajj2Y6jfn1NtbVNRiXh+DbPKxwyVx8r7aDTtF38NCHqN9Bm+Vf
BSigOcZcysJ4R2FmXq9HoxVr7aN4UjBWQdgBkuDxSzAm80l8/ioaO+3LtNW1SZkNGc1ysjzK32Va
x4MUjVWmCvtTJn3GJtPXuJ+ip07fI75pbXwUWncYt9Ap4/1Kuz7Jiv/fAl91ARdwARdwARdwARdw
ARdwARdwARdwARdwARdwAf+Xg4tvwxjEH3ZTyIsmJocZvU6izKCeVMjXaDipKHyAj5d6klF/78yr
+sXMCPw5cfrpxBmBvyRODzydSEmJpxMFRsSbepl6mZEwUsmpKbudyeK7q5q6mzgN6XhPfUQ9TMNo
LLsxebbvIP+w/mH9wkMiFw8y1vI7OU/n88LyIirC1PVh6yLWR60ftj5uXfy6kevHbB304qDnwl4z
HQz3nx0xL2resFL/skH1kasHeSX7Z4RlRFwclTlsjv/sMC/W6tq9vX/CaEKe3BfEoOTQhNFBV5qY
gffm21kzV9NRtyI5clbO6EErJiIJCTYwMsaMYAE0aHj0YGWQd3AwCxgdTX1beUdLQLRhJ/+JvJl/
C/nEtPK8Z3uMHjJg/IBHR4BO9g/XsrSFmqL1HzexXrplwfTTX8At0z//jpL++cvpzwO/6xU0wZKU
9F0gctYrqO+EmJgR8ZkO/5lLkkeEjY2IijKPGRYzmI0KGzGYLJFI4sx4HDt09GD4aWQ4srB40/DB
LDYaCcXEJMYEJnr+jfpaumJBmvgICUevA8KSZO878/5JXM/FcwucIRvli8YLFixAW3aFwWtk35BR
I8eOGhnSp7eXMTIiOioyQuRRY0aPGxfFxwSOQ13fkF6BFDwaVcY+vQU7X2dcvCCq/+CysJiJ4yqr
xk+YP/bSFnOf6IlDrn9g796H9r7z0N6ON8s/bVr96aermz4d6BMTlD4xdkz0jJDBcT6Thg+JXj6F
Jb7Dhu26665dHR+6qONebn3u1C87d54Sf9qZFqpLyfO3Kjv0b3KLDzOFsECd5hiQIeT5C3fFkkvQ
KmmdPAbqxxbptJGimEemFz3CNuq0N0Xx93XahwZ6/6HTvjzMJ0Sne1BFj9E67UclPTxt/Y1P8Sk6
3ZPm+xk7/4DKcr9FnX8buoff1zrNSfX7RacVGul3XKdVCuzkMZCff7BOGynYP1ynvSjHf6ROe6P8
LZ32oZ6BbTrtywICv9PpHjS2l1On/WhUkKetvzLXf6VO96ThQVbxFwFVBbb1DHpcp1WKClojafGX
qn2D3tNplSKCdkjaiHJj0L90WqWwoMOS9hLjEtxLpzEWQb9L2hvlfsEjdFqlwcH9Je2jj6+bdo+v
m3aPr5t2j6+bdo+vm3aPr5t2j6+bdo+vm3aPr5t2j6+bdo+vm3aPr5t2j6+bdo+vm3aPr6B9ha+C
Z+s0fBU8SdI9xL/XB1+l0yoNCy6StJ/0ycM6DfuDb5N0T/Glg+B3dVqlIcHPSjpQynlYp4UcN3+w
8HnwrzoNnwe3Sbq3sKd3H50W9pyWdB+U9+49UadViu0dKekQyV+q0+DvnSXp/pL/Np0W/HWSDhUx
0HuHTiMGem+S9CBpTy+dFjHgHutwyX9YpwX/HkkPFjHQ+7ROIwZ6fyHpYcI/fUw6Df/08ZF0nJDT
J0WnIafPUEF7d/O/dzf/e3frl3e3fvl14/frxu/XbVz8POOSS0uomqxUQoVUhFyjLUAulUl6Otmo
CrDrXBqlyU+JVMu0EOXlkkNDSQXaDweVLssL/5uSLJ2WaZSDmgr5FyTcPLUom4bcrW8ETcAdT3E6
NVKWpqBFBfJstCmFDXbZKhvyaoEaqkda/CerEqRVdagvl1wazUDegDxV2lAMjnpZU9tpr9A3HqlG
QyCvHFbVoKYWKIFc8XdJz81/pia3npnoa1ynrunwwRlcpgjpUeGvYjxXIq+hy1EmdP3v+1pDqfj8
TzmstEtrhG80+RkUTUZFjRxRz7OwqAolbqtq0Z8ZlAXt02gKkAbfCzoLpRrSKUgvkeUZKMlBKkZH
fOooA/d0WZpL/uQrkSv/orQYK/ufItNT7u5ltfRztW7dkk4v/Ln37kiyoYei99VoL7gLweXupTs2
6mRkaLRI1i6RvfToFH2u7+aZOtnWHSEee9yeq5T8bkvEHKiQEWGVUWuVZaVSihg9q/SiiNZ8XVsZ
6uslnw12eHzu1mn/N57xRFuDjAhRYpX9KtNtLMaTKC9CWYXsX4n0XuU5/WXT+yU8Zu0mpUGXeS59
xXr0iJhYJOeq2+pF+shU6ZLPNULRsldnesodV3+Oij9rdpcLX9cjFetEIbRW6N6uldLs59UtvD8b
JRVSY223ke8aC/c4nTkvhHfcWmulnCKUlsge/JUx1/RYrJJzsQpPXXrF3C6WnnbP0kK5jtV0W8di
O7lrusWtu3/2/+gpYV2llO+JK9sZ8hrk+F8uR7P7WlGix0UXpw287lWkTnpcyC/r7I/bru7RLdYr
EQ1u/7tnVbUeH54oPTuG/l2PuuJjmuz7n0dOeFjIvwLlVinb05simbvXtqqzxqDmLH93SRb9E1SF
9JywoV6ugQ3d1oG/Mvoeee45KeZqvT4aXXPMI+/P4+j2lrsHdrkG2M85jz0jVniWr0v+S9Z2efnP
Goqkh8Ust/7JInd/RAQldEqYjfU/BaVxJHbL8TSaxmGH1JCOwFMcdvHRQDyJk+tsytQ541E7AjWj
dXocjQJEq7E0Bju+gJAuRssOyxJwerDAX+Iejn6cPeOL5Mp3kYxf4VNhZ6ZcJexyHajBGcYqd+zS
ztW3sHOV8chpkDFi19fGrrXY4/Vp2Meny7l69pmiQZfmWTnFStCg+1GMUIosK9d9OwW0++xT2qmr
uwZxPrJKu4v0uVMko8babX/WpFSP7eVy3CqkpHK6Uu9htexNkYy94m79j5Uz1+NDz0ruPgs0yNh1
z5OuHbUWssUa3GVFCXWdJjzzrlrf+8T6W3vGWiRir07K8KwA5/K4TXqlWqZdPqmRkm3yTOBeKe3S
Fre87utbl7126bsyuQ54PFMMriK08syCrpVw+H8xziySX/xFNAtSu1zRhVSLPCss1M9Tnuiokv0c
3tnmf1ZXg4wUN6/1f0SLp85y1krSKTt3SbW1pLDIqm3Rcsus2nRblc2OIi3NVlNtqym0l9uqtOqK
ouFaeqG98D8wWYQwLcdWUSdKarVpVWg3YsKE+DgkI4drKRUVWnZ5aZm9Vsu21lpr6q3FHlEJaba6
mnJrjTbD2qCl2iqKE+qtNbVC7sjh40dqQ6aXF9XYam0l9qFzupXrjdBmZk6caDU9Vy96TMutKSy2
VhbWXK7ZSv6t1VqNtbS81m6tsRZr5VVakbXGXihyW12VHaJqh8/Iyp02ZVpaSu60rBla1hTtkmlp
GTNyMrSUqdkZGdMzZuT6+/r75paV12p2jzMFDZXVNbZqiFsiTOhUDyfZSmsKq8uWaIVVUAlv1NVa
tUVLtCW2OtGyyFYvjamrKoZDhBwYV1krhBRqFeVF1iqwF5bWWK2V1ir7cC0fzcoK662abZGwHC3t
Zxgj3NZQWGPVrOUQVqMVl9dYi+wVS7SSGltll1026LKVWiVLAzi72hXDPTXli+rsEA0zbVXW7h2K
rvUYBV91uqKzMehCrb6woq5wUQXMrq212ru3Hq7Nrqqw1tbKzsteoE/6WNhtaFpbbS0qLykv+nPP
NXixyl5eVSrbFhYXl4shLazQamSMxYriGulb6LOfbVRFeWW56BCUSL4GW83ltXZ3VJTAF7LQ1oAQ
qVtUUV5bJvRAltvdlYVLNNiPoapeIhzX5aEzFUl/TCvp6lxh1RLtijprrVRTZKtCtFXpPajR7ZbM
tWW2uopihGZ9OSaEiIE/d1/wYSSt5ZhH7hETfJ19hFlQYC8ssneNsehYoW51ybnFSpM7GxQVVmmL
rB5B0FNoTxAMs3NStDhtyPjR44Zq40aMj4sfHR/v4zM7E4XxI0aMHo103Khx2rixYyaMmeDvW2a3
VydYLA0NDcMrPQNfZKu8yAZLi7VMq91eYa1Jt9aWl4rwLRQhI3gaajBENZqMYmH6tNTpsZpnpWgA
mwjOmkIMEsIypbimHNZOqcHqUypauRtoOdYKhHsNIghLjpjPmpYipJcXIVRKyq+Ewupye1GZViz1
x2rSQhHkWAUarGJM5EStrShcJEWUyGVCjF01Zp82u9YdRdbKuopCEQBdhtvq7NV1dmlJjRVrjghK
e+Ei8LnjTcq1W4vKqqQxxbaiOjEEMgiHn8dnljJ7ZYWl0i7+80BLZe3CIrc7qqwNw0XNX2zVYK1A
qfU/NxFPFj1IJPd5fwUjcvfhVGzH5+OyUx3zxyb01Xk5SuRh43y1U/SD4HnqlZuV55WXlReRNv9H
S8v/raWXoMT9qmKTnHXn5Zwqj4ieV1lxSDq/9V9hI76cfoHUr1BzPr45UtL5ai+Sh6B66anzc83U
f6UiXv7cR6Mlf8kj57VeDVcnqxPVNHWsOl5NViepmeqE80rM/Y/jnCl6wUaA5/wc7uPi5ee3ifWi
T5VIHGTOP4o2+eJaSET/C67LVeJlbmRzdHJlYW0KZW5kb2JqCjQgMCBvYmoKPDwgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgL0xlbmd0aCAyMjYgPj4Kc3RyZWFtCnicXZCxbsQgEER7vmLLu+IEduLOshRd
Ghe5RHHyARjWDlK8oDUu/PcBYl2kFCANM281rLz2zz25CPKNvRkwwuTIMq5+Y4Mw4uxIVDVYZ+Kh
ym0WHYRM8LCvEZeeJi/aFkC+J3eNvMPpyfoRz0K+skV2NMPp8zokPWwhfOOCFEGJrgOLU5r0osNN
LwiyYJfeJt/F/ZKYv8THHhDqoqvfNsZbXIM2yJpmFK1SquqgVU3ddALJ/vMPapzMl+acfnjMadVU
JX28Zy7/717KbMypT1lCKZIrOML7noIPmcrnBx88bvZlbmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoK
PDwgL0Fubm90cyBbIDw8IC9BIDw8IC9TIC9VUkkgL1R5cGUgL0FjdGlvbiAvVVJJIChodHRwczov
L2dyb3Vwcy5nb29nbGUuY29tL2EvaXNvY3BwLm9yZy9mb3J1bS8jIW1zZy9zdGQtcHJvcG9zYWxz
L2I2bmNCb2pVOHdJL2JseDFHbExxVUFVSikgPj4gL0JvcmRlciBbIDAgMCAwIF0gL1JlY3QgWyA3
MiAzODMgNTM4IDM5NiBdIC9TdWJ0eXBlIC9MaW5rIC9UeXBlIC9Bbm5vdCA+PiA8PCAvQSA8PCAv
UyAvVVJJIC9UeXBlIC9BY3Rpb24gL1VSSSAoaHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9hL2lz
b2NwcC5vcmcvZm9ydW0vIyF0b3BpYy9zdGQtcHJvcG9zYWxzL0NEYlBDMllnaUhFKSA+PiAvQm9y
ZGVyIFsgMCAwIDAgXSAvUmVjdCBbIDcyIDM1MyA0NzUgMzY2IF0gL1N1YnR5cGUgL0xpbmsgL1R5
cGUgL0Fubm90ID4+IF0gL0NvbnRlbnRzIDYgMCBSIC9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0g
L1BhcmVudCAyNiAwIFIgL1Jlc291cmNlcyA8PCAvRXh0R1N0YXRlIDw8IC9HMCAyNyAwIFIgL0cx
IDQzIDAgUiA+PiAvRm9udCA8PCAvRjAgMjggMCBSIC9GMSA0MCAwIFIgL0YyIDMxIDAgUiA+PiAv
UHJvY1NldHMgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gPj4gL1R5cGUg
L1BhZ2UgPj4KZW5kb2JqCjYgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAx
MzA3NiA+PgpzdHJlYW0KeJzFXcuuJblx3PdX9A+4xPcDMAxYtkZrG/MHhiXAgBeW/x9wRNa9fSrJ
w+g7o4VnAGnQzUOyksnMDOYrfg/49x8i/qfP9P0//vvb/3y7erU/vf//H2IdhX8Rv/Pff//z9/s/
/vbXb3/4c/j+1//9Fr6nGNP3Edv3GGr7/rf//PaXb5yAf5JjG59/8nZYSmHYH84WXj8NXOj+Dyz0
x1+//eGX8D2Wq9k/8/uvf/kWP7c+GyZJ+fuv//3tH0PI/Z++//pfr7+NoVyzppbic1T54zIq5ivi
t2m6UWMZleKVahm5P0fVuo5qV8wYluRcuVxptDrDc1TI66hx5Tpqc99Y/mUZVeLVYumxun21ddS4
Zkmj6BVrvgKGRr/iOlcLVy5pFkfVun5jG1eZJZQp6dXzlXtps+hRA7Sv2e9+o+poVwmtlOHmisuo
Wa5ae63uG+vKOXNcLc2aPef84kelEK+BAxqeEv+yjppXwmGGpmiPEeCJ2pe5lt0ncGHJbQxP1bSO
mlcdfc4uV8z5Ag/OnhXnpBKuOUaYQ9ErlXqFFoKfq5RlFPgLgiD+5BtbvHJLOTieKOuKDd+Ii5S6
XLF3yI1Sa1D8lUa6aqnRS5NtxRmuNlvytN+oCv7qbaSF74MflUO7Zu8hSY7OsV4xDYpOcR9zSlep
IJinxCLlcsbucT4tKHplyJwOoT+yOqFcsPsAoS0lU67hiq32HhV/5dohJ/LwtN/ohdMGtVqTHJ0h
TTqkSZW8msETo7QWh7pDedQLd6N7KbetCJ4IbWJrinMypAl1XarqtCG7IAshn4aaq0ATVlwOT9WV
9iV2UGKmXBXnlAT++ilPFMiJtPPEuq/cL/BYKUV+I+QE9EvV51gK7nbNVd/tAs7p+KYqdVqBNOkd
py25EBoIlCggheKJAs6BHhrV3+31G8E5OMvpbYBV5hRwThod4kSe0IT8ilBXWVG1hgqZ00apihIV
emjkseihMpdR0EMTTKGtjgr+ijDGtH6sKVwFvDol39c0rtpL8vdx231OV8Nh9qm4sOZ2deiXLPVj
LeUabcIwlCuazRQ5QHAhbIkr4KIVqd0ruDC2kj3tVy6sZjOlkuXdrh0cDSZbJGZcR+G0IcCit2r/
eRk1xgVhO0qS5zihkUMPC+es5zgn9NCISerHFvJVcwje9l0p0WK4Rh1psWr7Ogr2fQ6xV3XTWgQl
wNFTUhX6E5K8zVoVVVsGCogj9KGo2vKEBTNhHkpKlHyVEmOTtAfPw+roOcn72CAxYa0W/40bvWq5
QqKlo86xtXTFDsUtbXKoYnBOT1XqjtbrBcWX/VzbN8K+L7DSspQAjVZaxpdOSQlIXyi+1t5ZMH/6
9Sd4cgEiH1v46c/sKpYjmAgwEnARjU1/jNpgaKCRkIOp2XL6PFjPV6FiT27FFaLFcYFJYVs9R21w
D4YjUELObsXV9AKcvcLABSpuX8tBRzBzyjNFv68VfFUIkhmyCSUxCuofdk5yu9/gHhgQd6xmR9Ud
OoJper4hx49RcV2x45LhWtQm6TUClEuPnvb7KACAARU6nqO2p4kJUxVWWpqKJwxgznQ/OhwpkSAs
Q8mzSEokCkvgtBnlXBSDvbY51DemBPVfeuuSJ2B9XmmOPpLcFwAmtHpJQ+4Lyhjm5XLa274qoBAk
XIxyXy3QvGyeC7e5Gu56guIObveLuZSgjCF4u9/XtiI4Bxdo1CEpAc6ZA1i1KAmQoLJTiS1rek2A
iZl6c5TYoBAkEwRvT37UCuRCp0gdRd6ODMk0WoHYcXOtsAomYcAFz46qqxGaExQVGGcGuSIMR0w1
alTSJMMkzDFMz6vbvmASlpbC7HIu8FfD/U9uX3EFqx+Qtvn7uAJf8BcMnOm/cTshmIRjAkBKjiak
DZBfnnO23UM1xtnSctM2sJqvDCRU5YoFkqnMURaqriDHIO2M/qa9hbQ5LLpjA3LQaQ2DupcmC+1h
YtPYmyWr21EyTHucdnYcvYEvmF5phujv0CqjC4wqmHG4HpJeMKoqxG+Q/FU6NEzJdbkdK7jvgGhz
3rbKkb8As6+c+lh07UqvSXP84yn6OFeFnMDdvh+ZjydU+dyeWw/SGiIMDWG01hRVDWDW2f2+NvCV
qt3tmOWKCeb4ANjOcvcZ5jgf+LNckc/t0ALeslr5voJzCu6/59UNMIFzWu5taqrWcfUwW/XSZJ2r
NZxQ6H3Ic+zligNiVd4O4C5IgBBSU7cWLAMJEGNx/LVaVpXP7UBNUUryyuf2XAEx1SjcflCih+zu
42pZNegh8PP9VHjkLwcKj5RosHMmhkZ505rZOdjJlHM94d75G0vnszZMc8XRDXZ0HXXFCuuKsKN7
hpiTUs6AHDaXpZQzIBcBHaWGaQO6o/HNV8mvNmBtw4QsXm+v0JEP6R1atCi+7+AJiFVYmYoSHTwR
YAvFd1Lup+iux3fG8NdAYTsRYc6LxmWZ6Tlqg0IwvaAzkomb16jFXMIlxEEDPvu5FhPH4B4ttOn2
9cs6qsG0x99PuSKFJe6iHU47kd18kykOe6tuJ5aPpQLIZdgSbsUVMBUwc4Noym7FFYbC9Jrx413y
NepPK3QEM5caqjwhejBriClUeUKEjjXl6Pe1vAgRFI6QS9KUgGk/es2ec3bfJFgeNkB3p/0OOgYY
aCOoEzLfZJl1DLUv+iYzbn/Lir/MN9lT86e9gRzwF1g1x65oTw9mgxXXmqJqygAm0Ma9yLnAhTDi
uueczesI/sKgsXDO5sHsMDhokKs7ZACz19sbeqYqASYuUfb7Wv2vBJi9xjok7QkwU0vD0349bULH
3kso8oRgEmK5UD3nrPCF0HG0++31yF85ULGDKSR/Qd3RxLmByWuuFRTGdsGcjZ5XN68jASbxeFYn
lFOGygbGGXL3GRwNFFDkrc1Q/zW2FiTnZKh/qNqeiuJC7AhmyVhk4QbRoNhh/s8e5L7AX6HERRa+
A5gx5jGjkiawUq/UIA2lvIcMvwrgUu7yGyG/Kq5j07ufkKsYmuTuYaVe/TOi4MjRJeCEZhypqxMq
kU9yacapdg8RDkCOK5TUrcU0V8LeW1dcWHKCxATiSHJfJTAWpdQqKVFgA+B8otRpBeYlsEv1WmH7
xgobIIwepE7DvYAJM0dq6hxL48Nd7EPKe0BLi1ip+rRhhDJiJSa5YqfZC6sjyRUBchjXonkVAOeK
GRZFkPua1eJakh+1eh0DjWMzJMXuKy0+GApeRm8wNFYCgOw5epsLIIcgdKH96gMEyBlhlCgthQop
N4F7s9Si9KzCym6LZbUB3wRpEnuf6tbSswpLtCxzrZSgLQdJvsy1gtVGj1yti95e99W7SfLmOWed
a1ST5KNK2g9y4ezF7T6t4AvyK6cSsp/rT+so2IUjL/bqNiqCc8A4XfIE7HF8I1YcSn7BkrgGRJ22
+Fpu15w5DW+vbsC34hwhxeRpQ7nQNxm8ftzAKu2vmu9Hh+M5AoHCci+pSznRGEHWW1qk72J1tA69
XQbUqJImrTMiquQq5X2jlQZ7NSW5e1hpOcZWHE+sDysNWjSP3ILkwgYtCsVRvR2dlm/sgRErIwV5
2h36sdaZvbz/OMcvguh1o18D0ePEppEiFUavBVaN0+FAHkFYgh2Km2v1c8Zx9ZlDcXPVzWeKgy4l
1uRWXEF0DlfCNwY/agsDZoBvvC/GOB0hRCCDaPKocq5KyFGKselr96uPmfAYQsjO4jXXCqJbu/Dh
PTVJLwblNsCmJunFoNwINi2SXhCWOPlei/zGCUWVwrD3+CNPAK9D3Iw5mqKqAV/8T3MntIW1Mih3
Qr14eq1QOxlMCKWp3VtQLgyc6k9oBV8ZJnSHNptyLvBES22aN+H8jRY6MsbI6rRTLRD18/ZDnfdl
b4lQ7FHuq+GEBhR7kft6+kzPtIdIhUK4X8fHSSjRZxp7G56jt1EUlqnfIetHLkyTRhXsIClzMl8c
GRUW1TdagC/mmnLFHCEnqP0956yQFlyIa1aTO6H1UYvAd6TSipQT9JninvUmZU7OGdCx39EJP0bl
FRSCCwckU3b8lde5Kj1fY2bHq3kL8OUDWe/BnWNY6UVvaCf0lbvvOCFD5JKqhLShj+S1wuYzLUzC
mMXtfnsMAUxowEvdy/u6jrIAzDiltgI7XPRf+t1vwCRGPmEWf7dXekFPwZSAWsiKXuBSmBKzeBkd
VhCdCj2Y0eu0VcOUjLudQkpdj+Kz48iLFt0gLYy9CdJXufvKZ8dYvDRZffKEtFgujChpX/ns+BF2
eKYEefXT6/ha8YshZuXt1fuSIZTD7/rVl/KjXqNUflQ+Rg0+86PyMa4zMtZ3JFO7Yi5G8WbGUD9H
7YYRBF5oZrDlY8SmZT7Vbmr3MWr1jRBr4uBblHMRa8IC5mvma9TKarHDyi/B3soEJYA1S7sjlfMx
YjMOoLUC3nLfuBlsNJ/mHaksdk/ziZZkcHOtajcw7yGXPNSKDCYDpqvF8dcecjapwuNMckUGk/WW
Q1CnnRh5W0bq/rQX2ic6WWsPfl+bmVLpxB+xuhNahXqqg+EMqU91O2jyhNFLSJJedJ/ChE+SVxPd
p2O24mm/BYBZsOKISfEXX/Fnz3O5j2/ykPguGoaaiwZIxfXIWZ0QFA3vtilUMRfUyGSAjuf77eWd
0djJFOqDEqtHIINzICf8vrZRBZwT6pxZ8UQuUIKQE1FydIaxnHLvXn5tlADn5DC7lzmbRwAwq4AN
e5NzQZpUWG3Zc/RqGDHzacwQvPzacpqgnCFNlhNaPQLgL7o9R5H7YubTKKv0XVdk5hMwrpeY6wnh
8jC/IKahVvwIJgvDc85mzLyCyc7nSJMHhr4FZJ53XyCZaoO95iXmOleuVwfi71md0B1yNtMiV7f8
KHA049KiurU0U3KaFoh8vmmlNXv9rU4CrO9IFnIGfFQ07TvNczKFHkXzPC+nnd69vMNq8/bEu5d3
wvMqbxpf3rHcetrbmzrkapw5Sy1aLbQexzsU54CX+WgTurxDn5lP2WuYNZMn5av1GafXMGvQFjQf
M2uXW7u9z096bUvpigsrH5NisWw4QQk+JoF1/O739/l6mXM0qhOqDOaPMAujpFeDhpkhe47eggIt
8ymaJ+x8h+7MJ7C9P8eV9qPzAch8XGL34ML0kU0i6MXMp5L7kLoDlirf+ou2fVukT5BJhmpfDVxY
MWyxc9YwMejaNkfzdvSe+USfYBlai7acYMuBW4se1Rh10qvke8uPqsU8rWe+t8ynwZRSxffMaRpQ
8U3yfYNGDht/bWF1zHxqKU0pcwCyoNPKIpm2uSBXYV2lKHGHZT7homVpA1jmE98hm6QE89MHPf5K
K4AfGH5bPVU/uPDnr/jh3Ua/BkPPuUO4GBHSl6+Z+RhbGCONhGTYPB+jUiMFb83ZoJDIfGISNUg6
3VwrRIPgHRUnXdy+VugIGEqjIEe5+8JchWphdY8V17A6OkaZtOG/cfVnUPBCoja3ry3kDCK15WJu
8HyMn4wUqaNOBgQ8Rm1ZVM3ONfl9bQU4+C7Se3a033KtGOQ2Zg9TnhCD3CDlRtWjAL5weZrb/frM
YZB2tDQcJTYgR0gLO3oG9Y0p4YTGKLOrfVmQW2M+uZvrzVs/2L6OqE7I3vpbamMqnmABjgnSmnn5
GrW+cDPIrd/Rsuc7ZEFu6Y6WFd/IMh3gm+53v8LQNmBetuglwFYihW/9teSk5zJ4TA3qRq27h2Iv
EG+hyXOE4djA58lRdYfHHRxd7qcJnfkE/ppSAnwEppVY1L4sp2lA6nQ5ijlNeS58v4WJMadphj6y
oupHyNkMQ34jZA7HtKlofwem4aL5USsovEPOZk1yxQ5lDMkUs7q1eUDNAiNnqWEyZE4ZI1a/r/Wh
ADwxoP+HPCG+z8/WS5ASoASo2cxsGMUTMFuuOKEGgqIXX96zxdWp3fPlnT7URQJsmU/zhw/1LCdg
zF50xqQmv5Fg9cPTetailh/VGaQnv7HRozlSLpJeBKt9WpjFWYsaWGUShafEFnI2WPykLFphDXIb
jcVPLMziLKPLxDeG2Re+30p+TOaJWDL8mVctAIwYraubRrD6Wf7o/I2ViQFt1pkU7WtiDkXo3urY
QrsIQ3tcNMyeRUXve+5zyG9ktvgsM0mJWenZKe0GAOc8JALM2WOT95EAs/GNfEiqtk6AGcZQMqd2
ykJYolHdNGBxZmVnzdE4GkiAcj86iPwoht8CasvdWzBZhmEod89gMlzaGuTuCTAbdGiS9ldLDL9N
dUjOsWCylnuQPIEBVnxusaMXjcxCFynllpPcPS2YThgtd9+Mv3qUusPCxCaU6JTf2Mk543Zsrbz6
87IT452g/RqsOkauPctO5GNU17PsRD5G5zkfYDsdTrR0zOTW28AeM4cajOPuZlphHJgBoqT6Xe0e
QPpxcMpTfiEzh+qdcCqoVfM1ANgZ1y1WfARQid035myUam8lx5h68xPC1raLeM6hYphVB66fcl+W
sjksJvUx1woJLWWTsRhyRSZjVnBPcN+4+qpCu0ZIVubiPJcVnaiw65viLvoJByRXS4pz6CecRF5B
0T7xnao2K4Yh9lUYoDdC9ZTYqhoyQG9aAviZ9lZ0Ahggd3XalhM0UipF7otwiRE1XVICcAkYtLQg
dz8qTND1Du1ACDd73Enb4oT4atS6BWycKcHQKNj1FGTiptHnCN2Zgx+1FZ2YkBO9NM9fWwBVArz8
UAfnvBSGRn2qg/Pu6Zn8VAfn7BV6Jj/VwXnFYt7q2fS+IJlK4GucOkeWk4AplPxNe1tO4qOYj/jG
xmiImLwE2Csk4htxkarj1XfexNhh63W54mCuZVs5eguNArRnsHxQ9GLRicoqKvIbme0Dw6QuN20r
OsFakdHSxMWKieFMycoQnOnFOooWp6R3nxkzUUcv6qYRoEHB1Cg1LYOeEm6j39cezsQHgA9/yTnH
hdCrfPhLzrsn9Jp51VZbhg5r5pU7BuAYuw4jzzIyR5HnOBhZAXLJW2sZOjACghu1PgGygAVETvba
fTPsaQs1yNWqqGrQC+pvsYVWrx1LcJUPT8g5S+QJvY5SrjInGzZA9zJnBVWZ/qURgvvGze9Fm6m2
mCTfV0imEe7qbmdetQIWMDq8ZfW2gMVHnthZmrCAxY+4kKPugLUEGyDNGOSKAGi4/6PL2wGGZ56F
5d6cb0dlAHtLln975nuWuWBhoBHliozAakR7iqpW5oKJ51J3sELiZCiH55ytjiKte15bJb9aomsl
3pFh5xwXSLlae5kST0DSX53vS0NRFVD2GiBHkZYVM4dmjqvMeVP7MG5c+NXiDq2+U19fg16v+NbV
hH56tI4xvM6jdR719GidcyMSqyMVKx2aj3HKrOU3oddrk3MVVt/Kt9P7nHvD15kIeDL0KBq0837F
lRknLJmX3O53L1R8qexxEnCxQ4HO2e3Na43OfQAmmL2dQvU5aodVHcZL7iXLUSyPCmRoKvvHqLQa
7VaQIS7nuOelMKAl357Jc44LgwRmvD2TInulsfZOMSB3zv+A2dthI4ShuJCwalBvOF7dAdOr1IJY
8VFq4XzazEsBa5be5Yp02c9ZR5FUpcu+s3yNW3ENHqUzfoQc5e2w8Msci6fXFjzK8MuPdNnHqNV7
QcD0kS57ppdliXyky55PKEPUF1j2wfH9Xh7BvARhuUNbkOa4rHZwUvT6DKxskqMzhHjC3mtR9LLK
egF23JSUAIjutSf/jRslCHIgwFKV+2KWyAhpeJ7Y4AsTwLfT3gofzCuNVDVHZxgJuNtx4ejNC/UI
mTxmNFkw5KfP8biiZYmwTHdX51hStpyzIGWhBUMWlhlXMse8UCwyOBTfE+T0HnqNiqpWrIDlg+Q5
EgrNib+vkl6NQfmsdKNOm8UK0myWJSL21WESlm4p+oL2H/X3qpS+BZwD0DRLklRllb4arG7b+W6X
ySe5vt7trQwBn+RGnEHdoWoPvjNHebetSt+Illl7ltFWpQ96b3a1eysDz24qSVHVqvR9htEeT8hA
zmcY7VHm3AXeAdKaon1lUxycdfEyeoVolRrmbjNwtk3MC/XRZkBQlZWNMZe3MTeq0gv1Ud/xbInW
wTSAjb9WqjImp87m59rhC7VVveMJjpxDL1QyFePmWkuk0wsVIX6nooQFQ447N/V8QhYM+RmmffzG
Zlm6sBekrm2WpZu7NMnpquqlWEHJsxIlegGEnnMoxml8Y4YY92y/bauyoOSmrLb4RRY2hkHX1DHC
rv9R7+MsJpol6a4GzF7wL7wxYPb4RZadpAmjR7HLU6ldiok26fgOvUgToE0mlEcrwXtesYfM1/bh
DYUP2n+hokF6M/mXkGMJJ6Z5VjR4jVIVDR5ziYoGj1GiosFjRVHR4DFKVDQoa7LiA1++KhqIfT0q
GjxGbYl7jC+rVnzrMWpFjiZ3m12Mx6jNbUe5O1Ly37hiVZO70x5LHqPWFSl3R7A0OkFV4svcKuPx
BFUn9Oe468QKqlr7jWnl9x7fuJbMe9SKP38jjK6L8rR62m9F+ipbEcXuvvGrebDJE/A3XZ/fFYBc
XgGiq1/UOuPkRMOpHIMKYjT/o+mGcgwqYJVN3OpMZfQatTG3XaduYR+PUSsTPVovlGP4zrP1gljx
0XpBzPVovfAYtXUAZLHhWWuS9OIrbAoWpCjoZc81qWV3QnuG6+shRsz1eIgRu6d/GxezeKpuQcPp
6pAuKah98ToxvyL5c1wfT5gHC2MnO855mwcL9ea/8V1ThZyYVas45/ZvhzG7XNH82xgnOdr82ylb
iPhjxfXxhNUsgXf8vrbHE4Bu2I/mA3uM2gJ9aVVAoLlz3DzqtBfaXSpZ0IsVkKyMmDohKElmPFlm
92OuN40QWBwgZ8Vf1rWP9TqGohdIxcISxXPOXoiD/R7vnI4zr1oFygBbJKi7bRUoKwSTvEMZoBsK
tTTJhRYOzHK8TZ1jhtoFcuoxqnPMsDQtTKFI2nd6WDae2B5iwF8bT+yBvoFPsalIeW8PMWD8LuWX
5a7Gu3z2+YSezzVnSty5q3eI+JkS1tvvo+LdmQutt1+K3euO/VFnQtHn1qQstA6AsPFTVTwBG5LV
P3sZcl+QOZ/Y6THXUsyG5To+sdNr1OZHfjzqiG9knUoK1p+MGkzsGJ6q6yM+/dvWYlZKAHYAhEJu
Qa/Ipx+AxIWjtw6Ajc1XrG7smfb2qFPuGtpnKcdHHXpYNUc/e/s9VlyfDCzWb4Ra1B36eK6xJ0+x
IqP9yh1Bdabqs2ufWPF+rrnBxXkU+/FBvQept61qJIvWRbl79jCGQT2TurXV6oSztZJc0eqEx4UL
99qSlmdt3ZzPt7ZanfA6QlAyp5lbii9qil7N6oQPq6tx3lezOuH4c3+ObypQUidkv/vtucbyrK1b
5VmnNaZQBaZGyhWZQlVL8PbqNldlPZkavX2/veoAcMac80LVrQJlgzQpZaHqV8OB+zuh/TWQ83KA
byDn8WZwDpZ9tBIoxxCFyMKysQWDCcegiJhYnr1HM3uP7ntmWTLYbPh9rf7abJlrebp9bQGurBiV
arXDEUG80YLNuqfXuntmWTKONLoV1yBeviykYCHI5Ris8fRci33xZaHkZgDgHGRtLTtTiVmuyIwB
AI7kd7/VSmT3n9hKU9+Y2FGFlXfcCe1Q6BXEez7HZxDvmSfuYj/R+kaVNaTjMWrAaJ8WUnumV6rM
GYJQrYr2zyqI5zsEI8iKM7eqaJ+gEFicmZERYkW2JmeNBTdqFV0M4uVjbY/qPlpr8jFj7OpuM4gX
OiOFqVa0yoUzWiDpea4b5NzFmc8nZK3Je7AM1zO9rDX5p6l6DiTNLGbwYaqeVywsUxD7mIq/nj7p
M+dYH7fRbtPrTC/wRMt9eNpvgcqPPm6Pud7VJEzJKlAKSgAep1mClyYb+BqdXXail5h7gZ7KLjvZ
347NQxx4a5k26FbcvM2NqvF+DzwHpd7VBvMi5bYy+zQJgzUAOXMOS+/AuqxDygnLZoyzR8lf9DYD
FLZFP65QqDLcFMC2KjlhTcfZplXqWjYdH5A4RWoF6/bWYwhDUgLAF6g3Zs9fK8Ak5KisqipPaLId
B4ymoKjKkNqAi1SqoheBCf1DQa7InMcMi89rhR2+sNFG7tNrvq2cPTP9yozyDrHofcel7F1+Ix9g
sfmQ5DfSNsltes235zx2AkwL9hffSKsDVs5y2qJcjljxUS7nrDsMmFglHLnisG5c0dP+LTApd43j
szQxyAGiValFDXLgt4s02QJcYdWCDsHzxApyWAgHplVqil4scTMyYOZUJ9QKQ5Dv3n5njm4AqwlC
LEv9aH3c+p2NLejVmKowLR5TzIXTjmwA6K2OX74KOd6ZR58/ixJynIM/H2Gw5ehpfuYWlmMgg/Or
nENEea0roz+fo96GwUZ2OHGj3oXBwi5hFl85+pCtsEsusbt9vcsuZHJrdPTaC7sw46FZU8JyjBhg
diFUXm9693y7sFJMcvd8uxjRWuiKfbFWKTGhP+0tpLZdxR7HJO3ZELJ2C0EW30gfTZoWUHfmCQgt
5tTd4kYEy1Z6+a226/kbDb6AN3NTvJoScxm61Q3cKIHb8oc/x+9//d9v6fuvf7tvTjq7P8GpuCCe
U8NjpsCZwo+ZhCP17UxbMXgW+km3MpChuayT17I6aVZGBSZpy1xbaC7rZFVrSbrt61OynOlj9bOg
cg700XLp/a832MSyMxA/9i50pgmjV6BB/E3aoCGLx1u/cHkKjEuB0ZSi4lhruD1qK07ybF6fyMJA
zXLAzt/IsGDYJjMXxf0G1EocXtbtuY/RXjr9rVwNsAwFmctdkOFMCStOE++CDGc5AHTMQHcryCB2
zxLzLYcyJb0I50q+wyjOobzsHTNL97pho2pnXcBhofVnzoGpetE9kbL8xgFjLkE5lDc88ZtkipWh
Z2O1/vfKlM+Zmr+7v3zt7hqoZKHD8Xvu7uHX+ffQg01+2w0P/056vJtp9/Lla4xRFz5cYR/ubciz
9aTuh4HpCKjpJfHmvytswtK9Nt1CkenlK9lqVIt9QY+kCX71kmIrys+qn9Vi+c6aGTLiqlYlSdkC
9N+x8myTN5IwOTCB8HfpEcLnCN1Yfpceef/rveAQ9GEadUoZaxCdpKpKGrDgUDQHvKTJZK5ntsqe
godgReE2tcWy3oA8a4kCACTF21YdF3hmDsVp5jvM0bojnilR2Ssg5LDw41ZwKPwomXjWNga+w0i9
KUqw4BCjjbO0Og2iY3Ozy93TfQBzqnZJLwaEh7uq6vkcoeMZ+zCr1DbMerWe81LbMJ+VT4dTahs2
d0+w5N/azL9JuloD+Mxi6H+vdP2cKbqb8baVPHb6k5MGz8PmbFmOYo5tg2b2J/22lXxIaTnDN63k
e825yhtrVXZxZtpKb2yf0mH4SZuOVXYHuKFKuWnx52FEb3/v9XPZ7XfmIC1SRpaX0UvS39jY7XfV
f9s3MgYs4rr7b1y9sYORdav+2+oNwzYnXvE8v0eWQ4OAWlXa07g4LHpXY1Gn3QNkV2I5qzeU+EL9
3Hek+ZJnt57jlh+Fnuox8jfGcH3E8NRzODWrFoRuBfbqOdSYneQ/ao1UEQweYeeA5aNbcXWgWsj4
sA6F9RzwzoQeKOLod7++LVhCT7K4CEGux1uMWNESesJsfsWtIwxQDB9PPSVW0oPjK1vSRknVbn09
YvWH/cb9O6D0Upe0Z2Fc/Da73e/uX2gfgLrm6LW7f5mEU6yHdz2HjCewV665S3rZ+8loFj91pr3V
cMKCnr929++8MpMIh6JXsidWYLAh52Kvl9BNK55PiMnGs89GCSFW7PWySrxVnZAVswWY7l1SFTis
zNBCkFTlq0KJlnZ9/kZz7DaA1qG+kcVsAzOzprpD5v6N2drInTnHuqzjsOmCPFPCYlzBg/5u7+5f
Fr3us/tbu3WEmexROnOTKzLGFfKwTkV7i3FtKY4kKcGSt7lY1PZj1PaqwBezmryU218VWPS6zhjl
7pmSHHsIRdJrGBfOVtRNs8K4H704BOfcTmKrByVWJEbm05a/HVuvF3Z7gtSZ6hutcd1Hr4QzvUpi
lHu1GnSPUSvuoiuZ+afyblviMlvzFrkvJi6zpoK8tZa4HHrpQVG1VPaEovEvd9/sbaunIHfPXi+w
QL2G2funhwsCsy0aeX0HYBcX+hfkaVsXl8wSQYrvrYvLiIvM2Xu9TFAize75fnMl94sxj1OekDmJ
GffUFedYfxbGDUiJaU5i2OJxKKqyMC5LS3cpTYhTmZwVkqIEU5JhgyVP1b3kLcvBzqwleW18h405
SL0NnoGGSVY4RuzLbJNcvQR46yRmCT1pPZqTGCZuHopzWCspRAC5qE7IeqoUzCjlvaURT0hMd0Jr
s8w7jRgSc6rds+RtAxNmbzOtuMSKqqQx/ah3nVfaNBx35i/rvFJi0Lav9VRh9pCUE4398QpUnzxt
c0vP9BNZ2NgSGLBdy8LGlsCzrLJw65YC3NuwO0+v9YTYRQ93Q0tM65YCYaElZhsW9tCGPiEgx9HH
KNKqtZ4qMMKalBOdxV5CnIslmr6IHOO7z/kacjy3l3wix3MD0EeJ4HpsXBTZGKvfHY/rsZWNVbMq
uGpNzsVaELNbrHI9NggyN36CYJ3uG7f0yHLRsqdTpB7b4lg1K6zAiJrHqA0UspoVDHw9F/untzBG
krRn+d+czJUsKMFHvcFWD26uFRRaYd872uRB+82pziS3Ynnr4oToes+tDb+vrZpVA5BjVIrb15b4
yOeZYXVLHnNtiY9MS+GDn9rXnR4ZrXfJY64NOlKxj+gpsUNHKvZmIQFixWKdMVLu6naYy5zKuMp9
VUAhGNDTc/QWXxxxh+60OrEiK5Knbm9Jj1Frr5dHquWZo5+ploISVsABMGAqXrUu67mucmKuoxgm
0kORozIkU+lgiqyomq2Aw10r6SwnDNKyppqeC7ya4yz6Pj4jms98/4xoPkuAZ0TzmfY5Q+Z8Ptwd
m1DmwvKZd/Kd2H1lPCPubZT0AuTgWfu7vTu3A+tBWYz+4xvXFSG/oB5TSeo+WstR5oB3uXvWz+rd
uqUIelnaJs4xKNpb2ibEk5c5e0ImuRB3t6h9Qd7gtHPzWmFPtUygxO04FftKjTkzVoz3MWorEgyw
CgSWsjohA6tzWj27M68aWK2sCaFOyMCqxaQomYPLA/BVLJRP7ItgFXqvSv1oYBV08Npq7+IC7R7z
7J6qK6Sl69Vq2ktKQItm9v/L8hzpeh3QC1mtWMFfsExy8HdoLWcLLdpiTE1yTuXL/YDkkZxjvV5q
jUNqKys4DGG48P2WtskIXRj3UjJZrxdI1UWnrftieQrLq5Mr0v5iJlKQc7E8BX29UpJDVl5QfLeh
fW6rSvurdatxcubVu0jwiF3a0XSq5hkWq2P7xkmJGdOiRbe0TUrMlIe00qxIMPCS16IbKGS1F4B7
rx83VxuLBBc2OlCS3BIyZ7EsirNkogMT9nH2MnqL2s6sVgvFXRW92ACULU7zkJRg2mZq1VswGyBn
ftccdaH9CveY3AmllqSUs74xjEmTutb6xrT0E6u2dXZphPySUq6x4cPGX3sxrsqHgoW/NqgNSBsB
PFJ4wxM/jxOf70TV12DoMVPZwdBjprKDoaJKzwOGiio9Dxh6rhTD979ekp9r71UDmEAw0d2orZZP
YyNEK4Rcj1niTHOdbEOT3Fzvmol+xJw/5lq9jnwlhJI1U+JMCb4Sskt4cXNtMeeZ9c1L0Lt/1AUS
9GINd9YbG/IcH3WBBFWtvOFdd/0x11o9iIULIeEYvSe+0cpsQR9oelmZrWRRAudvtMTaVG5TVVQP
YpQlZJKnxJ/WUYxeyLd371xZh/CYXZyD4mi2HIUxZKk352+0xFpg1ez5foPHjWliIUuq3vA4xTEk
Jaq1hFzPcWsmWq01XmiSEky/nclae4pvZPotkxWm3BfTbyPbJUiqsodOyT13ueLsV8Jc/rT39Ftw
YWNLe7WvHPGNuCKlqNthsd9Qep4LNxj6hLTnukCJUYIY4HliTSd9QtrX7jcv7QPSikpENOO6xUue
ZWGuTMcaVrxY7KsyRW+OhaNXerVipV67l+RrWrAl6TJuVZ7QIEwI1vf+fDssSTezKpOkxIzsqVC0
FjUv7QiWkn3+xgJdyzK1Iands30pkJflPp1pzxjl2Zjxq26HxSjPWEpSlPgsLx263Jcl/I6eJUd/
lJdui/RdoSPTghOMpqo4xxJ+e59ei26UqNOquAZ32nu9onyVEBftvvtyO+4jG0PIUZ29kMocbtRa
2dAqEfW7repZYlp56XS3VRUrQn61cLdVPZ9QhfzqVH2S72ugTrvbqp45p9KWy2097a19KXVaH96C
2RN+qdPm8Hp7jyZujE2cXpLv5aVZiSiFJrnQyksz6D7IfTEaLdTppe8ft1GdLaarlwDbcwL7DkJe
+nPc6EXgG+bt+TrKCaD/a86QvTTZax9N5kjeT0znfbHZBnvVSguZfmHG5c0kaT8bq1Pd3lBRr4iP
uT16W+6Pq28ysPpZ7zWrb2RVIxjuXVt8LXZr0tw9f22JyNUcNfMdf/0cfOV3LP418HWuFPNI0q3H
rOdnr5p6zMa2ukA5ZHvFOdcYIqzCRTQFeq4e9OhVU4951lYXiOq/yt2zLhCLb2Q31waYeDjBuhK/
RsXV10bA1OMdsHqsChIbxE1KNzuc6yh1KgSmr8sTGpHmuJWKfIxaU4wH2961G6Kd6cXgiwGqulFb
UC6rB0V6Cp6j9l414UcqQT1m1SdWes/5DuQ41wWKVp3K+sufecJ61cCW613uK1kQs/WXf6y4wgSI
+lnnLcTPNYaYxz96HFWd0N0CdNwepnOVHnYljqwCo/jr2dFGUIIJrjXcZq+oRAQuDPE2e4+ck4aF
J1va+ZlzDAolbKzJc2TfmxGtj8t5X3ej0GR9XM7faH1vWJe5qtM2v12taTmhrVFo50v77RU61wVi
o9DW7wDfY70PaxQKa7tLnrgbhYYb7h15AheD1V3ud9zjHaJ3L4L5c5PfWBgQPawWuqAXDI7CPBp/
H1eQw6pGdVqFEfGNkF8sT508r27ePfbQudNCHqPWYGHroXOnRQpKTCbx8nIrLmQL0Dqjlfw8n7aB
nDLuB8Vz9aBozReTv2l7D53B4MTp+X6bCzqtW36cO6EVChG+DJjIku8JXz6TgM70KpBMn0lAgl4s
pPqRBHS+jyyRmrfT3oEJLAUgDn8fd+9eAxeWO2riyBMFIBoY4fZfnGsfsV5RbXVKvrfuOJASVXK0
FVLts3XJX9YdJ4MLh+J7CzKtw0prnq0hApMWg5XWPNPegAkE2KIft+aegUGTd2LOefd8Pm6jVKdF
NyhUG+Mh6giKqhZkOmNdLL7VtG/0HidrA37WyCykyr4QXj9u0JGhqJ0ea3mOLKTKd/Su7qN1tKmj
e57YUwpZyCLccVPn6kGEHHQLe45e/WORfuFkJYvPPGFBpgPySVowjXYO67fLm8bw0YnNNylNmFII
vo9e1+4tbcqVP9rCit3TGgLmW2zfzT+Gb7RqxIpzWjObPC6032ofpVek1rmi1AgWqdUkR3940Vab
fEs8nK8H63MVKEZEfTR8PXN0m7TcoZAlCrBmNb31LLVVj6wCVYbnr6/25OjxHZO8fpbax8/CBjDB
sp9vUFuxWFz+GhJf2l+j9mxB+gCrRb4/Rq0gJ7MkYzRzXMxVCVZx1eJz1N4UJrIrkRXfEnOxRkzo
htgfc60Ac8JwzMkO5zHXm3w7wEc7nPOKbL4yodn59vpYce1neziLRIvt9bPXEV7hHs5uusz64z+w
OoGU7J8ev//7n7//fNDf/vqF14ZWy0GjP18bXqN2h/DL1StGQZYmdqmZbpRw9T5GCVfva1T815X9
Xq7ex6j1fcPKi41Ush41+cCWotv9XtEYuprSyO9+ZWUreh4tiuAxal3Rip6DqsGNelc4LBVz2Amq
siQYruvUVLVy5rkkT9WtcBjLmde8cM5KCSaE4O+p98/faP1zmTUiKZGsUPmwFIHziskKlc+R3Glv
Ds7Hm8Rj1PbaAA1FL1VRlHi+STzmEm8S4hsfbxKPUe/athRW+1S8mmD593gnqjz2tb70MEoFkqMP
ORe1MDgiu1H7awPkBCMhsuIvpsdWfEIakhJMj+2MjVNUZdGt8FFe4sz3lviKQVPKHCa+Eh6kpE7b
WsCAv4bkVWvuklk4RkkAFt0qkTGOiqNZTqvCJi7ytK0Xby7d37TNiVvN/d+a5EK6VEe9q1KK3UPm
sJ9B9qe9vTbQCTLrIgvXlwtr7gK+lzL6jiWGUeL2FVa8/ogSfozanKWMjMvm6j3vy6KEIaRLUhzN
ti3A4YuGWc8RuJlpldlrvvUbcfuvWO/XZbEiCzrxNd6f41b2iYnV4DIvAbbqyNCiwDz+Pq4vnJbS
OmrsRd0hi//Nq67d3Nm9shPB1PK+DNjOMP+XO7S9EMRrfpSkO89ldY/73YDrTFVLVoX88tJkc5Yy
WbUAA3kbYEW8VpSjNi+j92RVq75tlc/PPFGt8Vztxa+4ddllUY42vD0RV7deaRe+c05P1a2icbks
p93L+3X3dF1iPW8zpc0pGXGOyWqtixPqsKxgXhWvRRdbzpyS0FZeyuXN3ZgZg2oxzg9KvGmiQu24
7GvteXt3sx3e9k0rZry72XZtY9oLAU7b8+r22mDlNspYtMKKPx8Jpo/dr9/4SDB97Gt9BSkdGpm5
HO4bV0qw3EaCYSj5vtET0qHS/FxbUmhgn20LFHzsft1XH+yz3b3EXE/bCgV9FJJ8rLjOxT4KbHSR
1Vw9TJaGWSRT+tdPPHZbu9VOstfA8AWgq//89pdvwaYAGrv/46eIq3u2+y1uYfon/1+B4vwSUPwx
SgLF86gnUHyNUkBxnsSsA4o/RkmgOE+X2AFFMeoBFF/0UkDxtXsFFOdJgDqg+BqlgOKZqk+geKbq
Eyi+KKGA4pkST6B4/EYHFM+jnkDxuKIDivMkzhxQfI1SQPFICQcUX3MpoHj+xidQfI1SQPHIqw4o
vvalgOJ5ridQfM2lgOKRvxxQPFPiCRSPVHVA8cj3DiieRz2B4vG0HVA87t4BxaMEcEDxyNEOKB5P
yAHF11wKKJ53/wSK590/geJRMjmgeORoBxTP3/gEij9GSaD4GqWA4lFbWdJpq+Z6P9PL4GRsxd+0
vT7wK530fIcK395T7iUpvmd9YHbk0zrNuoAye22o+2hdQGucVeptOq9HypYz89jX5paGnIAFld1p
76Czgr+AaZKkF9NJA2RAUVxoFZJYDTPIExqQE3lUv/sddLJO12x+9zvohJwooS8WzBYvy9juMbzu
2EEndv/RpfGsrZgoGqAeF17dQOdk2YxFu++gM0M/tlTdiulNf89g3n43aksBpR4CoPc2wOZwTleH
gvT0ylv0KgOf7n7OYl8EirWORUavK7L3eGC/QLfiCu7Y+makqm05a32TIRGTurUOTr52v0Wcsqpp
Cf6E0o+I0/vPqwUYDDBjGb8XhjRPxt8CQxhbu/7q3779H6LCa2plbmRzdHJlYW0KZW5kb2JqCjcg
MCBvYmoKPDwgL1R5cGUgL1hSZWYgL0xlbmd0aCA0MiAvRmlsdGVyIC9GbGF0ZURlY29kZSAvRGVj
b2RlUGFybXMgPDwgL0NvbHVtbnMgNSAvUHJlZGljdG9yIDEyID4+IC9XIFsgMSAzIDEgXSAvU2l6
ZSA4IC9JRCBbPGM3YWZkOWVlYzI5MmUxNzM3YThkMGZhZTY0ZTFlNDFhPjxjN2FmZDllZWMyOTJl
MTczN2E4ZDBmYWU2NGUxZTQxYT5dID4+CnN0cmVhbQp4nGNiAAEmRsbZlxmYGBgYBUGkuySQZDQW
A4togkimbhBpEssAAFNyA4UKZW5kc3RyZWFtCmVuZG9iagogICAgICAgICAgICAgICAgICAgICAg
ICAgICAKc3RhcnR4cmVmCjIxNgolJUVPRgo=
--001a114304d64b488c0531243c6c--

.

I can see how the proposed feature would be useful in many contexts and
provide a clean solution to what if often handled in a messy way today.

I'm wondering why you have decided to handle a pre-processing action
with a syntax that doesn't look like this.  I remember having seen
somebody discuss a similar feature some time ago that looked somehow
like this.

    #inplace char data "datafile.txt"

The effect of the above snippet would have been that after
pre-processing, a variable

    char data[<file-size>] = {<file-data>};

would have been defined.  Note that `data` is not `const` in this
example which might be useful for some applications.  If I wanted the
data to be read-only, I could have written

    #inplace const char data "datafile.txt"

explicitly.  This would naturally allow to also use

    #inplace const char data <datafile.txt>

to be consistent with how the pre-processor finds other files.  You
couldn't have anonymous variables with the contents of a file in this
case but I'm wondering how useful these would be anyway.

I'm also not sure whether it is necessary to require the replacement
text to be a raw string literal.  Especially in environments where
compatibility with C is a concern, this could be an unnecessary road
block.  Couldn't the data equally well be inlined as an array of
integer literals or any offending characters be escaped via the good old
`\0dd` syntax?  Granted, that might not be very readable for humans but
pre-processed files are not very pretty in general.  It should be
allowed, though, to break the replacement over multiple lines using
either line-breaks in array syntax or else concatenation of string
literals.  The reason I think this is important is that many text
editors perform very poorly or even crash when faced with extremely long
lines.

I'm assuming that you're assuming that -- no matter how the syntax looks
like -- pre-processors would handle those file string literals the same
way they handle other file `#include`s so dependency computation by
build systems would continue to work by only running the pre-processor.
(Not that the standard would have to specify this, but it is good to be
aware of.)

Another question that should be discussed is whether and how to support
non-text data.  For example, if we have such a mechanism, I could
imagine it would be useful to embed small graphics or other binary data
into the program image as well.  Would encoding get into the way here?
Would NUL-termination mean that I have to subtract one from the size of
the generated array?  Not a big deal but something to be aware of.
Maybe there could be an additional "encoding" prefix for binary data
that would guarantee a verbatim copy and also suppress NUL-termination.

Finally, another option to include arbitrary data into program images
used today is deferring the combining until link-time.  At least on
GNU/Linux systems, this can be done by use of the `objcopy` program [1].

    extern "C" char * data;
    extern "C" const std::size_t size;

I don't think that this approach can do anything that replacement at
pre-processing time could not accomplish.  If you want to reduce
compile-time dependencies, you can always have a dedicated translation
unit that merely contains the lines

    char data = F"datafile.txt";
    const std::size_t size = sizeof(data);

to simulate the behavior of the `objcopy` solution but going the other
way round is not possible.  I'm just bringing it up because I thought
you might be interested to mention this in the discussion of your
proposal.

[1] https://sourceware.org/binutils/docs-2.26/binutils/objcopy.html



Andrew Tomazos <andrewtomazos@gmail.com> writes:

> Please find attached a draft 3-page proposal entitled "Proposal of File
> String Literals".
>
> Feedback appreciated.
>
> Thanks,
> Andrew.

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

.

On s=C3=A1bado, 23 de abril de 2016 12:16:23 PDT Andrew Tomazos wrote:
> Please find attached a draft 3-page proposal entitled "Proposal of File
> String Literals".

Any thought about what to do if the input file isn't the exact binary data =
you=20
want? For example, suppose you need to encode or decode base64.

Can you show this can be done with constexpr expressions?

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

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

On Sun, Apr 24, 2016 at 3:39 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> On s=C3=A1bado, 23 de abril de 2016 12:16:23 PDT Andrew Tomazos wrote:
> > Please find attached a draft 3-page proposal entitled "Proposal of File
> > String Literals".
>
> Any thought about what to do if the input file isn't the exact binary dat=
a
> you
> want? For example, suppose you need to encode or decode base64.
>
> Can you show this can be done with constexpr expressions?
>

As per a normal string literal, the text of the dedicated source file of a
file string literal will be decoded from source encoding in the usual
manner and then encoded in execution encoding (as determined by
implementation settings or encoding prefix). From there it will behave like
a normal string literal.  It is possible with constexpr programming to
encode or decode base64.  String literals are "constexpr-compatible".

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

--94eb2c1259be9c30d1053137d173
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 S=
un, Apr 24, 2016 at 3:39 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</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 s=C3=
=A1bado, 23 de abril de 2016 12:16:23 PDT Andrew Tomazos wrote:<br>
&gt; Please find attached a draft 3-page proposal entitled &quot;Proposal o=
f File<br>
&gt; String Literals&quot;.<br>
<br>
</span>Any thought about what to do if the input file isn&#39;t the exact b=
inary data you<br>
want? For example, suppose you need to encode or decode base64.<br>
<br>
Can you show this can be done with constexpr expressions?<br></blockquote><=
div><br></div><div>As per a normal string literal, the text of the dedicate=
d source file of a file string literal will be decoded from source encoding=
 in the usual manner and then encoded in execution encoding (as determined =
by implementation settings or encoding prefix). From there it will behave l=
ike a normal string literal.=C2=A0 It is possible with constexpr programmin=
g to encode or decode base64.=C2=A0 String literals are &quot;constexpr-com=
patible&quot;.</div><div><br></div></div></div></div>

<p></p>

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

--94eb2c1259be9c30d1053137d173--

.

Andrew Tomazos <andrewtomazos@gmail.com> writes:

>> I'm also not sure whether it is necessary to require the replacement
>> text to be a raw string literal.  Especially in environments where
>> compatibility with C is a concern, this could be an unnecessary road
>> block.
>
>
> Well, I guess it didn't block raw string literals, which are a feature
> of C++ and not of C (AFAIK).

What I wanted to say is that it would be nice if I could compile the
pre-processed file as C source code anyway.  Given that the
pre-processor used to be the same for both, C and C++, this seemed a
natural thing to think about for me.

>> Couldn't the data equally well be inlined as an array of integer
>> literals or any offending characters be escaped via the good old
>> `\0dd` syntax?  Granted, that might not be very readable for humans
>> but pre-processed files are not very pretty in general.  It should be
>> allowed, though, to break the replacement over multiple lines using
>> either line-breaks in array syntax or else concatenation of string
>> literals.  The reason I think this is important is that many text
>> editors perform very poorly or even crash when faced with extremely
>> long lines.
>>
>
> I don't follow this sorry.

I mean, instead of outputting

    R"D(some "nasty"
    stuff)D"

couldn't the pre-processor output

    {115, 111, 109, 101, 32, 34, 110, 97, 115, 116, 121, 34, 10, 115,
    116, 117, 102, 102, 0}

or

    "some \x22nasty\x22\0astuff"

to achieve the same effect without having to depend on raw string
literals.  These ways to encode string literals are inconvenient for
humans to type and read but the pre-processor shouldn't mind generating
them.  It would be even simpler than having to figure out a valid escape
sequence for raw string literals.  Not to mention the harvoc that could
be done by UTF-8 strings that switch to RTL scripts...

In my writing in the second half, I wanted to allow for the
pre-processor to generate replacement text broken up like this.

    "........... some ................... very ................. long"
    "......................... text ................................."
    "..... broken ......... up ................... on ..............."
    "............................ multiple .........................."
    "................................................................"
    "......... lines ......... using .................... implicit .."
    "..... concatenation ............... of ....... string .........."
    "............. literals ........................................."
    "..................................... to ......................."
    "........... keep .......... line ... lengths ..................."
    "................................................................"
    ".......................................... reasonable .........."

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

.

On domingo, 24 de abril de 2016 11:38:13 PDT Andrew Tomazos wrote:
> On Sun, Apr 24, 2016 at 3:39 AM, Thiago Macieira <thiago@macieira.org>
>=20
> wrote:
> > On s=C3=A1bado, 23 de abril de 2016 12:16:23 PDT Andrew Tomazos wrote:
> > > Please find attached a draft 3-page proposal entitled "Proposal of Fi=
le
> > > String Literals".
> >=20
> > Any thought about what to do if the input file isn't the exact binary d=
ata
> > you
> > want? For example, suppose you need to encode or decode base64.
> >=20
> > Can you show this can be done with constexpr expressions?
>=20
> As per a normal string literal, the text of the dedicated source file of =
a
> file string literal will be decoded from source encoding in the usual
> manner and then encoded in execution encoding (as determined by
> implementation settings or encoding prefix). From there it will behave li=
ke
> a normal string literal.  It is possible with constexpr programming to
> encode or decode base64.  String literals are "constexpr-compatible".

You're missing my point.

I want to be sure that I could pre-process the contents of the file into th=
e=20
data I actually want. That data and only that data should be stored in the=
=20
read-only sections of my binary's image.

If you can't prove that, it means I will need to have an extra tool to do t=
he=20
pre-processing and a buildsystem that runs it before the source gets compil=
ed.=20
That negates the benefit of having the feature in the first place, since th=
e=20
extra tool could just as well generate a .h file with the contents I want.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

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

On Sun, Apr 24, 2016 at 10:03 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On domingo, 24 de abril de 2016 11:38:13 PDT Andrew Tomazos wrote:
> > On Sun, Apr 24, 2016 at 3:39 AM, Thiago Macieira <thiago@macieira.org>
> >
> > wrote:
> > > On s=C3=A1bado, 23 de abril de 2016 12:16:23 PDT Andrew Tomazos wrote=
:
> > > > Please find attached a draft 3-page proposal entitled "Proposal of
> File
> > > > String Literals".
> > >
> > > Any thought about what to do if the input file isn't the exact binary
> data
> > > you
> > > want? For example, suppose you need to encode or decode base64.
> > >
> > > Can you show this can be done with constexpr expressions?
> >
> > As per a normal string literal, the text of the dedicated source file o=
f
> a
> > file string literal will be decoded from source encoding in the usual
> > manner and then encoded in execution encoding (as determined by
> > implementation settings or encoding prefix). From there it will behave
> like
> > a normal string literal.  It is possible with constexpr programming to
> > encode or decode base64.  String literals are "constexpr-compatible".
>
> You're missing my point.
>
> I want to be sure that I could pre-process the contents of the file into
> the
> data I actually want. That data and only that data should be stored in th=
e
> read-only sections of my binary's image.
>
> If you can't prove that, it means I will need to have an extra tool to do
> the
> pre-processing and a buildsystem that runs it before the source gets
> compiled.
> That negates the benefit of having the feature in the first place, since
> the
> extra tool could just as well generate a .h file with the contents I want=
..
>

You can "pre-process" the contents of a string literal using constexpr
programming:

  constexpr auto original_version =3D "original string";

  constexpr fixed_string process_string(fixed_string input) { ... }

  constexpr auto processed_version =3D process_string(original_version);

  int main() { cout << processed_version; }

In practice processed_version will be in the program image, and
original_version won't.

The above ordinary string literal can be replaced with a file string
literal, and the same logic applies.

Isn't that what you mean?

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

--94eb2c1246e0805cf00531501c27
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 Sun, Apr 24, 2016 at 10:03 PM, Thiago Macieira <span dir=3D"ltr">&lt=
;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.o=
rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HO=
EnZb"><div class=3D"h5">On domingo, 24 de abril de 2016 11:38:13 PDT Andrew=
 Tomazos wrote:<br>
&gt; On Sun, Apr 24, 2016 at 3:39 AM, Thiago Macieira &lt;<a href=3D"mailto=
:thiago@macieira.org">thiago@macieira.org</a>&gt;<br>
&gt;<br>
&gt; wrote:<br>
&gt; &gt; On s=C3=A1bado, 23 de abril de 2016 12:16:23 PDT Andrew Tomazos w=
rote:<br>
&gt; &gt; &gt; Please find attached a draft 3-page proposal entitled &quot;=
Proposal of File<br>
&gt; &gt; &gt; String Literals&quot;.<br>
&gt; &gt;<br>
&gt; &gt; Any thought about what to do if the input file isn&#39;t the exac=
t binary data<br>
&gt; &gt; you<br>
&gt; &gt; want? For example, suppose you need to encode or decode base64.<b=
r>
&gt; &gt;<br>
&gt; &gt; Can you show this can be done with constexpr expressions?<br>
&gt;<br>
&gt; As per a normal string literal, the text of the dedicated source file =
of a<br>
&gt; file string literal will be decoded from source encoding in the usual<=
br>
&gt; manner and then encoded in execution encoding (as determined by<br>
&gt; implementation settings or encoding prefix). From there it will behave=
 like<br>
&gt; a normal string literal.=C2=A0 It is possible with constexpr programmi=
ng to<br>
&gt; encode or decode base64.=C2=A0 String literals are &quot;constexpr-com=
patible&quot;.<br>
<br>
</div></div>You&#39;re missing my point.<br>
<br>
I want to be sure that I could pre-process the contents of the file into th=
e<br>
data I actually want. That data and only that data should be stored in the<=
br>
read-only sections of my binary&#39;s image.<br>
<br>
If you can&#39;t prove that, it means I will need to have an extra tool to =
do the<br>
pre-processing and a buildsystem that runs it before the source gets compil=
ed.<br>
That negates the benefit of having the feature in the first place, since th=
e<br>
extra tool could just as well generate a .h file with the contents I want.<=
br></blockquote><div><br></div><div>You can &quot;pre-process&quot; the con=
tents of a string literal using constexpr programming:</div><div><br></div>=
<div>=C2=A0 constexpr auto original_version =3D &quot;original string&quot;=
;</div><div><br></div><div>=C2=A0 constexpr fixed_string process_string(fix=
ed_string input) { ... }<br></div><div><br></div><div>=C2=A0 constexpr auto=
 processed_version =3D process_string(original_version);</div><div><br></di=
v><div>=C2=A0 int main() { cout &lt;&lt; processed_version; }</div><div><br=
></div><div>In practice processed_version will be in the program image, and=
 original_version won&#39;t.</div><div><br></div><div>The above ordinary st=
ring literal can be replaced with a file string literal, and the same logic=
 applies.</div><div><br></div><div>Isn&#39;t that what you mean?</div><div>=
<br></div></div></div></div>

<p></p>

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

--94eb2c1246e0805cf00531501c27--

.

On 2016-04-23 19:27, Moritz Klammler wrote:
> I'm wondering why you have decided to handle a pre-processing action
> with a syntax that doesn't look like this.  I remember having seen
> somebody discuss a similar feature some time ago that looked somehow
> like this.
>
>     #inplace char data "datafile.txt"

I was also wondering about that. In particular, I'll note that tools
that need to do non-compiler-assisted dependency scanning may have an
easier time with this format.

FWIW, I wouldn't ignore the point about being able to do path searches
for this feature. In fact, that may be a critical feature for some folks
(because the path cannot be determined when writing the source, but can
be specified by the build system). In particular, if no path search
occurs, it is impossible to include content from an external source
(i.e. a file not part of the source tree which uses it).

> Another question that should be discussed is whether and how to support
> non-text data.

No, that's not a question. That's a hard requirement ;-). I'm not sure
the proposal doesn't cover this, though?

  auto binary_data = F"image.png"; // char[]
  auto binary_size = sizeof(binary_data) / sizeof(*binary_data);
  auto image = parse_png(binary_data, binary_size);

Any form of this feature that cannot replace qrc is a failure in my book.

That said... I also wonder if being able to select between text vs.
binary mode is important, especially if importing large text blocks is
really a desired feature? (Most of the use cases I've seen have been for
binary files such as images. Andrew's proposal seems to imply uses for
text.)

Note that by "text mode" I mean native-to-C line ending translation.

> Maybe there could be an additional "encoding" prefix for binary data
> that would guarantee a verbatim copy and also suppress NUL-termination.

That's probably a good idea. (That said, I suspect many binary formats
can cope with a superfluous trailing NUL already. Anyway, this might be
useful, but probably isn't critical.)

--
Matthew

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

.

------=_Part_202_2115350795.1461601308575
Content-Type: multipart/alternative;
 boundary="----=_Part_203_6187422.1461601308575"

------=_Part_203_6187422.1461601308575
Content-Type: text/plain; charset=UTF-8

On Saturday, April 23, 2016 at 7:27:18 PM UTC-4, Moritz Klammler wrote:
>
> I can see how the proposed feature would be useful in many contexts and
> provide a clean solution to what if often handled in a messy way today.
>
> I'm wondering why you have decided to handle a pre-processing action
> with a syntax that doesn't look like this.  I remember having seen
> somebody discuss a similar feature some time ago that looked somehow
> like this.
>
>     #inplace char data "datafile.txt"
>

I despise the idea of making a new preprocessor directive. Even moreso, I
despise the idea of having a preprocessor directive *declaring* a variable.

I say we just reuse `#include`. At present, `#include` requires the next
token to be a ", a <, or a preprocessor token. We could just expand that to
a couple of extra options:

#include <options> <file-specifier/pp-token>

The <options> can be a command which alters the nature of the include. With
no options, then it includes the file's tokens into the command stream.

If <options> is `text`, for example, it would include the file as a *string
literal*, with text translation (for newlines and such). If <options> is
`bin`, then it would include the file as a string literal with no
translation. Note that embedded \0 characters would be allowed, and the
string literal would work just as any C++ string literal does with them. So
to use this, you would to this:

auto the_string = #include text "somefile.txt";

Of course, now we get into the question of what *kind* of string literal.
That is, narrow string, UTF-8 string, UTF-16 string (why not allow
inclusion of them?), and so forth. Obviously for `bin`, it would be a
narrow string literal. Perhaps there would be different forms of text:
`text` (narrow), `utf8`, `wide`, `utf16`, etc.

Note that this form of #include should not be *converting* the included
file for these different formats. It is up to the user to make sure that
the file actually stores data in the format the compiler was told to
expect. The only conversion that might be allowed would be the removal of
an initial BOM for the UTF formats.

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

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

<div dir=3D"ltr">On Saturday, April 23, 2016 at 7:27:18 PM UTC-4, Moritz Kl=
ammler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I can see how the=
 proposed feature would be useful in many contexts and
<br>provide a clean solution to what if often handled in a messy way today.
<br>
<br>I&#39;m wondering why you have decided to handle a pre-processing actio=
n
<br>with a syntax that doesn&#39;t look like this. =C2=A0I remember having =
seen
<br>somebody discuss a similar feature some time ago that looked somehow
<br>like this.
<br>
<br>=C2=A0 =C2=A0 #inplace char data &quot;datafile.txt&quot;
<br></blockquote><div><br>I despise the idea of making a new preprocessor d=
irective. Even moreso, I despise the idea of having a preprocessor directiv=
e <i>declaring</i> a variable.<br><br>I say we just reuse `#include`. At pr=
esent, `#include` requires the next token to be a &quot;, a &lt;, or a prep=
rocessor token. We could just expand that to a couple of extra options:<br>=
<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250=
); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px=
; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #800;" class=3D"styled-by-prettify">#include=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">&lt;options&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">file</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">-</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">specifier</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">/</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">pp</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">-</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">token</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&gt;</span></div></code></div><br>The &lt;options&gt; can be a command wh=
ich alters the nature of the include. With no options, then it includes the=
 file&#39;s tokens into the command stream.<br><br>If &lt;options&gt; is `t=
ext`, for example, it would include the file as a <i>string literal</i>, wi=
th text translation (for newlines and such). If &lt;options&gt; is `bin`, t=
hen it would include the file as a string literal with no translation. Note=
 that embedded \0 characters would be allowed, and the string=20
literal would work just as any C++ string literal does with them. So to use=
 this, you would to this:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> the_string </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>#include</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
text </span><span style=3D"color: #080;" class=3D"styled-by-prettify">&quot=
;somefile.txt&quot;</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span></div></code></div><br>Of course, now we get into the ques=
tion of what <i>kind</i> of string literal. That is, narrow string, UTF-8 s=
tring, UTF-16 string (why not allow inclusion of them?), and so forth. Obvi=
ously for `bin`, it would be a narrow string literal. Perhaps there would b=
e different forms of text: `text` (narrow), `utf8`, `wide`, `utf16`, etc.<b=
r><br>Note that this form of #include should not be <i>converting</i> the i=
ncluded file for these different formats. It is up to the user to make sure=
 that the file actually stores data in the format the compiler was told to =
expect. The only conversion that might be allowed would be the removal of a=
n initial BOM for the UTF formats.<br></div></div>

<p></p>

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

------=_Part_203_6187422.1461601308575--
------=_Part_202_2115350795.1461601308575--

.

On segunda-feira, 25 de abril de 2016 16:37:08 PDT Andrew Tomazos wrote:
> > If you can't prove that, it means I will need to have an extra tool to do
> > the
> > pre-processing and a buildsystem that runs it before the source gets
> > compiled.
> > That negates the benefit of having the feature in the first place, since
> > the
> > extra tool could just as well generate a .h file with the contents I want.
>
> You can "pre-process" the contents of a string literal using constexpr
> programming:
>
>   constexpr auto original_version = "original string";
>
>   constexpr fixed_string process_string(fixed_string input) { ... }
>
>   constexpr auto processed_version = process_string(original_version);
>
>   int main() { cout << processed_version; }
>
> In practice processed_version will be in the program image, and
> original_version won't.
>
> The above ordinary string literal can be replaced with a file string
> literal, and the same logic applies.
>
> Isn't that what you mean?

Yes.

I'd like to see a concrete example in the paper, doing some transformation of
the data. As a strawman, it would be nice to know if you could write a
constexpr function that would generate a perfect hashing table given the
complete population of source strings (newline separated).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

--94eb2c1246e0c8b6fd05315259ee
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2016-04-23 19:27, Moritz Klammler wrote:
> > I'm wondering why you have decided to handle a pre-processing action
> > with a syntax that doesn't look like this.  I remember having seen
> > somebody discuss a similar feature some time ago that looked somehow
> > like this.
> >
> >     #inplace char data "datafile.txt"
>
> I was also wondering about that. In particular, I'll note that tools
> that need to do non-compiler-assisted dependency scanning may have an
> easier time with this format.
>

I don't think that is true.  For a tool to accurately do dependency
scanning, it already has to do near full tokenization and preprocessing:

#include MACRO_REPLACE_ME

auto x = R"(
#include "skip_me"
)";

#if some_expression_that_is_false
#include "skip_me_too"
#endif

For approximate dependency scanning, which is of dubious benefit anyway, it
is easy to add the proposed file string literal token pattern to the
scanner.


> > Another question that should be discussed is whether and how to support
>
> non-text data.
>
> No, that's not a question. That's a hard requirement ;-). I'm not sure
> the proposal doesn't cover this, though?
>
>   auto binary_data = F"image.png"; // char[]
>   auto binary_size = sizeof(binary_data) / sizeof(*binary_data);
>   auto image = parse_png(binary_data, binary_size);
>

I don't think that is portable, or advisable.  In particular source files
are decoded in an implementation-defined manner during translation.  Even
if your source encoding was the same as the execution encoding, the
implementation may still reject arbitrary binary sequences which are not
valid for that encoding.

While we might be able to extend the proposal to make this work, I think
the better way to include an image would be to use a link-time or run-time
strategy.

As designed, a use of a file string literal should be interchangable with a
use of a raw string literal, and visa versa, by simply copy-and-pasting the
body.  You would never put an image in a raw string literal (and I don't
think it would work for the previous reason given).

That said... I also wonder if being able to select between text vs.
>
binary mode is important, especially if importing large text blocks is
> really a desired feature? (Most of the use cases I've seen have been for
> binary files such as images. Andrew's proposal seems to imply uses for
> text.)
>

The use cases for file string literals are largely the same as for raw
string literals.  File string literals simply allow you to factor them out
into a dedicated source file, rather than having them in-line.

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

--94eb2c1246e0c8b6fd05315259ee
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 M=
on, Apr 25, 2016 at 5:24 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D=
"">On 2016-04-23 19:27, Moritz Klammler wrote:<br>
&gt; I&#39;m wondering why you have decided to handle a pre-processing acti=
on<br>
&gt; with a syntax that doesn&#39;t look like this.=C2=A0 I remember having=
 seen<br>
&gt; somebody discuss a similar feature some time ago that looked somehow<b=
r>
&gt; like this.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0#inplace char data &quot;datafile.txt&quot;<br>
<br>
</span>I was also wondering about that. In particular, I&#39;ll note that t=
ools<br>
that need to do non-compiler-assisted dependency scanning may have an<br>
easier time with this format.<br></blockquote><div><br></div><div>I don&#39=
;t think that is true.=C2=A0 For a tool to accurately do dependency scannin=
g, it already has to do near full tokenization and preprocessing:</div><div=
><br></div><div>#include MACRO_REPLACE_ME</div><div><br></div><div>auto x =
=3D R&quot;(</div><div>#include &quot;skip_me&quot;</div><div>)&quot;;</div=
><div><br></div><div>#if some_expression_that_is_false</div><div>#include &=
quot;skip_me_too&quot;</div><div>#endif</div><div><br></div><div>For approx=
imate dependency scanning, which is of dubious benefit anyway, it is easy t=
o add the proposed file string literal token pattern to the scanner.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">&gt; Another question that s=
hould be discussed is whether and how to support<br></blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><span class=3D"">
&gt; non-text data.<br>
<br>
</span>No, that&#39;s not a question. That&#39;s a hard requirement ;-). I&=
#39;m not sure<br>
the proposal doesn&#39;t cover this, though?<br>
<br>
=C2=A0 auto binary_data =3D F&quot;image.png&quot;; // char[]<br>
=C2=A0 auto binary_size =3D sizeof(binary_data) / sizeof(*binary_data);<br>
=C2=A0 auto image =3D parse_png(binary_data, binary_size);<br></blockquote>=
<div><br></div><div>I don&#39;t think that is portable, or advisable.=C2=A0=
 In particular source files are decoded in an implementation-defined manner=
 during translation.=C2=A0 Even if your source encoding was the same as the=
 execution encoding, the implementation may still reject arbitrary binary s=
equences which are not valid for that encoding.</div><div><br></div><div>Wh=
ile we might be able to extend the proposal to make this work, I think the =
better way to include an image would be to use a link-time or run-time stra=
tegy.</div><div><br></div><div>As designed, a use of a file string literal =
should be interchangable with a use of a raw string literal, and visa versa=
, by simply copy-and-pasting the body.=C2=A0 You would never put an image i=
n a raw string literal (and I don&#39;t think it would work for the previou=
s reason given).</div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That sa=
id... I also wonder if being able to select between text vs.<br></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
binary mode is important, especially if importing large text blocks is<br>
really a desired feature? (Most of the use cases I&#39;ve seen have been fo=
r<br>
binary files such as images. Andrew&#39;s proposal seems to imply uses for<=
br>
text.)<br></blockquote><div>=C2=A0</div><div>The use cases for file string =
literals are largely the same as for raw string literals.=C2=A0 File string=
 literals simply allow you to factor them out into a dedicated source file,=
 rather than having them in-line.</div><div><br></div></div></div></div>

<p></p>

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

--94eb2c1246e0c8b6fd05315259ee--

.

On 2016-04-25 13:17, Andrew Tomazos wrote:
> On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
>> On 2016-04-23 19:27, Moritz Klammler wrote:
>>> Another question that should be discussed is whether and how to support
>>> non-text data.
>>
>> No, that's not a question. That's a hard requirement ;-). I'm not sure
>> the proposal doesn't cover this, though?
>>
>>   auto binary_data = F"image.png"; // char[]
>>   auto binary_size = sizeof(binary_data) / sizeof(*binary_data);
>>   auto image = parse_png(binary_data, binary_size);
>
> I don't think that is portable, or advisable.  In particular source
> files are decoded in an implementation-defined manner during
> translation.  Even if your source encoding was the same as the
> execution encoding, the implementation may still reject arbitrary
> binary sequences which are not valid for that encoding.
>
> While we might be able to extend the proposal to make this work, I
> think the better way [...]

In that case, I am Strongly Against your proposal. I probably, on some
occasions, want this feature for text. I *definitely* want it for binary
resources, and much more often than I might want it for text.

I think you are missing a significant and important use case, and, if
you don't account for that case, the feature is just begging to be
misused and abused and subject to confusion and surprise breakage.

> I think the better way to include an image would be to use a
> link-time or run-time strategy.

You're welcome to your opinion, but it does not match existing and
widespread practice.

--
Matthew

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

.

------=_Part_485_254510926.1461606314075
Content-Type: multipart/alternative;
 boundary="----=_Part_486_2002972252.1461606314075"

------=_Part_486_2002972252.1461606314075
Content-Type: text/plain; charset=UTF-8

On Monday, April 25, 2016 at 1:38:05 PM UTC-4, Matthew Woehlke wrote:
>
> On 2016-04-25 13:17, Andrew Tomazos wrote:
> > On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
> >> On 2016-04-23 19:27, Moritz Klammler wrote:
> >>> Another question that should be discussed is whether and how to
> support
> >>> non-text data.
> >>
> >> No, that's not a question. That's a hard requirement ;-). I'm not sure
> >> the proposal doesn't cover this, though?
> >>
> >>   auto binary_data = F"image.png"; // char[]
> >>   auto binary_size = sizeof(binary_data) / sizeof(*binary_data);
> >>   auto image = parse_png(binary_data, binary_size);
> >
> > I don't think that is portable, or advisable.  In particular source
> > files are decoded in an implementation-defined manner during
> > translation.  Even if your source encoding was the same as the
> > execution encoding, the implementation may still reject arbitrary
> > binary sequences which are not valid for that encoding.
> >
> > While we might be able to extend the proposal to make this work, I
> > think the better way [...]
>
> In that case, I am Strongly Against your proposal. I probably, on some
> occasions, want this feature for text. I *definitely* want it for binary
> resources, and much more often than I might want it for text.
>
> I think you are missing a significant and important use case, and, if
> you don't account for that case, the feature is just begging to be
> misused and abused and subject to confusion and surprise breakage.
>

I think your second point is the best reason to make sure that binary
inclusions are well-supported. If you give people the ability to include
files as strings, people are going to use it for including binary files.
That is *guaranteed*. So the only options are to have it cause subtle
breakage or to properly support it.

It's better not to do it at all and force us to use our current measures
than to do it halfway.

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

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

<div dir=3D"ltr">On Monday, April 25, 2016 at 1:38:05 PM UTC-4, Matthew Woe=
hlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-04-25 13:17=
, Andrew Tomazos wrote:
<br>&gt; On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
<br>&gt;&gt; On 2016-04-23 19:27, Moritz Klammler wrote:
<br>&gt;&gt;&gt; Another question that should be discussed is whether and h=
ow to support
<br>&gt;&gt;&gt; non-text data.
<br>&gt;&gt;
<br>&gt;&gt; No, that&#39;s not a question. That&#39;s a hard requirement ;=
-). I&#39;m not sure
<br>&gt;&gt; the proposal doesn&#39;t cover this, though?
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 auto binary_data =3D F&quot;image.png&quot;; // char[]
<br>&gt;&gt; =C2=A0 auto binary_size =3D sizeof(binary_data) / sizeof(*bina=
ry_data);
<br>&gt;&gt; =C2=A0 auto image =3D parse_png(binary_data, binary_size);
<br>&gt;=20
<br>&gt; I don&#39;t think that is portable, or advisable. =C2=A0In particu=
lar source
<br>&gt; files are decoded in an implementation-defined manner during
<br>&gt; translation. =C2=A0Even if your source encoding was the same as th=
e
<br>&gt; execution encoding, the implementation may still reject arbitrary
<br>&gt; binary sequences which are not valid for that encoding.
<br>&gt;=20
<br>&gt; While we might be able to extend the proposal to make this work, I
<br>&gt; think the better way [...]
<br>
<br>In that case, I am Strongly Against your proposal. I probably, on some
<br>occasions, want this feature for text. I *definitely* want it for binar=
y
<br>resources, and much more often than I might want it for text.
<br>
<br>I think you are missing a significant and important use case, and, if
<br>you don&#39;t account for that case, the feature is just begging to be
<br>misused and abused and subject to confusion and surprise breakage.<br><=
/blockquote><br>I think your second point is the best reason to make sure t=
hat binary inclusions are well-supported. If you give people the ability to=
 include files as strings, people are going to use it for including binary =
files. That is <i>guaranteed</i>. So the only options are to have it cause =
subtle breakage or to properly support it.<br><br>It&#39;s better not to do=
 it at all and force us to use our current measures than to do it halfway.<=
br></div>

<p></p>

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

------=_Part_486_2002972252.1461606314075--
------=_Part_485_254510926.1461606314075--

.

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

On Mon, Apr 25, 2016 at 7:45 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, April 25, 2016 at 1:38:05 PM UTC-4, Matthew Woehlke wrote:
>>
>> On 2016-04-25 13:17, Andrew Tomazos wrote:
>> > On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
>> >> On 2016-04-23 19:27, Moritz Klammler wrote:
>> >>> Another question that should be discussed is whether and how to
>> support
>> >>> non-text data.
>> >>
>> >> No, that's not a question. That's a hard requirement ;-). I'm not sure
>> >> the proposal doesn't cover this, though?
>> >>
>> >>   auto binary_data = F"image.png"; // char[]
>> >>   auto binary_size = sizeof(binary_data) / sizeof(*binary_data);
>> >>   auto image = parse_png(binary_data, binary_size);
>> >
>> > I don't think that is portable, or advisable.  In particular source
>> > files are decoded in an implementation-defined manner during
>> > translation.  Even if your source encoding was the same as the
>> > execution encoding, the implementation may still reject arbitrary
>> > binary sequences which are not valid for that encoding.
>> >
>> > While we might be able to extend the proposal to make this work, I
>> > think the better way [...]
>>
>> In that case, I am Strongly Against your proposal. I probably, on some
>> occasions, want this feature for text. I *definitely* want it for binary
>> resources, and much more often than I might want it for text.
>>
>> I think you are missing a significant and important use case, and, if
>> you don't account for that case, the feature is just begging to be
>> misused and abused and subject to confusion and surprise breakage.
>>
>
> I think your second point is the best reason to make sure that binary
> inclusions are well-supported. If you give people the ability to include
> files as strings, people are going to use it for including binary files.
> That is *guaranteed*. So the only options are to have it cause subtle
> breakage or to properly support it.
>

Ok, you've convinced me.

We can add a new encoding-prefix "b" for binary.  So it would be:

  auto binary_data = bF"image.png";

I'd need to think about the wording, it will probably be
impementation-defined with a note saying roughly that the data should
undergo no decoding or encoding from source to execution.

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

--001a114e30dc1ad895053152f729
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 M=
on, Apr 25, 2016 at 7:45 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Monday, April 25, 2016 at 1:38:05 PM UTC-4, Matthew Woehlke wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">On 2016-04-25 13:17, Andrew Tomazos=
 wrote:
<br>&gt; On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
<br>&gt;&gt; On 2016-04-23 19:27, Moritz Klammler wrote:
<br>&gt;&gt;&gt; Another question that should be discussed is whether and h=
ow to support
<br>&gt;&gt;&gt; non-text data.
<br>&gt;&gt;
<br>&gt;&gt; No, that&#39;s not a question. That&#39;s a hard requirement ;=
-). I&#39;m not sure
<br>&gt;&gt; the proposal doesn&#39;t cover this, though?
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 auto binary_data =3D F&quot;image.png&quot;; // char[]
<br>&gt;&gt; =C2=A0 auto binary_size =3D sizeof(binary_data) / sizeof(*bina=
ry_data);
<br>&gt;&gt; =C2=A0 auto image =3D parse_png(binary_data, binary_size);
<br>&gt;=20
<br>&gt; I don&#39;t think that is portable, or advisable.=C2=A0 In particu=
lar source
<br>&gt; files are decoded in an implementation-defined manner during
<br>&gt; translation.=C2=A0 Even if your source encoding was the same as th=
e
<br>&gt; execution encoding, the implementation may still reject arbitrary
<br>&gt; binary sequences which are not valid for that encoding.
<br>&gt;=20
<br>&gt; While we might be able to extend the proposal to make this work, I
<br>&gt; think the better way [...]
<br>
<br>In that case, I am Strongly Against your proposal. I probably, on some
<br>occasions, want this feature for text. I *definitely* want it for binar=
y
<br>resources, and much more often than I might want it for text.
<br>
<br>I think you are missing a significant and important use case, and, if
<br>you don&#39;t account for that case, the feature is just begging to be
<br>misused and abused and subject to confusion and surprise breakage.<br><=
/blockquote><br></span>I think your second point is the best reason to make=
 sure that binary inclusions are well-supported. If you give people the abi=
lity to include files as strings, people are going to use it for including =
binary files. That is <i>guaranteed</i>. So the only options are to have it=
 cause subtle breakage or to properly support it.<br></div></blockquote><di=
v>=C2=A0</div><div>Ok, you&#39;ve convinced me.</div><div><br></div><div>We=
 can add a new encoding-prefix &quot;b&quot; for binary.=C2=A0 So it would =
be:</div><div><br></div><div>=C2=A0 auto binary_data =3D bF&quot;image.png&=
quot;;</div><div><br></div><div>I&#39;d need to think about the wording, it=
 will probably be impementation-defined with a note saying roughly that the=
 data should undergo no decoding or encoding from source to execution.</div=
><div><br></div></div></div></div>

<p></p>

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

--001a114e30dc1ad895053152f729--

.

On 2016-04-25 14:01, Andrew Tomazos wrote:
> Ok, you've convinced me.

Thanks. I do think the original idea is also good, I just really want it
for binary data, and... well, Nicol eloquently reiterated my concern
:-). I do think there are enough folks that want something like this for
binary data that explicitly supporting binary data will definitely
*help* the proposal. (And to be fair, when I say "binary data", I really
mean "resources". Some of which... will be text :-). For example, SVG,
GLSL... and I'm sure you could add to that list.)

> We can add a new encoding-prefix "b" for binary.  So it would be:
>
>   auto binary_data = bF"image.png";
>
> I'd need to think about the wording, it will probably be
> impementation-defined with a note saying roughly that the data should
> undergo no decoding or encoding from source to execution.

Right. (I was going to say that feels backwards, but missed that your
end point is "execution". Presumably escaping or something would happen
in the PP stage.)

BTW, what about path search? IIUC, the intent is that the file name is
looked up as if `#include "name"`, correct? It might not be terrible to
state this more explicitly, though...

--
Matthew

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

.

--94eb2c122bdc07c196053164aaaa
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 25, 2016 at 8:20 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2016-04-25 14:01, Andrew Tomazos wrote:
> > Ok, you've convinced me.
>
> Thanks. I do think the original idea is also good, I just really want it
> for binary data, and... well, Nicol eloquently reiterated my concern
> :-). I do think there are enough folks that want something like this for
> binary data that explicitly supporting binary data will definitely
> *help* the proposal. (And to be fair, when I say "binary data", I really
> mean "resources". Some of which... will be text :-). For example, SVG,
> GLSL... and I'm sure you could add to that list.)
>
> > We can add a new encoding-prefix "b" for binary.  So it would be:
> >
> >   auto binary_data = bF"image.png";
> >
> > I'd need to think about the wording, it will probably be
> > impementation-defined with a note saying roughly that the data should
> > undergo no decoding or encoding from source to execution.
>
> Right. (I was going to say that feels backwards, but missed that your
> end point is "execution". Presumably escaping or something would happen
> in the PP stage.)
>
> BTW, what about path search? IIUC, the intent is that the file name is
> looked up as if `#include "name"`, correct? It might not be terrible to
> state this more explicitly, though...
>

The wording says that F"foo" is equivalent to #include "foo" (with some
modifications none of which effect the mapping of paths to source files).
In practice you just put the files in one of your include paths as usual.

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

--94eb2c122bdc07c196053164aaaa
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 M=
on, Apr 25, 2016 at 8:20 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2016-=
04-25 14:01, Andrew Tomazos wrote:<br>
&gt; Ok, you&#39;ve convinced me.<br>
<br>
</span>Thanks. I do think the original idea is also good, I just really wan=
t it<br>
for binary data, and... well, Nicol eloquently reiterated my concern<br>
:-). I do think there are enough folks that want something like this for<br=
>
binary data that explicitly supporting binary data will definitely<br>
*help* the proposal. (And to be fair, when I say &quot;binary data&quot;, I=
 really<br>
mean &quot;resources&quot;. Some of which... will be text :-). For example,=
 SVG,<br>
GLSL... and I&#39;m sure you could add to that list.)<br>
<span><br>
&gt; We can add a new encoding-prefix &quot;b&quot; for binary.=C2=A0 So it=
 would be:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0auto binary_data =3D bF&quot;image.png&quot;;<br>
&gt;<br>
&gt; I&#39;d need to think about the wording, it will probably be<br>
&gt; impementation-defined with a note saying roughly that the data should<=
br>
&gt; undergo no decoding or encoding from source to execution.<br>
<br>
</span>Right. (I was going to say that feels backwards, but missed that you=
r<br>
end point is &quot;execution&quot;. Presumably escaping or something would =
happen<br>
in the PP stage.)<br>
<br>
BTW, what about path search? IIUC, the intent is that the file name is<br>
looked up as if `#include &quot;name&quot;`, correct? It might not be terri=
ble to<br>
state this more explicitly, though...<br></blockquote><div><br></div><div>T=
he wording says that F&quot;foo&quot; is equivalent to #include &quot;foo&q=
uot; (with some modifications none of which effect the mapping of paths to =
source files).=C2=A0 In practice you just put the files in one of your incl=
ude paths as usual.</div><div><br></div></div></div></div>

<p></p>

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

--94eb2c122bdc07c196053164aaaa--

.

------=_Part_2434_329608999.1461879549122
Content-Type: multipart/alternative;
 boundary="----=_Part_2435_683319576.1461879549123"

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

On Monday, April 25, 2016 at 11:01:27 AM UTC-7, Andrew Tomazos wrote:
>
> On Mon, Apr 25, 2016 at 7:45 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Monday, April 25, 2016 at 1:38:05 PM UTC-4, Matthew Woehlke wrote:
>>>
>>> On 2016-04-25 13:17, Andrew Tomazos wrote:=20
>>> > On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:=20
>>> >> On 2016-04-23 19:27, Moritz Klammler wrote:=20
>>> >>> Another question that should be discussed is whether and how to=20
>>> support=20
>>> >>> non-text data.=20
>>> >>=20
>>> >> No, that's not a question. That's a hard requirement ;-). I'm not=20
>>> sure=20
>>> >> the proposal doesn't cover this, though?=20
>>> >>=20
>>> >>   auto binary_data =3D F"image.png"; // char[]=20
>>> >>   auto binary_size =3D sizeof(binary_data) / sizeof(*binary_data);=
=20
>>> >>   auto image =3D parse_png(binary_data, binary_size);=20
>>> >=20
>>> > I don't think that is portable, or advisable.  In particular source=
=20
>>> > files are decoded in an implementation-defined manner during=20
>>> > translation.  Even if your source encoding was the same as the=20
>>> > execution encoding, the implementation may still reject arbitrary=20
>>> > binary sequences which are not valid for that encoding. [...]
>>>
>> =20

> If you give people the ability to include files as strings, people are=20
>> going to use it for including binary files. That is *guaranteed*. So the=
=20
>> only options are to have it cause subtle breakage or to properly support=
 it.
>>
> =20
> Ok, you've convinced me.
>
> We can add a new encoding-prefix "b" for binary.  So it would be:
>
>   auto binary_data =3D bF"image.png";
>
> I'd need to think about the wording, it will probably be=20
> impementation-defined with a note saying roughly that the data should=20
> undergo no decoding or encoding from source to execution.
>

I was just thinking before your post that this has shades of the icky=20
"mode" behavior of fopen(); i.e., it's up to the programmer (and therefore=
=20
often buggy) whether the file is opened in "b"inary or "t"ext mode. What=20
makes for the "often buggy" part is that the path-of-least-resistance=20
happens to work perfectly on Unix/Linux/OSX, and therefore the vast=20
majority of working programmers never need to learn the icky parts.

What happens on a Windows platform when I write

    const char data[] =3D R"(
    )";

? Does data come out equivalent to "\n" or to "\r\n"? Does it depend on the=
=20
compiler (MSVC versus Clang) or not? I don't have a Windows machine to find=
=20
out for myself, sorry.
I would expect that

    const char data[] =3D F"just-a-blank-line.h";

would have the same behavior on Windows as the above program, whatever that=
=20
behavior is.

I would offer that perhaps the syntax

    const char data[] =3D RF"image.png";

is available for "raw binary" (i.e., "I want exactly these bytes at=20
runtime") file input. However, this may be overcomplicating the token=20
grammar; it would be the one(?) case where R"..." did *not* introduce a raw=
=20
string literal token.

Re source and runtime encodings: I have experience with Green Hills=20
compilers in "euc2jis" mode, where the source encoding is EUC and the=20
runtime encoding is Shift-JIS: string literal tokens are assumed to be=20
encoded in EUC, and have to be transcoded to JIS before their bytes are=20
written to the data section. It would indeed be horrible if the programmer=
=20
wrote

    const char data[] =3D F"image.png";

and the bytes that got written to the .rodata section were the "EUC2JIS'ed"=
=20
version of "image.png". However, it would be almost as horrible if the=20
programmer wrote

    const char license_message[] =3D F"license.txt";

and the bytes that got written to the .rodata section were NOT the=20
"EUC2JIS'ed" version of "license.txt". And we definitely can't rely on=20
heuristics like "the extension of the include file" to determine whether we=
=20
should be assuming "source encoding" or "raw encoding". So I would agree=20
with your (Andrew's) idea that we need a way for the programmer to specify=
=20
whether the file input should be treated as "source" or "raw".  I merely=20
offer that prefix-"b" seems awkward to me, and I think prefix-"R" is=20
available.

Either way, your proposal should include an example along the lines of

    const char example[] =3D RF"foo(bar.h)foo";

Does this mean "include bar.h", or "include foo(bar.h)foo" =E2=80=94 and wh=
y?

Re phases of translation: I think your proposal should include an example=
=20
along the lines of

    #define X(x) F ## #x
    #include X(foo) ".h"
    const char example[] =3D X(foo) ".h";

I think the behavior of the above #include is implementation-defined or=20
possibly undefined; I haven't checked.
I'm curious whether you'd make the behavior of the above "example"=20
equivalent to

    const char example[] =3D F"foo" /*followed by the two characters*/ ".h"=
;

or

    const char example[] =3D F"foo.h";

or ill-formed / implementation-defined / undefined. However, if I'm right=
=20
about the behavior of the above #include, I would accept any of these=20
results, or even "I don't care =E2=80=94 let the committee sort it out", be=
cause my=20
impression is that the preprocessor has lots of these little corner cases=
=20
that end up getting sorted out over decades by the vendors, rather than by=
=20
the standard.

Re preprocessing (e.g. base64-decoding), I've often wished that the major=
=20
vendors would provide some Perl-style
http://perldoc.perl.org/functions/open.html
"input from shell-pipe" syntax; for example,

    #include "image.png.64 | base64 -d"
    #include "<(base64 -d image.png.txt)"
    #include "<(wget -O - http://example.com/static/image.png)"

This strikes me as not a matter for top-down standardization but rather for=
=20
some vendor to take the plunge (and expose themselves to all the bad=20
publicity that would come with enabling arbitrary code execution in a C++=
=20
compiler).

my $.02,
=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3171171b-6e10-46bc-a095-9b438504ca2f%40isocpp.or=
g.

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

<div dir=3D"ltr">On Monday, April 25, 2016 at 11:01:27 AM UTC-7, Andrew Tom=
azos wrote:<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"><d=
iv><div class=3D"gmail_quote">On Mon, Apr 25, 2016 at 7:45 PM, Nicol Bolas =
<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"oZVK3fPZBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><span>On Monday, April 25, 2016 at 1:38:05=
 PM UTC-4, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On=
 2016-04-25 13:17, Andrew Tomazos wrote:
<br>&gt; On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
<br>&gt;&gt; On 2016-04-23 19:27, Moritz Klammler wrote:
<br>&gt;&gt;&gt; Another question that should be discussed is whether and h=
ow to support
<br>&gt;&gt;&gt; non-text data.
<br>&gt;&gt;
<br>&gt;&gt; No, that&#39;s not a question. That&#39;s a hard requirement ;=
-). I&#39;m not sure
<br>&gt;&gt; the proposal doesn&#39;t cover this, though?
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 auto binary_data =3D F&quot;image.png&quot;; // char[]
<br>&gt;&gt; =C2=A0 auto binary_size =3D sizeof(binary_data) / sizeof(*bina=
ry_data);
<br>&gt;&gt; =C2=A0 auto image =3D parse_png(binary_data, binary_size);
<br>&gt;=20
<br>&gt; I don&#39;t think that is portable, or advisable.=C2=A0 In particu=
lar source
<br>&gt; files are decoded in an implementation-defined manner during
<br>&gt; translation.=C2=A0 Even if your source encoding was the same as th=
e
<br>&gt; execution encoding, the implementation may still reject arbitrary
<br>&gt; binary sequences which are not valid for that encoding. [...]<br><=
/blockquote></span></div></blockquote></div></div></div></blockquote><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></span>If yo=
u give people the ability to include files as strings, people are going to =
use it for including binary files. That is <i>guaranteed</i>. So the only o=
ptions are to have it cause subtle breakage or to properly support it.<br><=
/div></blockquote><div>=C2=A0</div><div>Ok, you&#39;ve convinced me.</div><=
div><br></div><div>We can add a new encoding-prefix &quot;b&quot; for binar=
y.=C2=A0 So it would be:</div><div><br></div><div>=C2=A0 auto binary_data =
=3D bF&quot;image.png&quot;;</div><div><br></div><div>I&#39;d need to think=
 about the wording, it will probably be impementation-defined with a note s=
aying roughly that the data should undergo no decoding or encoding from sou=
rce to execution.</div></div></div></div></blockquote><div><br></div><div>I=
 was just thinking before your post that this has shades of the icky &quot;=
mode&quot; behavior of fopen(); i.e., it&#39;s up to the programmer (and th=
erefore often buggy) whether the file is opened in &quot;b&quot;inary or &q=
uot;t&quot;ext mode. What makes for the &quot;often buggy&quot; part is tha=
t the path-of-least-resistance happens to work perfectly on Unix/Linux/OSX,=
 and therefore the vast majority of working programmers never need to learn=
 the icky parts.</div><div><br></div><div>What happens on a Windows platfor=
m when I write</div><div><br></div><div>=C2=A0 =C2=A0 const char data[] =3D=
 R&quot;(</div><div>=C2=A0 =C2=A0 )&quot;;</div><div><br></div><div>? Does =
data come out equivalent to &quot;\n&quot; or to &quot;\r\n&quot;? Does it =
depend on the compiler (MSVC versus Clang) or not? I don&#39;t have a Windo=
ws machine to find out for myself, sorry.</div><div>I would expect that</di=
v><div><br></div><div>=C2=A0 =C2=A0 const char data[] =3D F&quot;just-a-bla=
nk-line.h&quot;;</div><div><br></div><div>would have the same behavior on W=
indows as the above program, whatever that behavior is.</div><div><br></div=
><div>I would offer that perhaps the syntax</div><div><br></div><div>=C2=A0=
 =C2=A0 const char data[] =3D RF&quot;image.png&quot;;</div><div><br></div>=
<div>is available for &quot;raw binary&quot; (i.e., &quot;I want exactly th=
ese bytes at runtime&quot;) file input. However, this may be overcomplicati=
ng the token grammar; it would be the one(?) case where R&quot;...&quot; di=
d <i>not</i> introduce a raw string literal token.</div><div><br></div><div=
>Re source and runtime encodings: I have experience with Green Hills compil=
ers in &quot;euc2jis&quot; mode, where the source encoding is EUC and the r=
untime encoding is Shift-JIS: string literal tokens are assumed to be encod=
ed in EUC, and have to be transcoded to JIS before their bytes are written =
to the data section. It would indeed be horrible if the programmer wrote</d=
iv><div><br></div><div>=C2=A0 =C2=A0 const char data[] =3D F&quot;image.png=
&quot;;</div><div><br></div><div>and the bytes that got written to the .rod=
ata section were the &quot;EUC2JIS&#39;ed&quot; version of &quot;image.png&=
quot;. However, it would be almost as horrible if the programmer wrote</div=
><div><br></div><div><div>=C2=A0 =C2=A0 const char license_message[] =3D F&=
quot;license.txt&quot;;</div></div><div><br></div><div>and the bytes that g=
ot written to the .rodata section were NOT the &quot;EUC2JIS&#39;ed&quot; v=
ersion of &quot;license.txt&quot;. And we definitely can&#39;t rely on heur=
istics like &quot;the extension of the include file&quot; to determine whet=
her we should be assuming &quot;source encoding&quot; or &quot;raw encoding=
&quot;. So I would agree with your (Andrew&#39;s) idea that we need a way f=
or the programmer to specify whether the file input should be treated as &q=
uot;source&quot; or &quot;raw&quot;. =C2=A0I merely offer that prefix-&quot=
;b&quot; seems awkward to me, and I think prefix-&quot;R&quot; is available=
..</div><div><br></div><div>Either way, your proposal should include an exam=
ple along the lines of</div><div><br></div><div>=C2=A0 =C2=A0 const char ex=
ample[] =3D RF&quot;foo(bar.h)foo&quot;;</div><div><br></div><div>Does this=
 mean &quot;include bar.h&quot;, or &quot;include foo(bar.h)foo&quot; =E2=
=80=94 and why?</div><div><br></div><div>Re phases of translation: I think =
your proposal should include an example along the lines of</div><div><br></=
div><div>=C2=A0 =C2=A0 #define X(x) F ## #x</div><div>=C2=A0 =C2=A0 #includ=
e X(foo) &quot;.h&quot;</div><div>=C2=A0 =C2=A0 const char example[] =3D X(=
foo) &quot;.h&quot;;</div><div><br></div><div>I think the behavior of the a=
bove #include is implementation-defined or possibly undefined; I haven&#39;=
t checked.</div><div>I&#39;m curious whether you&#39;d make the behavior of=
 the above &quot;example&quot; equivalent to</div><div><br></div><div>=C2=
=A0 =C2=A0 const char example[] =3D F&quot;foo&quot; /*followed by the two =
characters*/ &quot;.h&quot;;</div><div><br></div><div>or</div><div><br></di=
v><div><div>=C2=A0 =C2=A0 const char example[] =3D F&quot;foo.h&quot;;</div=
><div><br></div></div><div>or ill-formed / implementation-defined / undefin=
ed. However, if I&#39;m right about the behavior of the above #include, I w=
ould accept any of these results, or even &quot;I don&#39;t care =E2=80=94 =
let the committee sort it out&quot;, because my impression is that the prep=
rocessor has lots of these little corner cases that end up getting sorted o=
ut over decades by the vendors, rather than by the standard.</div><div><br>=
</div><div>Re preprocessing (e.g. base64-decoding), I&#39;ve often wished t=
hat the major vendors would provide some Perl-style</div><div><a href=3D"ht=
tp://perldoc.perl.org/functions/open.html">http://perldoc.perl.org/function=
s/open.html<br></a></div><div><div>&quot;input from shell-pipe&quot; syntax=
; for example,</div><div><br></div><div></div></div><div>=C2=A0 =C2=A0 #inc=
lude &quot;image.png.64 | base64 -d&quot;</div><div><div>=C2=A0 =C2=A0 #inc=
lude &quot;&lt;(base64 -d image.png.txt)&quot;</div></div><div>=C2=A0 =C2=
=A0 #include &quot;&lt;(wget -O - http://example.com/static/image.png)&quot=
;</div><div><br></div><div>This strikes me as not a matter for top-down sta=
ndardization but rather for some vendor to take the plunge (and expose them=
selves to all the bad publicity that would come with enabling arbitrary cod=
e execution in a C++ compiler).</div><div><br></div><div>my $.02,</div><div=
>=E2=80=93Arthur</div></div>

<p></p>

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

------=_Part_2435_683319576.1461879549123--
------=_Part_2434_329608999.1461879549122--

.

------=_Part_194_842860940.1461945711647
Content-Type: multipart/alternative;
 boundary="----=_Part_195_2093545868.1461945711647"

------=_Part_195_2093545868.1461945711647
Content-Type: text/plain; charset=UTF-8

On Thursday, April 28, 2016 at 5:39:09 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Monday, April 25, 2016 at 11:01:27 AM UTC-7, Andrew Tomazos wrote:
>>
>> On Mon, Apr 25, 2016 at 7:45 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Monday, April 25, 2016 at 1:38:05 PM UTC-4, Matthew Woehlke wrote:
>>>>
>>>> On 2016-04-25 13:17, Andrew Tomazos wrote:
>>>> > On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
>>>> >> On 2016-04-23 19:27, Moritz Klammler wrote:
>>>> >>> Another question that should be discussed is whether and how to
>>>> support
>>>> >>> non-text data.
>>>> >>
>>>> >> No, that's not a question. That's a hard requirement ;-). I'm not
>>>> sure
>>>> >> the proposal doesn't cover this, though?
>>>> >>
>>>> >>   auto binary_data = F"image.png"; // char[]
>>>> >>   auto binary_size = sizeof(binary_data) / sizeof(*binary_data);
>>>> >>   auto image = parse_png(binary_data, binary_size);
>>>> >
>>>> > I don't think that is portable, or advisable.  In particular source
>>>> > files are decoded in an implementation-defined manner during
>>>> > translation.  Even if your source encoding was the same as the
>>>> > execution encoding, the implementation may still reject arbitrary
>>>> > binary sequences which are not valid for that encoding. [...]
>>>>
>>>
>
>> If you give people the ability to include files as strings, people are
>>> going to use it for including binary files. That is *guaranteed*. So
>>> the only options are to have it cause subtle breakage or to properly
>>> support it.
>>>
>>
>> Ok, you've convinced me.
>>
>> We can add a new encoding-prefix "b" for binary.  So it would be:
>>
>>   auto binary_data = bF"image.png";
>>
>> I'd need to think about the wording, it will probably be
>> impementation-defined with a note saying roughly that the data should
>> undergo no decoding or encoding from source to execution.
>>
>
> I was just thinking before your post that this has shades of the icky
> "mode" behavior of fopen(); i.e., it's up to the programmer (and therefore
> often buggy) whether the file is opened in "b"inary or "t"ext mode. What
> makes for the "often buggy" part is that the path-of-least-resistance
> happens to work perfectly on Unix/Linux/OSX, and therefore the vast
> majority of working programmers never need to learn the icky parts.
>
> What happens on a Windows platform when I write
>
>     const char data[] = R"(
>     )";
>
> ? Does data come out equivalent to "\n" or to "\r\n"? Does it depend on
> the compiler (MSVC versus Clang) or not? I don't have a Windows machine to
> find out for myself, sorry.
>

According to the standard:

>  A source-file new-line in a raw string literal results in a new-line in
the resulting execution string-
literal.

So it would be a `\n`, not a `\r\n`.

Granted, the above quote is not in normative text (presumably because
section 2.14.3 makes it more clear). But clearly that is the intent of the
specification. So if VS doesn't do that correctly, then it's broken.

And since VS has had raw string literals for a while now, odds are good
someone would have noticed it if they did it wrong.

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

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

<div dir=3D"ltr">On Thursday, April 28, 2016 at 5:39:09 PM UTC-4, Arthur O&=
#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Monday, April 25, 2016 at 11:01:27 AM UTC-7, Andrew Tomazos wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote">On Mon, Apr 25, 2016 at 7:45 PM, Nicol Bolas <span dir=3D"ltr">&=
lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><span>On Monday, April 25, 2016 at 1=
:38:05 PM UTC-4, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">On 2016-04-25 13:17, Andrew Tomazos wrote:
<br>&gt; On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
<br>&gt;&gt; On 2016-04-23 19:27, Moritz Klammler wrote:
<br>&gt;&gt;&gt; Another question that should be discussed is whether and h=
ow to support
<br>&gt;&gt;&gt; non-text data.
<br>&gt;&gt;
<br>&gt;&gt; No, that&#39;s not a question. That&#39;s a hard requirement ;=
-). I&#39;m not sure
<br>&gt;&gt; the proposal doesn&#39;t cover this, though?
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 auto binary_data =3D F&quot;image.png&quot;; // char[]
<br>&gt;&gt; =C2=A0 auto binary_size =3D sizeof(binary_data) / sizeof(*bina=
ry_data);
<br>&gt;&gt; =C2=A0 auto image =3D parse_png(binary_data, binary_size);
<br>&gt;=20
<br>&gt; I don&#39;t think that is portable, or advisable.=C2=A0 In particu=
lar source
<br>&gt; files are decoded in an implementation-defined manner during
<br>&gt; translation.=C2=A0 Even if your source encoding was the same as th=
e
<br>&gt; execution encoding, the implementation may still reject arbitrary
<br>&gt; binary sequences which are not valid for that encoding. [...]<br><=
/blockquote></span></div></blockquote></div></div></div></blockquote><div>=
=C2=A0</div><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"><div><=
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 dir=3D"ltr"><=
span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"></blockquote></span>If you giv=
e people the ability to include files as strings, people are going to use i=
t for including binary files. That is <i>guaranteed</i>. So the only option=
s are to have it cause subtle breakage or to properly support it.<br></div>=
</blockquote><div>=C2=A0</div><div>Ok, you&#39;ve convinced me.</div><div><=
br></div><div>We can add a new encoding-prefix &quot;b&quot; for binary.=C2=
=A0 So it would be:</div><div><br></div><div>=C2=A0 auto binary_data =3D bF=
&quot;image.png&quot;;</div><div><br></div><div>I&#39;d need to think about=
 the wording, it will probably be impementation-defined with a note saying =
roughly that the data should undergo no decoding or encoding from source to=
 execution.</div></div></div></div></blockquote><div><br></div><div>I was j=
ust thinking before your post that this has shades of the icky &quot;mode&q=
uot; behavior of fopen(); i.e., it&#39;s up to the programmer (and therefor=
e often buggy) whether the file is opened in &quot;b&quot;inary or &quot;t&=
quot;ext mode. What makes for the &quot;often buggy&quot; part is that the =
path-of-least-resistance happens to work perfectly on Unix/Linux/OSX, and t=
herefore the vast majority of working programmers never need to learn the i=
cky parts.</div><div><br></div><div>What happens on a Windows platform when=
 I write</div><div><br></div><div>=C2=A0 =C2=A0 const char data[] =3D R&quo=
t;(</div><div>=C2=A0 =C2=A0 )&quot;;</div><div><br></div><div>? Does data c=
ome out equivalent to &quot;\n&quot; or to &quot;\r\n&quot;? Does it depend=
 on the compiler (MSVC versus Clang) or not? I don&#39;t have a Windows mac=
hine to find out for myself, sorry.</div></div></blockquote><div><br>Accord=
ing to the standard:<br><br>&gt;=C2=A0 A source-file new-line in a raw stri=
ng literal results in a new-line in the resulting execution string-<br>lite=
ral.<br><br>So it would be a `\n`, not a `\r\n`.<br><br>Granted, the above =
quote is not in normative text (presumably because section 2.14.3 makes it =
more clear). But clearly that is the intent of the specification. So if VS =
doesn&#39;t do that correctly, then it&#39;s broken.<br><br>And since VS ha=
s had raw string literals for a while now, odds are good someone would have=
 noticed it if they did it wrong.<br></div></div>

<p></p>

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

------=_Part_195_2093545868.1461945711647--
------=_Part_194_842860940.1461945711647--

.

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

On Fri, Apr 29, 2016 at 6:01 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, April 28, 2016 at 5:39:09 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> On Monday, April 25, 2016 at 11:01:27 AM UTC-7, Andrew Tomazos wrote:
>>>
>>> On Mon, Apr 25, 2016 at 7:45 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Monday, April 25, 2016 at 1:38:05 PM UTC-4, Matthew Woehlke wrote:
>>>>>
>>>>> On 2016-04-25 13:17, Andrew Tomazos wrote:
>>>>> > On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
>>>>> >> On 2016-04-23 19:27, Moritz Klammler wrote:
>>>>> >>> Another question that should be discussed is whether and how to
>>>>> support
>>>>> >>> non-text data.
>>>>> >>
>>>>> >> No, that's not a question. That's a hard requirement ;-). I'm not
>>>>> sure
>>>>> >> the proposal doesn't cover this, though?
>>>>> >>
>>>>> >>   auto binary_data = F"image.png"; // char[]
>>>>> >>   auto binary_size = sizeof(binary_data) / sizeof(*binary_data);
>>>>> >>   auto image = parse_png(binary_data, binary_size);
>>>>> >
>>>>> > I don't think that is portable, or advisable.  In particular source
>>>>> > files are decoded in an implementation-defined manner during
>>>>> > translation.  Even if your source encoding was the same as the
>>>>> > execution encoding, the implementation may still reject arbitrary
>>>>> > binary sequences which are not valid for that encoding. [...]
>>>>>
>>>>
>>
>>> If you give people the ability to include files as strings, people are
>>>> going to use it for including binary files. That is *guaranteed*. So
>>>> the only options are to have it cause subtle breakage or to properly
>>>> support it.
>>>>
>>>
>>> Ok, you've convinced me.
>>>
>>> We can add a new encoding-prefix "b" for binary.  So it would be:
>>>
>>>   auto binary_data = bF"image.png";
>>>
>>> I'd need to think about the wording, it will probably be
>>> impementation-defined with a note saying roughly that the data should
>>> undergo no decoding or encoding from source to execution.
>>>
>>
>> I was just thinking before your post that this has shades of the icky
>> "mode" behavior of fopen(); i.e., it's up to the programmer (and therefore
>> often buggy) whether the file is opened in "b"inary or "t"ext mode. What
>> makes for the "often buggy" part is that the path-of-least-resistance
>> happens to work perfectly on Unix/Linux/OSX, and therefore the vast
>> majority of working programmers never need to learn the icky parts.
>>
>> What happens on a Windows platform when I write
>>
>>     const char data[] = R"(
>>     )";
>>
>> ? Does data come out equivalent to "\n" or to "\r\n"? Does it depend on
>> the compiler (MSVC versus Clang) or not? I don't have a Windows machine to
>> find out for myself, sorry.
>>
>
> According to the standard:
>
> >  A source-file new-line in a raw string literal results in a new-line in
> the resulting execution string-
> literal.
>
> So it would be a `\n`, not a `\r\n`.
>
> Granted, the above quote is not in normative text (presumably because
> section 2.14.3 makes it more clear). But clearly that is the intent of the
> specification. So if VS doesn't do that correctly, then it's broken.
>
> And since VS has had raw string literals for a while now, odds are good
> someone would have noticed it if they did it wrong.
>

Not so fast:

"Physical source file characters are mapped, in an implementation-defined
manner, to the basic source character set (introducing new-line characters
for end-of-line indicators) if necessary. The set of physical source file
characters accepted is implementation-defined."

This mapping is commonly known as the "source encoding".  As a part of the
souce file, the content of raw string literals are input, likewise, in
source encoding.

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

--001a11439b7af6f8920531a2cbee
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 Fri, Apr 29, 2016 at 6:01 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D=
"h5">On Thursday, April 28, 2016 at 5:39:09 PM UTC-4, Arthur O&#39;Dwyer wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><div dir=3D"ltr">On Monday, April 25, 2016 at 11:01:27=
 AM UTC-7, Andrew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote">On Mon, Apr 25, 2016 at 7:45 PM, Nicol Bolas <span d=
ir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><span>On Monday, April 25, 2016 at 1:3=
8:05 PM UTC-4, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex">On 2016-04-25 13:17, =
Andrew Tomazos wrote:
<br>&gt; On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
<br>&gt;&gt; On 2016-04-23 19:27, Moritz Klammler wrote:
<br>&gt;&gt;&gt; Another question that should be discussed is whether and h=
ow to support
<br>&gt;&gt;&gt; non-text data.
<br>&gt;&gt;
<br>&gt;&gt; No, that&#39;s not a question. That&#39;s a hard requirement ;=
-). I&#39;m not sure
<br>&gt;&gt; the proposal doesn&#39;t cover this, though?
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 auto binary_data =3D F&quot;image.png&quot;; // char[]
<br>&gt;&gt; =C2=A0 auto binary_size =3D sizeof(binary_data) / sizeof(*bina=
ry_data);
<br>&gt;&gt; =C2=A0 auto image =3D parse_png(binary_data, binary_size);
<br>&gt;=20
<br>&gt; I don&#39;t think that is portable, or advisable.=C2=A0 In particu=
lar source
<br>&gt; files are decoded in an implementation-defined manner during
<br>&gt; translation.=C2=A0 Even if your source encoding was the same as th=
e
<br>&gt; execution encoding, the implementation may still reject arbitrary
<br>&gt; binary sequences which are not valid for that encoding. [...]<br><=
/blockquote></span></div></blockquote></div></div></div></blockquote><div>=
=C2=A0</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-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><span><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"></blockquote></=
span>If you give people the ability to include files as strings, people are=
 going to use it for including binary files. That is <i>guaranteed</i>. So =
the only options are to have it cause subtle breakage or to properly suppor=
t it.<br></div></blockquote><div>=C2=A0</div><div>Ok, you&#39;ve convinced =
me.</div><div><br></div><div>We can add a new encoding-prefix &quot;b&quot;=
 for binary.=C2=A0 So it would be:</div><div><br></div><div>=C2=A0 auto bin=
ary_data =3D bF&quot;image.png&quot;;</div><div><br></div><div>I&#39;d need=
 to think about the wording, it will probably be impementation-defined with=
 a note saying roughly that the data should undergo no decoding or encoding=
 from source to execution.</div></div></div></div></blockquote><div><br></d=
iv><div>I was just thinking before your post that this has shades of the ic=
ky &quot;mode&quot; behavior of fopen(); i.e., it&#39;s up to the programme=
r (and therefore often buggy) whether the file is opened in &quot;b&quot;in=
ary or &quot;t&quot;ext mode. What makes for the &quot;often buggy&quot; pa=
rt is that the path-of-least-resistance happens to work perfectly on Unix/L=
inux/OSX, and therefore the vast majority of working programmers never need=
 to learn the icky parts.</div><div><br></div><div>What happens on a Window=
s platform when I write</div><div><br></div><div>=C2=A0 =C2=A0 const char d=
ata[] =3D R&quot;(</div><div>=C2=A0 =C2=A0 )&quot;;</div><div><br></div><di=
v>? Does data come out equivalent to &quot;\n&quot; or to &quot;\r\n&quot;?=
 Does it depend on the compiler (MSVC versus Clang) or not? I don&#39;t hav=
e a Windows machine to find out for myself, sorry.</div></div></blockquote>=
</div></div><div><br>According to the standard:<br><br>&gt;=C2=A0 A source-=
file new-line in a raw string literal results in a new-line in the resultin=
g execution string-<br>literal.<br><br>So it would be a `\n`, not a `\r\n`.=
<br><br>Granted, the above quote is not in normative text (presumably becau=
se section 2.14.3 makes it more clear). But clearly that is the intent of t=
he specification. So if VS doesn&#39;t do that correctly, then it&#39;s bro=
ken.<br><br>And since VS has had raw string literals for a while now, odds =
are good someone would have noticed it if they did it wrong.</div></div></b=
lockquote><div><br></div><div>Not so fast:</div><div><br></div><div>&quot;P=
hysical source file characters are mapped, in an implementation-defined man=
ner, to the basic source
character set (introducing new-line characters for end-of-line indicators) =
if necessary. The set of physical
source file characters accepted is implementation-defined.&quot;</div><div>=
<br></div><div>This mapping is commonly known as the &quot;source encoding&=
quot;.=C2=A0 As a part of the souce file, the content of raw string literal=
s are input, likewise, in source encoding.</div><div><br></div></div></div>=
</div>

<p></p>

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

--001a11439b7af6f8920531a2cbee--

.

------=_Part_719_730568738.1461952867991
Content-Type: multipart/alternative;
 boundary="----=_Part_720_1990363186.1461952867992"

------=_Part_720_1990363186.1461952867992
Content-Type: text/plain; charset=UTF-8

On Friday, April 29, 2016 at 1:16:01 PM UTC-4, Andrew Tomazos wrote:
>
> On Fri, Apr 29, 2016 at 6:01 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Thursday, April 28, 2016 at 5:39:09 PM UTC-4, Arthur O'Dwyer wrote:
>>>
>>> On Monday, April 25, 2016 at 11:01:27 AM UTC-7, Andrew Tomazos wrote:
>>>>
>>>> On Mon, Apr 25, 2016 at 7:45 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>>
>>>>> On Monday, April 25, 2016 at 1:38:05 PM UTC-4, Matthew Woehlke wrote:
>>>>>>
>>>>>> On 2016-04-25 13:17, Andrew Tomazos wrote:
>>>>>> > On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
>>>>>> >> On 2016-04-23 19:27, Moritz Klammler wrote:
>>>>>> >>> Another question that should be discussed is whether and how to
>>>>>> support
>>>>>> >>> non-text data.
>>>>>> >>
>>>>>> >> No, that's not a question. That's a hard requirement ;-). I'm not
>>>>>> sure
>>>>>> >> the proposal doesn't cover this, though?
>>>>>> >>
>>>>>> >>   auto binary_data = F"image.png"; // char[]
>>>>>> >>   auto binary_size = sizeof(binary_data) / sizeof(*binary_data);
>>>>>> >>   auto image = parse_png(binary_data, binary_size);
>>>>>> >
>>>>>> > I don't think that is portable, or advisable.  In particular source
>>>>>> > files are decoded in an implementation-defined manner during
>>>>>> > translation.  Even if your source encoding was the same as the
>>>>>> > execution encoding, the implementation may still reject arbitrary
>>>>>> > binary sequences which are not valid for that encoding. [...]
>>>>>>
>>>>>
>>>
>>>> If you give people the ability to include files as strings, people are
>>>>> going to use it for including binary files. That is *guaranteed*. So
>>>>> the only options are to have it cause subtle breakage or to properly
>>>>> support it.
>>>>>
>>>>
>>>> Ok, you've convinced me.
>>>>
>>>> We can add a new encoding-prefix "b" for binary.  So it would be:
>>>>
>>>>   auto binary_data = bF"image.png";
>>>>
>>>> I'd need to think about the wording, it will probably be
>>>> impementation-defined with a note saying roughly that the data should
>>>> undergo no decoding or encoding from source to execution.
>>>>
>>>
>>> I was just thinking before your post that this has shades of the icky
>>> "mode" behavior of fopen(); i.e., it's up to the programmer (and therefore
>>> often buggy) whether the file is opened in "b"inary or "t"ext mode. What
>>> makes for the "often buggy" part is that the path-of-least-resistance
>>> happens to work perfectly on Unix/Linux/OSX, and therefore the vast
>>> majority of working programmers never need to learn the icky parts.
>>>
>>> What happens on a Windows platform when I write
>>>
>>>     const char data[] = R"(
>>>     )";
>>>
>>> ? Does data come out equivalent to "\n" or to "\r\n"? Does it depend on
>>> the compiler (MSVC versus Clang) or not? I don't have a Windows machine to
>>> find out for myself, sorry.
>>>
>>
>> According to the standard:
>>
>> >  A source-file new-line in a raw string literal results in a new-line
>> in the resulting execution string-
>> literal.
>>
>> So it would be a `\n`, not a `\r\n`.
>>
>> Granted, the above quote is not in normative text (presumably because
>> section 2.14.3 makes it more clear). But clearly that is the intent of the
>> specification. So if VS doesn't do that correctly, then it's broken.
>>
>> And since VS has had raw string literals for a while now, odds are good
>> someone would have noticed it if they did it wrong.
>>
>
> Not so fast:
>
> "Physical source file characters are mapped, in an implementation-defined
> manner, to the basic source character set (introducing new-line characters
> for end-of-line indicators) if necessary. The set of physical source file
> characters accepted is implementation-defined."
>
> This mapping is commonly known as the "source encoding".  As a part of the
> souce file, the content of raw string literals are input, likewise, in
> source encoding.
>

Considering that the specification has non-normative examples of raw string
literals and their non-raw equivalents, and those examples explicitly show
that a "source encoding" newline should be equivalent to "\n", then clearly
the writers of the specification believe that the conversion is not
implementation dependent. So either your interpretation or their
interpretation of the spec is wrong.

In any case, it seems to me that "introducing new-line characters for
end-of-line indicators" would mean that the implementation is *not allowed*
to use a platform-specific "end-of-line indicators". That it *must* use the
source character set value of "\n". That is, what "\n" maps to is
implementation defined. That "end-of-line indicators" must become "\n" is
not.

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

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

<div dir=3D"ltr">On Friday, April 29, 2016 at 1:16:01 PM UTC-4, Andrew Toma=
zos wrote:<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"><di=
v><div class=3D"gmail_quote">On Fri, Apr 29, 2016 at 6:01 PM, Nicol Bolas <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"yfua0vWhBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39=
;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div>On Thursday, April 28, 2016 at 5:39:09 PM UTC-4=
, Arthur O&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On Monday, Apr=
il 25, 2016 at 11:01:27 AM UTC-7, Andrew Tomazos wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Mon, Apr 25, 2016 at 7:45 =
PM, Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com=
</a>&gt;</span> wrote:<br><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"><div dir=3D"ltr"><span>On Monday=
, April 25, 2016 at 1:38:05 PM UTC-4, Matthew Woehlke wrote:<blockquote cla=
ss=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=
">On 2016-04-25 13:17, Andrew Tomazos wrote:
<br>&gt; On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
<br>&gt;&gt; On 2016-04-23 19:27, Moritz Klammler wrote:
<br>&gt;&gt;&gt; Another question that should be discussed is whether and h=
ow to support
<br>&gt;&gt;&gt; non-text data.
<br>&gt;&gt;
<br>&gt;&gt; No, that&#39;s not a question. That&#39;s a hard requirement ;=
-). I&#39;m not sure
<br>&gt;&gt; the proposal doesn&#39;t cover this, though?
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 auto binary_data =3D F&quot;image.png&quot;; // char[]
<br>&gt;&gt; =C2=A0 auto binary_size =3D sizeof(binary_data) / sizeof(*bina=
ry_data);
<br>&gt;&gt; =C2=A0 auto image =3D parse_png(binary_data, binary_size);
<br>&gt;=20
<br>&gt; I don&#39;t think that is portable, or advisable.=C2=A0 In particu=
lar source
<br>&gt; files are decoded in an implementation-defined manner during
<br>&gt; translation.=C2=A0 Even if your source encoding was the same as th=
e
<br>&gt; execution encoding, the implementation may still reject arbitrary
<br>&gt; binary sequences which are not valid for that encoding. [...]<br><=
/blockquote></span></div></blockquote></div></div></div></blockquote><div>=
=C2=A0</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-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><span><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"></blockquote></=
span>If you give people the ability to include files as strings, people are=
 going to use it for including binary files. That is <i>guaranteed</i>. So =
the only options are to have it cause subtle breakage or to properly suppor=
t it.<br></div></blockquote><div>=C2=A0</div><div>Ok, you&#39;ve convinced =
me.</div><div><br></div><div>We can add a new encoding-prefix &quot;b&quot;=
 for binary.=C2=A0 So it would be:</div><div><br></div><div>=C2=A0 auto bin=
ary_data =3D bF&quot;image.png&quot;;</div><div><br></div><div>I&#39;d need=
 to think about the wording, it will probably be impementation-defined with=
 a note saying roughly that the data should undergo no decoding or encoding=
 from source to execution.</div></div></div></div></blockquote><div><br></d=
iv><div>I was just thinking before your post that this has shades of the ic=
ky &quot;mode&quot; behavior of fopen(); i.e., it&#39;s up to the programme=
r (and therefore often buggy) whether the file is opened in &quot;b&quot;in=
ary or &quot;t&quot;ext mode. What makes for the &quot;often buggy&quot; pa=
rt is that the path-of-least-resistance happens to work perfectly on Unix/L=
inux/OSX, and therefore the vast majority of working programmers never need=
 to learn the icky parts.</div><div><br></div><div>What happens on a Window=
s platform when I write</div><div><br></div><div>=C2=A0 =C2=A0 const char d=
ata[] =3D R&quot;(</div><div>=C2=A0 =C2=A0 )&quot;;</div><div><br></div><di=
v>? Does data come out equivalent to &quot;\n&quot; or to &quot;\r\n&quot;?=
 Does it depend on the compiler (MSVC versus Clang) or not? I don&#39;t hav=
e a Windows machine to find out for myself, sorry.</div></div></blockquote>=
</div></div><div><br>According to the standard:<br><br>&gt;=C2=A0 A source-=
file new-line in a raw string literal results in a new-line in the resultin=
g execution string-<br>literal.<br><br>So it would be a `\n`, not a `\r\n`.=
<br><br>Granted, the above quote is not in normative text (presumably becau=
se section 2.14.3 makes it more clear). But clearly that is the intent of t=
he specification. So if VS doesn&#39;t do that correctly, then it&#39;s bro=
ken.<br><br>And since VS has had raw string literals for a while now, odds =
are good someone would have noticed it if they did it wrong.</div></div></b=
lockquote><div><br></div><div>Not so fast:</div><div><br></div><div>&quot;P=
hysical source file characters are mapped, in an implementation-defined man=
ner, to the basic source
character set (introducing new-line characters for end-of-line indicators) =
if necessary. The set of physical
source file characters accepted is implementation-defined.&quot;</div><div>=
<br></div><div>This mapping is commonly known as the &quot;source encoding&=
quot;.=C2=A0 As a part of the souce file, the content of raw string literal=
s are input, likewise, in source encoding.</div></div></div></div></blockqu=
ote><div><br>Considering that the specification has non-normative examples =
of raw string literals and their non-raw equivalents, and those examples ex=
plicitly show that a &quot;source encoding&quot; newline should be equivale=
nt to &quot;\n&quot;, then clearly the writers of the specification believe=
 that the conversion is not implementation dependent. So either your interp=
retation or their interpretation of the spec is wrong.<br><br>In any case, =
it seems to me that &quot;introducing new-line characters for end-of-line i=
ndicators&quot; would mean that the implementation is <i>not allowed</i> to=
 use a platform-specific &quot;end-of-line indicators&quot;. That it <i>mus=
t</i> use the source character set value of &quot;\n&quot;. That is, what &=
quot;\n&quot; maps to is implementation defined. That &quot;end-of-line ind=
icators&quot; must become &quot;\n&quot; is not.<br></div></div>

<p></p>

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

------=_Part_720_1990363186.1461952867992--
------=_Part_719_730568738.1461952867991--

.

--94eb2c11b6ccd449b00531bb1b87
Content-Type: text/plain; charset=UTF-8

On Fri, Apr 29, 2016 at 8:01 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Friday, April 29, 2016 at 1:16:01 PM UTC-4, Andrew Tomazos wrote:
>
>> On Fri, Apr 29, 2016 at 6:01 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Thursday, April 28, 2016 at 5:39:09 PM UTC-4, Arthur O'Dwyer wrote:
>>>>
>>>> On Monday, April 25, 2016 at 11:01:27 AM UTC-7, Andrew Tomazos wrote:
>>>>>
>>>>> On Mon, Apr 25, 2016 at 7:45 PM, Nicol Bolas <jmck...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Monday, April 25, 2016 at 1:38:05 PM UTC-4, Matthew Woehlke wrote:
>>>>>>>
>>>>>>> On 2016-04-25 13:17, Andrew Tomazos wrote:
>>>>>>> > On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
>>>>>>> >> On 2016-04-23 19:27, Moritz Klammler wrote:
>>>>>>> >>> Another question that should be discussed is whether and how to
>>>>>>> support
>>>>>>> >>> non-text data.
>>>>>>> >>
>>>>>>> >> No, that's not a question. That's a hard requirement ;-). I'm not
>>>>>>> sure
>>>>>>> >> the proposal doesn't cover this, though?
>>>>>>> >>
>>>>>>> >>   auto binary_data = F"image.png"; // char[]
>>>>>>> >>   auto binary_size = sizeof(binary_data) / sizeof(*binary_data);
>>>>>>> >>   auto image = parse_png(binary_data, binary_size);
>>>>>>> >
>>>>>>> > I don't think that is portable, or advisable.  In particular
>>>>>>> source
>>>>>>> > files are decoded in an implementation-defined manner during
>>>>>>> > translation.  Even if your source encoding was the same as the
>>>>>>> > execution encoding, the implementation may still reject arbitrary
>>>>>>> > binary sequences which are not valid for that encoding. [...]
>>>>>>>
>>>>>>
>>>>
>>>>> If you give people the ability to include files as strings, people are
>>>>>> going to use it for including binary files. That is *guaranteed*. So
>>>>>> the only options are to have it cause subtle breakage or to properly
>>>>>> support it.
>>>>>>
>>>>>
>>>>> Ok, you've convinced me.
>>>>>
>>>>> We can add a new encoding-prefix "b" for binary.  So it would be:
>>>>>
>>>>>   auto binary_data = bF"image.png";
>>>>>
>>>>> I'd need to think about the wording, it will probably be
>>>>> impementation-defined with a note saying roughly that the data should
>>>>> undergo no decoding or encoding from source to execution.
>>>>>
>>>>
>>>> I was just thinking before your post that this has shades of the icky
>>>> "mode" behavior of fopen(); i.e., it's up to the programmer (and therefore
>>>> often buggy) whether the file is opened in "b"inary or "t"ext mode. What
>>>> makes for the "often buggy" part is that the path-of-least-resistance
>>>> happens to work perfectly on Unix/Linux/OSX, and therefore the vast
>>>> majority of working programmers never need to learn the icky parts.
>>>>
>>>> What happens on a Windows platform when I write
>>>>
>>>>     const char data[] = R"(
>>>>     )";
>>>>
>>>> ? Does data come out equivalent to "\n" or to "\r\n"? Does it depend on
>>>> the compiler (MSVC versus Clang) or not? I don't have a Windows machine to
>>>> find out for myself, sorry.
>>>>
>>>
>>> According to the standard:
>>>
>>> >  A source-file new-line in a raw string literal results in a new-line
>>> in the resulting execution string-
>>> literal.
>>>
>>> So it would be a `\n`, not a `\r\n`.
>>>
>>> Granted, the above quote is not in normative text (presumably because
>>> section 2.14.3 makes it more clear). But clearly that is the intent of the
>>> specification. So if VS doesn't do that correctly, then it's broken.
>>>
>>> And since VS has had raw string literals for a while now, odds are good
>>> someone would have noticed it if they did it wrong.
>>>
>>
>> Not so fast:
>>
>> "Physical source file characters are mapped, in an implementation-defined
>> manner, to the basic source character set (introducing new-line characters
>> for end-of-line indicators) if necessary. The set of physical source file
>> characters accepted is implementation-defined."
>>
>> This mapping is commonly known as the "source encoding".  As a part of
>> the souce file, the content of raw string literals are input, likewise, in
>> source encoding.
>>
>
> Considering that the specification has non-normative examples of raw
> string literals and their non-raw equivalents, and those examples
> explicitly show that a "source encoding" newline should be equivalent to
> "\n", then clearly the writers of the specification believe that the
> conversion is not implementation dependent. So either your interpretation
> or their interpretation of the spec is wrong.
>

The examples you are referring to do not show how the new-line is encoded
in the original physical source file.  They cannot, unless they show the
hex dump of the bytes of the physical source file.  The examples just show
that the "text" new line in the raw string literal (after decoding) can be
equivalent to an escaped new line '\n' in an ordinary string literal.  I
think the motivation of the example was just to show that raw string
literals can contain embedded new lines (unlike ordinary string literals) -
among other this.

In Table 7 it says '\n' maps to NL(LF) and that '\r' maps to CR, and offers
no further definition of what NL( LF) and CR are.  I assume NL(LF) is the
new line character that is a member of the basic source character set, and
that CR is the carriage return that is a member of the basic execution
character set.  I think the these basic source character set new lines are
the same "new-line characters" refered to in the "introducing new-line
characters for end-of-line indicators" during phase 1 source decoding.

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

--94eb2c11b6ccd449b00531bb1b87
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 Fri, Apr 29, 2016 at 8:01 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@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">On F=
riday, April 29, 2016 at 1:16:01 PM UTC-4, Andrew Tomazos wrote:<div><div><=
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"><div><div class=3D"=
gmail_quote">On Fri, Apr 29, 2016 at 6:01 PM, Nicol Bolas <span dir=3D"ltr"=
>&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex"><div dir=3D"ltr"><div><div>On Thursday, April 28, 2016 at 5:39:09=
 PM UTC-4, Arthur O&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On Mo=
nday, April 25, 2016 at 11:01:27 AM UTC-7, Andrew Tomazos wrote:<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"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Mon, Apr 25, 2016=
 at 7:45 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span=
>On Monday, April 25, 2016 at 1:38:05 PM UTC-4, Matthew Woehlke wrote:<bloc=
kquote 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;paddin=
g-left:1ex">On 2016-04-25 13:17, Andrew Tomazos wrote:
<br>&gt; On Mon, Apr 25, 2016 at 5:24 PM, Matthew Woehlke wrote:
<br>&gt;&gt; On 2016-04-23 19:27, Moritz Klammler wrote:
<br>&gt;&gt;&gt; Another question that should be discussed is whether and h=
ow to support
<br>&gt;&gt;&gt; non-text data.
<br>&gt;&gt;
<br>&gt;&gt; No, that&#39;s not a question. That&#39;s a hard requirement ;=
-). I&#39;m not sure
<br>&gt;&gt; the proposal doesn&#39;t cover this, though?
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 auto binary_data =3D F&quot;image.png&quot;; // char[]
<br>&gt;&gt; =C2=A0 auto binary_size =3D sizeof(binary_data) / sizeof(*bina=
ry_data);
<br>&gt;&gt; =C2=A0 auto image =3D parse_png(binary_data, binary_size);
<br>&gt;=20
<br>&gt; I don&#39;t think that is portable, or advisable.=C2=A0 In particu=
lar source
<br>&gt; files are decoded in an implementation-defined manner during
<br>&gt; translation.=C2=A0 Even if your source encoding was the same as th=
e
<br>&gt; execution encoding, the implementation may still reject arbitrary
<br>&gt; binary sequences which are not valid for that encoding. [...]<br><=
/blockquote></span></div></blockquote></div></div></div></blockquote><div>=
=C2=A0</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-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><span><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"></blockquote></=
span>If you give people the ability to include files as strings, people are=
 going to use it for including binary files. That is <i>guaranteed</i>. So =
the only options are to have it cause subtle breakage or to properly suppor=
t it.<br></div></blockquote><div>=C2=A0</div><div>Ok, you&#39;ve convinced =
me.</div><div><br></div><div>We can add a new encoding-prefix &quot;b&quot;=
 for binary.=C2=A0 So it would be:</div><div><br></div><div>=C2=A0 auto bin=
ary_data =3D bF&quot;image.png&quot;;</div><div><br></div><div>I&#39;d need=
 to think about the wording, it will probably be impementation-defined with=
 a note saying roughly that the data should undergo no decoding or encoding=
 from source to execution.</div></div></div></div></blockquote><div><br></d=
iv><div>I was just thinking before your post that this has shades of the ic=
ky &quot;mode&quot; behavior of fopen(); i.e., it&#39;s up to the programme=
r (and therefore often buggy) whether the file is opened in &quot;b&quot;in=
ary or &quot;t&quot;ext mode. What makes for the &quot;often buggy&quot; pa=
rt is that the path-of-least-resistance happens to work perfectly on Unix/L=
inux/OSX, and therefore the vast majority of working programmers never need=
 to learn the icky parts.</div><div><br></div><div>What happens on a Window=
s platform when I write</div><div><br></div><div>=C2=A0 =C2=A0 const char d=
ata[] =3D R&quot;(</div><div>=C2=A0 =C2=A0 )&quot;;</div><div><br></div><di=
v>? Does data come out equivalent to &quot;\n&quot; or to &quot;\r\n&quot;?=
 Does it depend on the compiler (MSVC versus Clang) or not? I don&#39;t hav=
e a Windows machine to find out for myself, sorry.</div></div></blockquote>=
</div></div><div><br>According to the standard:<br><br>&gt;=C2=A0 A source-=
file new-line in a raw string literal results in a new-line in the resultin=
g execution string-<br>literal.<br><br>So it would be a `\n`, not a `\r\n`.=
<br><br>Granted, the above quote is not in normative text (presumably becau=
se section 2.14.3 makes it more clear). But clearly that is the intent of t=
he specification. So if VS doesn&#39;t do that correctly, then it&#39;s bro=
ken.<br><br>And since VS has had raw string literals for a while now, odds =
are good someone would have noticed it if they did it wrong.</div></div></b=
lockquote><div><br></div><div>Not so fast:</div><div><br></div><div>&quot;P=
hysical source file characters are mapped, in an implementation-defined man=
ner, to the basic source
character set (introducing new-line characters for end-of-line indicators) =
if necessary. The set of physical
source file characters accepted is implementation-defined.&quot;</div><div>=
<br></div><div>This mapping is commonly known as the &quot;source encoding&=
quot;.=C2=A0 As a part of the souce file, the content of raw string literal=
s are input, likewise, in source encoding.</div></div></div></div></blockqu=
ote></div></div><div><br>Considering that the specification has non-normati=
ve examples of raw string literals and their non-raw equivalents, and those=
 examples explicitly show that a &quot;source encoding&quot; newline should=
 be equivalent to &quot;\n&quot;, then clearly the writers of the specifica=
tion believe that the conversion is not implementation dependent. So either=
 your interpretation or their interpretation of the spec is wrong.<br></div=
></div></blockquote><div><br></div><div>The examples you are referring to d=
o not show how the new-line is encoded in the original physical source file=
..=C2=A0 They cannot, unless they show the hex dump of the bytes of the phys=
ical source file.=C2=A0 The examples just show that the &quot;text&quot; ne=
w line in the raw string literal (after decoding) can be equivalent to an e=
scaped new line &#39;\n&#39; in an ordinary string literal.=C2=A0 I think t=
he motivation of the example was just to show that raw string literals can =
contain embedded new lines (unlike ordinary string literals) - among other =
this.</div><div><br></div><div>In Table 7 it says &#39;\n&#39; maps to NL(L=
F) and that &#39;\r&#39; maps to CR, and offers no further definition of wh=
at NL( LF) and CR are.=C2=A0 I assume NL(LF) is the new line character that=
 is a member of the basic source character set, and that CR is the carriage=
 return that is a member of the basic execution character set.=C2=A0 I thin=
k the these basic source character set new lines are the same &quot;new-lin=
e characters&quot; refered to in the &quot;introducing new-line characters =
for end-of-line indicators&quot; during phase 1 source decoding.</div><div>=
<br></div></div></div></div>

<p></p>

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

--94eb2c11b6ccd449b00531bb1b87--

.

------=_Part_489_1878381570.1462067266720
Content-Type: multipart/alternative;
 boundary="----=_Part_490_2143438556.1462067266721"

------=_Part_490_2143438556.1462067266721
Content-Type: text/plain; charset=UTF-8

On Saturday, April 30, 2016 at 6:16:20 PM UTC-4, Andrew Tomazos wrote:
>
> On Fri, Apr 29, 2016 at 8:01 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Friday, April 29, 2016 at 1:16:01 PM UTC-4, Andrew Tomazos wrote:
>>
>>> On Fri, Apr 29, 2016 at 6:01 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Thursday, April 28, 2016 at 5:39:09 PM UTC-4, Arthur O'Dwyer wrote:
>>>>>
>>>>> I was just thinking before your post that this has shades of the icky
>>>>> "mode" behavior of fopen(); i.e., it's up to the programmer (and therefore
>>>>> often buggy) whether the file is opened in "b"inary or "t"ext mode. What
>>>>> makes for the "often buggy" part is that the path-of-least-resistance
>>>>> happens to work perfectly on Unix/Linux/OSX, and therefore the vast
>>>>> majority of working programmers never need to learn the icky parts.
>>>>>
>>>>> What happens on a Windows platform when I write
>>>>>
>>>>>     const char data[] = R"(
>>>>>     )";
>>>>>
>>>>> ? Does data come out equivalent to "\n" or to "\r\n"? Does it depend
>>>>> on the compiler (MSVC versus Clang) or not? I don't have a Windows machine
>>>>> to find out for myself, sorry.
>>>>>
>>>>
>>>> According to the standard:
>>>>
>>>> >  A source-file new-line in a raw string literal results in a new-line
>>>> in the resulting execution string-
>>>> literal.
>>>>
>>>> So it would be a `\n`, not a `\r\n`.
>>>>
>>>> Granted, the above quote is not in normative text (presumably because
>>>> section 2.14.3 makes it more clear). But clearly that is the intent of the
>>>> specification. So if VS doesn't do that correctly, then it's broken.
>>>>
>>>> And since VS has had raw string literals for a while now, odds are good
>>>> someone would have noticed it if they did it wrong.
>>>>
>>>
>>> Not so fast:
>>>
>>> "Physical source file characters are mapped, in an
>>> implementation-defined manner, to the basic source character set
>>> (introducing new-line characters for end-of-line indicators) if necessary.
>>> The set of physical source file characters accepted is
>>> implementation-defined."
>>>
>>> This mapping is commonly known as the "source encoding".  As a part of
>>> the souce file, the content of raw string literals are input, likewise, in
>>> source encoding.
>>>
>>
>> Considering that the specification has non-normative examples of raw
>> string literals and their non-raw equivalents, and those examples
>> explicitly show that a "source encoding" newline should be equivalent to
>> "\n", then clearly the writers of the specification believe that the
>> conversion is not implementation dependent. So either your interpretation
>> or their interpretation of the spec is wrong.
>>
>
> The examples you are referring to do not show how the new-line is encoded
> in the original physical source file.
>

It doesn't matter how it's encoded in the original physical source file. So
long as the line endings in the physical source file are converted to
proper C++ newline characters, everything works fine.

Consider what would happen if you perform #include on a file that consists
solely of a raw string literal. Textual file inclusion should be the
equivalent of that: it does whatever #include would do, if the bytes of
text file being included had been wrapped in a raw string (of the
appropriate encoding).


> They cannot, unless they show the hex dump of the bytes of the physical
> source file.  The examples just show that the "text" new line in the raw
> string literal (after decoding) can be equivalent to an escaped new line
> '\n' in an ordinary string literal.  I think the motivation of the example
> was just to show that raw string literals can contain embedded new lines
> (unlike ordinary string literals) - among other this.
>

The example in the standard does not use the term "can be equivalent".
Indeed, the example's terminology needs no room for doubt. Observe:

Assuming no whitespace at the beginning of lines in the following example,
> the assert will succeed:
>

>
const char* p = R"(a\
> b
> c)";
> assert(std::strcmp(p, "a\\\nb\nc") == 0);
>
>
"the assert *will succeed*" does not leave room for the ambiguity you seem
to hold to. All of the other examples use the term "is equivalent", not
"can be equivalent".

So either the standard has a defect that should be corrected or your view
of how raw string literals are allowed to translate is wrong.

In Table 7 it says '\n' maps to NL(LF) and that '\r' maps to CR, and offers
> no further definition of what NL( LF) and CR are.
>

Sure it does. It defines '\n' to be "NL(LF)", but it *also* declares it to
be the grammatical construct "new-line". Which is used in several places in
the C++ grammar.

How they're encoded is essentially irrelevant. What matters is that the
character set must provide a value that represents '\n', and when a file is
loaded, platform-specific new-lines must be converted into 'new-line'.

I assume NL(LF) is the new line character that is a member of the basic
> source character set, and that CR is the carriage return that is a member
> of the basic execution character set.  I think the these basic source
> character set new lines are the same "new-line characters" refered to in
> the "introducing new-line characters for end-of-line indicators" during
> phase 1 source decoding.
>

You don't have to think; it says so. "new-line" is used quite frequently in
the grammar.

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

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

<div dir=3D"ltr">On Saturday, April 30, 2016 at 6:16:20 PM UTC-4, Andrew To=
mazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote">On Fri, Apr 29, 2016 at 8:01 PM, Nicol Bolas=
 <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"TFFZv-0ABQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#=
39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">On Friday, April 29, 2016 at 1:16:01 PM U=
TC-4, Andrew Tomazos wrote:<div><div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Apr 29, 2016 at =
6:01 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div>=
On Thursday, April 28, 2016 at 5:39:09 PM UTC-4, Arthur O&#39;Dwyer wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div></div><div>I was just thinking before=
 your post that this has shades of the icky &quot;mode&quot; behavior of fo=
pen(); i.e., it&#39;s up to the programmer (and therefore often buggy) whet=
her the file is opened in &quot;b&quot;inary or &quot;t&quot;ext mode. What=
 makes for the &quot;often buggy&quot; part is that the path-of-least-resis=
tance happens to work perfectly on Unix/Linux/OSX, and therefore the vast m=
ajority of working programmers never need to learn the icky parts.</div><di=
v><br></div><div>What happens on a Windows platform when I write</div><div>=
<br></div><div>=C2=A0 =C2=A0 const char data[] =3D R&quot;(</div><div>=C2=
=A0 =C2=A0 )&quot;;</div><div><br></div><div>? Does data come out equivalen=
t to &quot;\n&quot; or to &quot;\r\n&quot;? Does it depend on the compiler =
(MSVC versus Clang) or not? I don&#39;t have a Windows machine to find out =
for myself, sorry.</div></div></blockquote></div></div><div><br>According t=
o the standard:<br><br>&gt;=C2=A0 A source-file new-line in a raw string li=
teral results in a new-line in the resulting execution string-<br>literal.<=
br><br>So it would be a `\n`, not a `\r\n`.<br><br>Granted, the above quote=
 is not in normative text (presumably because section 2.14.3 makes it more =
clear). But clearly that is the intent of the specification. So if VS doesn=
&#39;t do that correctly, then it&#39;s broken.<br><br>And since VS has had=
 raw string literals for a while now, odds are good someone would have noti=
ced it if they did it wrong.</div></div></blockquote><div><br></div><div>No=
t so fast:</div><div><br></div><div>&quot;Physical source file characters a=
re mapped, in an implementation-defined manner, to the basic source
character set (introducing new-line characters for end-of-line indicators) =
if necessary. The set of physical
source file characters accepted is implementation-defined.&quot;</div><div>=
<br></div><div>This mapping is commonly known as the &quot;source encoding&=
quot;.=C2=A0 As a part of the souce file, the content of raw string literal=
s are input, likewise, in source encoding.</div></div></div></div></blockqu=
ote></div></div><div><br>Considering that the specification has non-normati=
ve examples of raw string literals and their non-raw equivalents, and those=
 examples explicitly show that a &quot;source encoding&quot; newline should=
 be equivalent to &quot;\n&quot;, then clearly the writers of the specifica=
tion believe that the conversion is not implementation dependent. So either=
 your interpretation or their interpretation of the spec is wrong.<br></div=
></div></blockquote><div><br></div><div>The examples you are referring to d=
o not show how the new-line is encoded in the original physical source file=
..</div></div></div></div></blockquote><div><br>It doesn&#39;t matter how it=
&#39;s encoded in the original physical source file. So long as the line en=
dings in the physical source file are converted to proper C++ newline chara=
cters, everything works fine.<br><br>Consider what would happen if you perf=
orm #include on a file that consists solely of a raw string literal. Textua=
l file inclusion should be the equivalent of that: it does whatever #includ=
e would do, if the bytes of text file being included had been wrapped in a =
raw string (of the appropriate encoding).<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div>They cannot, unless they show the hex dump of the bytes of the physi=
cal source file.=C2=A0 The examples just show that the &quot;text&quot; new=
 line in the raw string literal (after decoding) can be equivalent to an es=
caped new line &#39;\n&#39; in an ordinary string literal.=C2=A0 I think th=
e motivation of the example was just to show that raw string literals can c=
ontain embedded new lines (unlike ordinary string literals) - among other t=
his.</div></div></div></div></blockquote><div><br>The example in the standa=
rd does not use the term &quot;can be equivalent&quot;. Indeed, the example=
&#39;s terminology needs no room for doubt. Observe:<br><br><blockquote sty=
le=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
 padding-left: 1ex;" class=3D"gmail_quote"><div>Assuming no whitespace at t=
he beginning of lines in the following example, the assert will succeed:</d=
iv></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left=
: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><=
div>=C2=A0</div></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex=
; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"g=
mail_quote"><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">=
const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">char</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> p </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> R</span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify">&quot;(a\<br>b<br>c)&quot;</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">assert</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
strcmp</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">p</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
080;" class=3D"styled-by-prettify">&quot;a\\\nb\nc&quot;</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span></div></code></div><br></blockquote><div><br>&quot;the asse=
rt <b>will succeed</b>&quot; does not leave room for the ambiguity you seem=
 to hold to. All of the other examples use the term &quot;is equivalent&quo=
t;, not &quot;can be equivalent&quot;.<br><br>So either the standard has a =
defect that should be corrected or your view of how raw string literals are=
 allowed to translate is wrong.<br><br></div></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=
In Table 7 it says &#39;\n&#39; maps to NL(LF) and that &#39;\r&#39; maps t=
o CR, and offers no further definition of what NL( LF) and CR are.</div></d=
iv></div></div></blockquote><div><br>Sure it does. It defines &#39;\n&#39; =
to be &quot;NL(LF)&quot;, but it <i>also</i> declares it to be the grammati=
cal construct &quot;new-line&quot;. Which is used in several places in the =
C++ grammar.<br><br>How they&#39;re encoded is essentially irrelevant. What=
 matters is that the character set must provide a value that represents &#3=
9;\n&#39;, and when a file is loaded, platform-specific new-lines must be c=
onverted into &#39;new-line&#39;.<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>I as=
sume NL(LF) is the new line character that is a member of the basic source =
character set, and that CR is the carriage return that is a member of the b=
asic execution character set.=C2=A0 I think the these basic source characte=
r set new lines are the same &quot;new-line characters&quot; refered to in =
the &quot;introducing new-line characters for end-of-line indicators&quot; =
during phase 1 source decoding.</div></div></div></div></blockquote><div><b=
r>You don&#39;t have to think; it says so. &quot;new-line&quot; is used qui=
te frequently in the grammar.<br></div></div>

<p></p>

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

------=_Part_490_2143438556.1462067266721--
------=_Part_489_1878381570.1462067266720--

.

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

On Sat, Apr 30, 2016 at 6:47 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Saturday, April 30, 2016 at 6:16:20 PM UTC-4, Andrew Tomazos wrote:
>> On Fri, Apr 29, 2016 at 8:01 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>> On Friday, April 29, 2016 at 1:16:01 PM UTC-4, Andrew Tomazos wrote:
>>>> On Fri, Apr 29, 2016 at 6:01 PM, Nicol Bolas <jmck...@gmail.com> wrote=
:
>>>>> On Thursday, April 28, 2016 at 5:39:09 PM UTC-4, Arthur O'Dwyer wrote=
:
>>>>>>
>>>>>> What happens on a Windows platform when I write
>>>>>>
>>>>>>     const char data[] =3D R"(
>>>>>>     )";
>>>>>>
>>>>>> ? Does data come out equivalent to "\n" or to "\r\n"? Does it depend
>>>>>> on the compiler (MSVC versus Clang) or not? I don't have a Windows
machine
>>>>>> to find out for myself, sorry.
>>>>>
>>>>> According to the standard:
>>>>>
>>>>> >  A source-file new-line in a raw string literal results in a
new-line
>>>>> > in the resulting execution string-literal.
>>>>>
>>>>> So it would be a `\n`, not a `\r\n`.
>>>>>
>>>>> Granted, the above quote is not in normative text (presumably because
>>>>> section 2.14.3 makes it more clear). But clearly that is the intent
of the
>>>>> specification. [...]
>>>>
>>>> Not so fast:
>>>>
>>>> "Physical source file characters are mapped, in an
>>>> implementation-defined manner, to the basic source character set
>>>> (introducing new-line characters for end-of-line indicators) if
necessary.
>>>> The set of physical source file characters accepted is
>>>> implementation-defined."
>>>>
>>>> This mapping is commonly known as the "source encoding".  As a part of
>>>> the souce file, the content of raw string literals are input,
likewise, in
>>>> source encoding.

That doesn't contradict what Nicol said. In fact, I'm pretty sure that you
two (Andrew, Nicol) are in violent agreement on the points that matter. But
regardless, I'm pretty sure that Nicol is right. :)

> It doesn't matter how it's encoded in the original physical source file.
So
> long as the line endings in the physical source file are converted to
proper
> C++ newline characters, everything works fine.

Right.

> Consider what would happen if you perform #include on a file that consist=
s
> solely of a raw string literal. Textual file inclusion should be the
> equivalent of that: it does whatever #include would do, if the bytes of
text
> file being included had been wrapped in a raw string (of the appropriate
> encoding).

This is the part that requires a separate "raw/binary" mode for the
inclusion of data files.
Suppose I'm on a Windows platform.
If I use the proposed new "file string literal" construct to include a file
"foo.bin" whose physical contents are (hex)

    89 50 4E 47 0D 0A 1A 0A ...

[ http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html ]
then I definitely do *not* want that "end-of-line indicator" (0D 0A)
converted into a new-line character (0A) by any phase of translation. It is
absolutely critical that

    const char mypng[] =3D RF"foo.bin";

produce exactly the same program as

    const char mypng[] =3D { 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A=
,
.... };

.. Whereas, if the file contains

    68 69 0D 0A 62 79 65 0D 0A ...

then it is absolutely critical that

    const char mymsg[] =3D F"foo.bin";

produce exactly the same program as

    const char mymsg[] =3D { 0x68, 0x69, '\n', 0x62, 0x79, 0x65, '\n', ... =
};

Notice that I used my suggestion of "R" in the first case to mean "take the
physical bytes", and left off the "R" in the second case to mean "take the
file as if it were textually included as source code going through the
various phases of translation".

Notice that in that last sentence I used the cumbersome phrase "as source
code..." instead of just saying "encoded in the source character set."
That's because the source character encoding isn't the only thing that's
relevant here. The format of the end-of-line indicator is not determined by
the source character encoding.


>> In Table 7 it says '\n' maps to NL(LF) and that '\r' maps to CR [...]
>> I assume NL(LF) is the new line character that is a member of the basic
>> source character set, and that CR is the carriage return that is a
member of
>> the basic execution character set.

No; the four characters '\n' in the source correspond at runtime to the
character value of NL in the *execution* character set.
You're correct that the four characters '\r' in the source correspond at
runtime to the character value of CR in the *execution* character set.
By runtime, no vestiges of the source character encoding remain. by
definition, the character encoding that matters at *execution* time is the
*execution* character encoding. (The standard often abuses the term
"character set" to mean "character encoding"; this is unimportant.)

Generally speaking, barring weirdnesses like Green Hills' "euc2jis" mode,
the source and execution character sets are identical, and the source and
execution character encodings are also identical. However, at the source
level we also have the concept of "end-of-line indicator", which doesn't
correspond to anything at execution time. On Windows the end-of-line
indicator is the pair of characters 0D 0A (that is to say, CR NL). The
standard is clear (per Nicol's explanation) that if the end-of-line
indicator 0D 0A occurs inside a raw string literal in the source code, it
must be translated to a new-line character (that is to say, NL; that is to
say, 0A).

If you were on Windows, cross-compiling for an old Mac where the new-line
character (in the execution character encoding) was 0D, then the standard
would require that

assert(strcmp("\n", "\x0d") =3D=3D 0);  // axiom: NL in the execution chara=
cter
set is 0D
const char data[] =3D R"(
)";
assert(strcmp(data, "\n") =3D=3D 0);  // because the end-of-line indicator =
on
line 2 was converted to NL
assert(strcmp(data, "\x0d") =3D=3D 0);  // Q.E.D.

If you were on Windows, compiling for Windows where the new-line character
(in the execution character encoding) was 0A, then the standard would
require that

assert(strcmp("\n", "\x0a") =3D=3D 0);  // axiom: NL in the execution chara=
cter
set is 0A
const char data[] =3D R"(
)";
assert(strcmp(data, "\n") =3D=3D 0);  // because the end-of-line indicator =
on
line 2 was converted to NL
assert(strcmp(data, "\x0a") =3D=3D 0);  // Q.E.D.


I'm pretty sure I've got all that right. Anyone disagree?

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Sat, Apr 30, 2016 at 6:47 PM, Nicol Bolas &lt;<a href=
=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br>&gt; =
On Saturday, April 30, 2016 at 6:16:20 PM UTC-4, Andrew Tomazos wrote:<br>&=
gt;&gt; On Fri, Apr 29, 2016 at 8:01 PM, Nicol Bolas &lt;<a href=3D"mailto:=
jmck...@gmail.com">jmck...@gmail.com</a>&gt; wrote:<br>&gt;&gt;&gt; On Frid=
ay, April 29, 2016 at 1:16:01 PM UTC-4, Andrew Tomazos wrote:<br>&gt;&gt;&g=
t;&gt; On Fri, Apr 29, 2016 at 6:01 PM, Nicol Bolas &lt;<a href=3D"mailto:j=
mck...@gmail.com">jmck...@gmail.com</a>&gt; wrote:<br>&gt;&gt;&gt;&gt;&gt; =
On Thursday, April 28, 2016 at 5:39:09 PM UTC-4, Arthur O&#39;Dwyer wrote:<=
br>&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt; What happens on a W=
indows platform when I write<br>&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt=
;&gt;&gt; =C2=A0 =C2=A0 const char data[] =3D R&quot;(<br>&gt;&gt;&gt;&gt;&=
gt;&gt; =C2=A0 =C2=A0 )&quot;;<br>&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&=
gt;&gt;&gt; ? Does data come out equivalent to &quot;\n&quot; or to &quot;\=
r\n&quot;? Does it depend<br>&gt;&gt;&gt;&gt;&gt;&gt; on the compiler (MSVC=
 versus Clang) or not? I don&#39;t have a Windows machine<br>&gt;&gt;&gt;&g=
t;&gt;&gt; to find out for myself, sorry.<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&g=
t;&gt;&gt;&gt; According to the standard:<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&g=
t;&gt;&gt;&gt; &gt; =C2=A0A source-file new-line in a raw string literal re=
sults in a new-line<br>&gt;&gt;&gt;&gt;&gt; &gt; in the resulting execution=
 string-literal.<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; So it woul=
d be a `\n`, not a `\r\n`.<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; =
Granted, the above quote is not in normative text (presumably because<br>&g=
t;&gt;&gt;&gt;&gt; section 2.14.3 makes it more clear). But clearly that is=
 the intent of the<br>&gt;&gt;&gt;&gt;&gt; specification. [...]<br>&gt;&gt;=
&gt;&gt;<br>&gt;&gt;&gt;&gt; Not so fast:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&g=
t;&gt; &quot;Physical source file characters are mapped, in an<br>&gt;&gt;&=
gt;&gt; implementation-defined manner, to the basic source character set<br=
>&gt;&gt;&gt;&gt; (introducing new-line characters for end-of-line indicato=
rs) if necessary.<br>&gt;&gt;&gt;&gt; The set of physical source file chara=
cters accepted is<br>&gt;&gt;&gt;&gt; implementation-defined.&quot;<br>&gt;=
&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; This mapping is commonly known as the &quo=
t;source encoding&quot;.=C2=A0 As a part of<br>&gt;&gt;&gt;&gt; the souce f=
ile, the content of raw string literals are input, likewise, in<br>&gt;&gt;=
&gt;&gt; source encoding.<br><br>That doesn&#39;t contradict what Nicol sai=
d. In fact, I&#39;m pretty sure that you two (Andrew, Nicol) are in violent=
 agreement on the points that matter. But regardless, I&#39;m pretty sure t=
hat Nicol is right. :)<br><br>&gt; It doesn&#39;t matter how it&#39;s encod=
ed in the original physical source file. So<br>&gt; long as the line ending=
s in the physical source file are converted to proper<br>&gt; C++ newline c=
haracters, everything works fine.<br><br>Right.<br><br>&gt; Consider what w=
ould happen if you perform #include on a file that consists<br>&gt; solely =
of a raw string literal. Textual file inclusion should be the<br>&gt; equiv=
alent of that: it does whatever #include would do, if the bytes of text<br>=
&gt; file being included had been wrapped in a raw string (of the appropria=
te<br>&gt; encoding).<br><br>This is the part that requires a separate &quo=
t;raw/binary&quot; mode for the inclusion of data files.<div>Suppose I&#39;=
m on a Windows platform.</div><div>If I use the proposed new &quot;file str=
ing literal&quot; construct to include a file &quot;foo.bin&quot; whose phy=
sical contents are (hex)<br><br>=C2=A0 =C2=A0 89 50 4E 47 0D 0A 1A 0A ...<b=
r><br>[ <a href=3D"http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.htm=
l">http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html</a> ]<br>then =
I definitely do <i><b>not</b></i> want that &quot;end-of-line indicator&quo=
t; (0D 0A) converted into a new-line character (0A) by any phase of transla=
tion. It is absolutely critical that<div><br></div><div>=C2=A0 =C2=A0 const=
 char mypng[] =3D RF&quot;foo.bin&quot;;</div><div><br></div><div>produce e=
xactly the same program as</div><div><br><div>=C2=A0 =C2=A0 const char mypn=
g[] =3D { 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A, ... };</div><div>=
<br></div><div>. Whereas, if the file contains</div><div><br></div><div>=C2=
=A0 =C2=A0 68 69 0D 0A 62 79 65 0D 0A ...</div><div><br></div><div>then it =
is absolutely critical that</div><div><br></div><div>=C2=A0 =C2=A0 const ch=
ar mymsg[] =3D F&quot;foo.bin&quot;;</div><div><br></div><div>produce exact=
ly the same program as</div><div><br></div><div>=C2=A0 =C2=A0 const char my=
msg[] =3D { 0x68, 0x69, &#39;\n&#39;, 0x62, 0x79, 0x65, &#39;\n&#39;, ... }=
;</div><div><br></div><div>Notice that I used my suggestion of &quot;R&quot=
; in the first case to mean &quot;take the physical bytes&quot;, and left o=
ff the &quot;R&quot; in the second case to mean &quot;take the file as if i=
t were textually included as source code going through the various phases o=
f translation&quot;.</div><div><br></div><div>Notice that in that last sent=
ence I used the cumbersome phrase &quot;as source code...&quot; instead of =
just saying &quot;encoded in the source character set.&quot; That&#39;s bec=
ause the source character encoding isn&#39;t the only thing that&#39;s rele=
vant here. The format of the end-of-line indicator is not determined by the=
 source character encoding.</div><div><br></div><div><br></div>&gt;&gt; In =
Table 7 it says &#39;\n&#39; maps to NL(LF) and that &#39;\r&#39; maps to C=
R [...]<br>&gt;&gt; I assume NL(LF) is the new line character that is a mem=
ber of the basic<br>&gt;&gt; source character set, and that CR is the carri=
age return that is a member of<br>&gt;&gt; the basic execution character se=
t.</div><div><br></div><div>No; the four characters <font face=3D"monospace=
, monospace">&#39;\n&#39;</font> in the source correspond at runtime to the=
 character value of NL in the <i>execution</i> character set.</div><div>You=
&#39;re correct that the four characters <font face=3D"monospace, monospace=
">&#39;\r&#39;</font> in the source correspond at runtime to the character =
value of CR in the <i>execution</i> character set.</div><div>By runtime, no=
 vestiges of the source character encoding remain. by definition, the chara=
cter encoding that matters at <i>execution</i> time is the <i>execution</i>=
 character encoding. (The standard often abuses the term &quot;character se=
t&quot; to mean &quot;character encoding&quot;; this is unimportant.)</div>=
<div><br></div><div>Generally speaking, barring weirdnesses like Green Hill=
s&#39; &quot;euc2jis&quot; mode, the source and execution character sets ar=
e identical, and the source and execution character encodings are also iden=
tical. However, at the source level we also have the concept of &quot;end-o=
f-line indicator&quot;, which doesn&#39;t correspond to anything at executi=
on time. On Windows the end-of-line indicator is the pair of characters 0D =
0A (that is to say, CR NL). The standard is clear (per Nicol&#39;s explanat=
ion) that if the end-of-line indicator 0D 0A occurs inside a raw string lit=
eral in the source code, it must be translated to a new-line character (tha=
t is to say, NL; that is to say, 0A).</div><div><br></div><div>If you were =
on Windows, cross-compiling for an old Mac where the new-line character (in=
 the execution character encoding) was 0D, then the standard would require =
that</div><div><br></div><div>assert(strcmp(&quot;\n&quot;, &quot;\x0d&quot=
;) =3D=3D 0); =C2=A0// axiom: NL in the execution character set is 0D</div>=
<div>const char data[] =3D R&quot;(</div><div>)&quot;;</div><div>assert(str=
cmp(data, &quot;\n&quot;) =3D=3D 0); =C2=A0// because the end-of-line indic=
ator on line 2 was converted to NL</div><div><div><div>assert(strcmp(data, =
&quot;\x0d&quot;) =3D=3D 0); =C2=A0// Q.E.D.</div><div></div></div></div><d=
iv><br></div><div>If you were on Windows, compiling for Windows where the n=
ew-line character (in the execution character encoding) was 0A, then the st=
andard would require that</div><div><br></div><div><div>assert(strcmp(&quot=
;\n&quot;, &quot;\x0a&quot;) =3D=3D 0); =C2=A0// axiom: NL in the execution=
 character set is 0A</div><div>const char data[] =3D R&quot;(</div><div>)&q=
uot;;</div><div>assert(strcmp(data, &quot;\n&quot;) =3D=3D 0); =C2=A0// bec=
ause the end-of-line indicator on line 2 was converted to NL</div><div><div=
>assert(strcmp(data, &quot;\x0a&quot;) =3D=3D 0); =C2=A0// Q.E.D.</div><div=
></div></div></div><div><br></div><div><br></div><div>I&#39;m pretty sure I=
&#39;ve got all that right. Anyone disagree?</div></div><div><br></div><div=
>=E2=80=93Arthur</div><div><br></div></div>

<p></p>

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

--94eb2c0934b6f5e5f10531c12ea0--

.

On 2016-04-28 17:39, Arthur O'Dwyer wrote:
> Either way, your proposal should include an example along the lines of
>=20
>     const char example[] =3D RF"foo(bar.h)foo";
>=20
> Does this mean "include bar.h", or "include foo(bar.h)foo" =E2=80=94 and =
why?

Certainly the latter; anything else is just overly complicating things
to no benefit.

If you really need a string like "foo" + contents of 'bar.h' + "foo",
use concatenation:

  auto example[] =3D R"foo" RF"bar.h" R"foo";

> I think your proposal should include an example=20
> along the lines of
>=20
>     #define X(x) F ## #x
>     #include X(foo) ".h"
>     const char example[] =3D X(foo) ".h";
>=20
> I think the behavior of the above #include is implementation-defined or=
=20
> possibly undefined; I haven't checked.
> I'm curious whether you'd make the behavior of the above "example"=20
> equivalent to
>=20
>     const char example[] =3D F"foo" /*followed by the two characters*/ ".=
h";
>=20
> or
>=20
>     const char example[] =3D F"foo.h";
>=20
> or ill-formed / implementation-defined / undefined [...] or even "I=20
> don't care =E2=80=94 let the committee sort it out".

Does string literal concatenation even occur during the PP phase? Some
crude experiments with GCC=C2=B9 suggest otherwise, which makes this a moot
point (read: the first result is obviously and necessarily "correct").

To get the second, you would probably have to write something more like
(disclaimer: not tested):

  #define S(s) #s
  #define X(x) F ## S(x.h)
  const char example[] =3D X(foo); // F"foo.h"

(=C2=B9 echo 'char const* c =3D "a" "b" "c";' | gcc -E -)

--=20
Matthew

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

.

------=_Part_906_618473169.1462308640910
Content-Type: multipart/alternative;
 boundary="----=_Part_907_648146077.1462308640910"

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

On Tuesday, May 3, 2016 at 11:49:31 AM UTC-4, Matthew Woehlke wrote:
>
> On 2016-04-28 17:39, Arthur O'Dwyer wrote:=20
> > Either way, your proposal should include an example along the lines of=
=20
> >=20
> >     const char example[] =3D RF"foo(bar.h)foo";=20
> >=20
> > Does this mean "include bar.h", or "include foo(bar.h)foo" =E2=80=94 an=
d why?=20
>
> Certainly the latter; anything else is just overly complicating things=20
> to no benefit.=20
>
> If you really need a string like "foo" + contents of 'bar.h' + "foo",=20
> use concatenation:=20
>

I believe that Arthur was comparing to current raw string literals:

const char example[] =3D R"foo(bar.h)foo";

results in example containing "bar.h".

Does adding the F after the R change the delimiter semantics?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/782c32c5-1441-41ca-87c4-6e65c82bc91c%40isocpp.or=
g.

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

<div dir=3D"ltr">On Tuesday, May 3, 2016 at 11:49:31 AM UTC-4, Matthew Woeh=
lke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-04-28 17:39,=
 Arthur O&#39;Dwyer wrote:
<br>&gt; Either way, your proposal should include an example along the line=
s of
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 const char example[] =3D RF&quot;foo(bar.h)foo&quot;=
;
<br>&gt;=20
<br>&gt; Does this mean &quot;include bar.h&quot;, or &quot;include foo(bar=
..h)foo&quot; =E2=80=94 and why?
<br>
<br>Certainly the latter; anything else is just overly complicating things
<br>to no benefit.
<br>
<br>If you really need a string like &quot;foo&quot; + contents of &#39;bar=
..h&#39; + &quot;foo&quot;,
<br>use concatenation:
<br></blockquote><div><br></div><div>I believe that Arthur was comparing to=
 current raw string literals:</div><div><br></div><div>const char example[]=
 =3D R&quot;foo(bar.h)foo&quot;;</div><div><br></div><div>results in exampl=
e containing &quot;bar.h&quot;.</div><div><br></div><div>Does adding the F =
after the R change the delimiter semantics?</div><div><br></div></div>

<p></p>

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

------=_Part_907_648146077.1462308640910--
------=_Part_906_618473169.1462308640910--

.

------=_Part_1626_300545314.1462322929808
Content-Type: multipart/alternative;
 boundary="----=_Part_1627_531540568.1462322929808"

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

On Tuesday, May 3, 2016 at 4:50:41 PM UTC-4, Greg Marr wrote:
>
> On Tuesday, May 3, 2016 at 11:49:31 AM UTC-4, Matthew Woehlke wrote:
>>
>> On 2016-04-28 17:39, Arthur O'Dwyer wrote:=20
>> > Either way, your proposal should include an example along the lines of=
=20
>> >=20
>> >     const char example[] =3D RF"foo(bar.h)foo";=20
>> >=20
>> > Does this mean "include bar.h", or "include foo(bar.h)foo" =E2=80=94 a=
nd why?=20
>>
>> Certainly the latter; anything else is just overly complicating things=
=20
>> to no benefit.=20
>>
>> If you really need a string like "foo" + contents of 'bar.h' + "foo",=20
>> use concatenation:=20
>>
>
> I believe that Arthur was comparing to current raw string literals:
>
> const char example[] =3D R"foo(bar.h)foo";
>
> results in example containing "bar.h".
>
> Does adding the F after the R change the delimiter semantics?
>

I thought the point was that `R` already had a meaning and therefore=20
shouldn't be used to mean "binary". There should be a syntax specifically=
=20
for reading files that should be interpreted as binary data.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7a66d5b6-bb99-4af9-b7be-69025302a7f9%40isocpp.or=
g.

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

<div dir=3D"ltr">On Tuesday, May 3, 2016 at 4:50:41 PM UTC-4, Greg Marr wro=
te:<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">On Tuesday=
, May 3, 2016 at 11:49:31 AM UTC-4, Matthew Woehlke wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">On 2016-04-28 17:39, Arthur O&#39;Dwyer wrote:
<br>&gt; Either way, your proposal should include an example along the line=
s of
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 const char example[] =3D RF&quot;foo(bar.h)foo&quot;=
;
<br>&gt;=20
<br>&gt; Does this mean &quot;include bar.h&quot;, or &quot;include foo(bar=
..h)foo&quot; =E2=80=94 and why?
<br>
<br>Certainly the latter; anything else is just overly complicating things
<br>to no benefit.
<br>
<br>If you really need a string like &quot;foo&quot; + contents of &#39;bar=
..h&#39; + &quot;foo&quot;,
<br>use concatenation:
<br></blockquote><div><br></div><div>I believe that Arthur was comparing to=
 current raw string literals:</div><div><br></div><div>const char example[]=
 =3D R&quot;foo(bar.h)foo&quot;;</div><div><br></div><div>results in exampl=
e containing &quot;bar.h&quot;.</div><div><br></div><div>Does adding the F =
after the R change the delimiter semantics?</div></div></blockquote><div><b=
r>I thought the point was that `R` already had a meaning and therefore shou=
ldn&#39;t be used to mean &quot;binary&quot;. There should be a syntax spec=
ifically for reading files that should be interpreted as binary data.<br></=
div></div>

<p></p>

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

------=_Part_1627_531540568.1462322929808--
------=_Part_1626_300545314.1462322929808--

.

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

On Tue, May 3, 2016 at 1:50 PM, Greg Marr <gregmmarr@gmail.com> wrote:

> On Tuesday, May 3, 2016 at 11:49:31 AM UTC-4, Matthew Woehlke wrote:
>>
>> On 2016-04-28 17:39, Arthur O'Dwyer wrote:
>> > Either way, your proposal should include an example along the lines of
>> >
>> >     const char example[] =3D RF"foo(bar.h)foo";
>> >
>> > Does this mean "include bar.h", or "include foo(bar.h)foo" =E2=80=94 a=
nd why?
>>
>> Certainly the latter; anything else is just overly complicating things
>> to no benefit.
>>
>> If you really need a string like "foo" + contents of 'bar.h' + "foo",
>> use concatenation:
>>
>
> I believe that Arthur was comparing to current raw string literals:
>
> const char example[] =3D R"foo(bar.h)foo";
>
> results in example containing "bar.h".
>
> Does adding the F after the R change the delimiter semantics?
>

Correct, that's what I was getting at.
And the fact that Matthew apparently interpreted the (non-)meaning of the
string as something like

    const char example[] =3D "foo" F"bar.h" "foo";

=E2=80=94 i.e. yet a third interpretation =E2=80=94 shows that there's room=
 for programmer
confusion here. This is why I think an example or two is important, and why
I think the exact syntax needs discussion and polishing, so that the final
result avoids as much programmer confusion as possible.

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Tue, May 3, 2016 at 1:50 PM, Greg Marr <span dir=3D"ltr=
">&lt;<a href=3D"mailto:gregmmarr@gmail.com" target=3D"_blank">gregmmarr@gm=
ail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"=
">On Tuesday, May 3, 2016 at 11:49:31 AM UTC-4, Matthew Woehlke wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">On 2016-04-28 17:39, Arthur O&#39;Dwyer =
wrote:
<br>&gt; Either way, your proposal should include an example along the line=
s of
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 const char example[] =3D RF&quot;foo(bar.h)foo&quot;=
;
<br>&gt;=20
<br>&gt; Does this mean &quot;include bar.h&quot;, or &quot;include foo(bar=
..h)foo&quot; =E2=80=94 and why?
<br>
<br>Certainly the latter; anything else is just overly complicating things
<br>to no benefit.
<br>
<br>If you really need a string like &quot;foo&quot; + contents of &#39;bar=
..h&#39; + &quot;foo&quot;,
<br>use concatenation:
<br></blockquote><div><br></div></span><div>I believe that Arthur was compa=
ring to current raw string literals:</div><div><br></div><div>const char ex=
ample[] =3D R&quot;foo(bar.h)foo&quot;;</div><div><br></div><div>results in=
 example containing &quot;bar.h&quot;.</div><div><br></div><div>Does adding=
 the F after the R change the delimiter semantics?</div></div></blockquote>=
<div><br></div><div>Correct, that&#39;s what I was getting at.</div><div>An=
d the fact that Matthew apparently interpreted the (non-)meaning of the str=
ing as something like</div><div><br></div><div>=C2=A0 =C2=A0 const char exa=
mple[] =3D &quot;foo&quot; F&quot;bar.h&quot; &quot;foo&quot;;</div><div><b=
r></div><div>=E2=80=94 i.e. yet a third interpretation =E2=80=94 shows that=
 there&#39;s room for programmer confusion here. This is why I think an exa=
mple or two is important, and why I think the exact syntax needs discussion=
 and polishing, so that the final result avoids as much programmer confusio=
n as possible.</div><div><br></div><div>=E2=80=93Arthur</div></div></div></=
div>

<p></p>

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

--001a1149299c911ef10531faa40c--

.

On 2016-05-03 16:50, Greg Marr wrote:
> On Tuesday, May 3, 2016 at 11:49:31 AM UTC-4, Matthew Woehlke wrote:
>> On 2016-04-28 17:39, Arthur O'Dwyer wrote:=20
>>> Either way, your proposal should include an example along the lines of=
=20
>>>
>>>     const char example[] =3D RF"foo(bar.h)foo";=20
>>>
>>> Does this mean "include bar.h", or "include foo(bar.h)foo" =E2=80=94 an=
d why?=20
>>
>> Certainly the latter; anything else is just overly complicating things=
=20
>> to no benefit.=20
>>
>> If you really need a string like "foo" + contents of 'bar.h' + "foo",=20
>> use concatenation:=20
>=20
> I believe that Arthur was comparing to current raw string literals:
>=20
> const char example[] =3D R"foo(bar.h)foo";
>=20
> results in example containing "bar.h".

Ah... yes, I interpret the original example as being the same as
`F"foo(bar.h)foo"`, with the `R` serving only to specify binary vs. text
include mode. (As Nicol notes, this may be a good reason to use
something other than `R` for that purpose. Maybe we should use `Ft` and
`Fb` instead, with `F` by itself being a synonym for `Ft`?)

I doubt esoteric file names are going to be so common as to justify a
mechanism for naming them other than whatever can be used in e.g.
`#include <foo.h>`. Let's not overengineer the feature :-). If we
*really* need it, we could just specify that escapes are parsed within
the name; that's inconvenient but covers anything, and realistically I
doubt it will be needed much if at all.

(Can you #include a file name with e.g. a newline in its name? I've
never actually had occasion to need to find out...)

--=20
Matthew

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

.

------=_Part_4192_946158329.1462374532972
Content-Type: multipart/alternative;
 boundary="----=_Part_4193_1803068996.1462374532980"

------=_Part_4193_1803068996.1462374532980
Content-Type: text/plain; charset=UTF-8

On Wednesday, May 4, 2016 at 10:23:17 AM UTC-4, Matthew Woehlke wrote:
>
> Ah... yes, I interpret the original example as being the same as
> `F"foo(bar.h)foo"`, with the `R` serving only to specify binary vs. text
> include mode. (As Nicol notes, this may be a good reason to use
> something other than `R` for that purpose. Maybe we should use `Ft` and
> `Fb` instead, with `F` by itself being a synonym for `Ft`?)
>

We need more than just `t` and `b` here. We need to be able to use the full
range of encodings that C++ provides for string literals: narrow, wide,
UTF-8, UTF-16, and UTF-32.

So `u8F` would mean that the file is encoded in UTF-8, so the generated
literal should match. I would prefer to avoid `Fu8`, because that makes
`Fu8"filename.txt"` seem like the `u8` applies to the filename literal
rather than the generated one.

We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), `uF` (UTF-16),
`UF` (UTF-32), and `bF` (no translation).

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

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

<div dir=3D"ltr">On Wednesday, May 4, 2016 at 10:23:17 AM UTC-4, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Ah... yes, I inter=
pret the original example as being the same as
<br>`F&quot;foo(bar.h)foo&quot;`, with the `R` serving only to specify bina=
ry vs. text
<br>include mode. (As Nicol notes, this may be a good reason to use
<br>something other than `R` for that purpose. Maybe we should use `Ft` and
<br>`Fb` instead, with `F` by itself being a synonym for `Ft`?)<br></blockq=
uote><div><br>We need more than just `t` and `b` here. We need to be able t=
o use the full range of encodings that C++ provides for string literals: na=
rrow, wide, UTF-8, UTF-16, and UTF-32.<br><br>So `u8F` would mean that the =
file is encoded in UTF-8, so the generated literal should match. I would pr=
efer to avoid `Fu8`, because that makes `Fu8&quot;filename.txt&quot;` seem =
like the `u8` applies to the filename literal rather than the generated one=
..<br><br>We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), `uF` (U=
TF-16), `UF` (UTF-32), and `bF` (no translation).<br></div></div>

<p></p>

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

------=_Part_4193_1803068996.1462374532980--
------=_Part_4192_946158329.1462374532972--

.

------=_Part_4143_1061668422.1462375359730
Content-Type: multipart/alternative;
 boundary="----=_Part_4144_572401418.1462375359731"

------=_Part_4144_572401418.1462375359731
Content-Type: text/plain; charset=UTF-8

On Wednesday, May 4, 2016 at 11:08:53 AM UTC-4, Nicol Bolas wrote:
>
> On Wednesday, May 4, 2016 at 10:23:17 AM UTC-4, Matthew Woehlke wrote:
>>
>> Ah... yes, I interpret the original example as being the same as
>> `F"foo(bar.h)foo"`, with the `R` serving only to specify binary vs. text
>> include mode. (As Nicol notes, this may be a good reason to use
>> something other than `R` for that purpose. Maybe we should use `Ft` and
>> `Fb` instead, with `F` by itself being a synonym for `Ft`?)
>>
>
> We need more than just `t` and `b` here. We need to be able to use the
> full range of encodings that C++ provides for string literals: narrow,
> wide, UTF-8, UTF-16, and UTF-32.
>
> So `u8F` would mean that the file is encoded in UTF-8, so the generated
> literal should match. I would prefer to avoid `Fu8`, because that makes
> `Fu8"filename.txt"` seem like the `u8` applies to the filename literal
> rather than the generated one.
>
> We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), `uF` (UTF-16),
> `UF` (UTF-32), and `bF` (no translation).
>

Actually, something just occurred to me about `bF`. Namely, NUL termination.

All of the genuine string literals should be NUL terminated, since that's
how we expect literals to behave. But `bF` shouldn't be NUL terminated.
So... what do we do?

A string literal is always considered an array in C++, so sizing
information is there. But people are very used to *discarding* sizing
information. How many times have you seen the equivalent of this:

const char *str = "SomeLiteral";

We do this all the time. Now, to be fair to us, this is in part because of
a long-time lack of `string_view` and an appropriate literal: `auto str =
"SomeLiteral"sv;`.

But my point is that people frequently discard sizing information of string
literals. Because of NUL termination, that's generally OK, if slow. NUL
characters in strings are quite rare, thanks to long-standing practice of
using NUL characters as terminators.

NUL characters in binary files however are very common. So using `strlen`
to recompute the lost length is not workable.

Given that we're adding something new to the language anyway (the encoding
formats I used above could simply be a new case for `string-literal`, using
`encoding-prefix<opt>`, with the exception of `b`), maybe we could also add
some language that will prevent this. Perhaps a `bF` string literal is a
special "binary literal" that can have some different rules. It could have
the type `const unsigned char[X]`, but we could add language so that the
literal itself would not decay into a pointer. You could still do this:

const unsigned char var[] = bF"Filename.bin";
const unsigned char* pVar = var;

But you couldn't do this directly:

const unsigned char* pVar = bF"Filename.bin";

I do feel that we should make `bF` return an array of `unsigned char`'s
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/485639dd-7ee3-4dda-95e4-f52adab127e9%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, May 4, 2016 at 11:08:53 AM UTC-4, Nicol Bola=
s wrote:<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">On We=
dnesday, May 4, 2016 at 10:23:17 AM UTC-4, Matthew Woehlke wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex">Ah... yes, I interpret the original example a=
s being the same as
<br>`F&quot;foo(bar.h)foo&quot;`, with the `R` serving only to specify bina=
ry vs. text
<br>include mode. (As Nicol notes, this may be a good reason to use
<br>something other than `R` for that purpose. Maybe we should use `Ft` and
<br>`Fb` instead, with `F` by itself being a synonym for `Ft`?)<br></blockq=
uote><div><br>We need more than just `t` and `b` here. We need to be able t=
o use the full range of encodings that C++ provides for string literals: na=
rrow, wide, UTF-8, UTF-16, and UTF-32.<br><br>So `u8F` would mean that the =
file is encoded in UTF-8, so the generated literal should match. I would pr=
efer to avoid `Fu8`, because that makes `Fu8&quot;filename.txt&quot;` seem =
like the `u8` applies to the filename literal rather than the generated one=
..<br><br>We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), `uF` (U=
TF-16), `UF` (UTF-32), and `bF` (no translation).<br></div></div></blockquo=
te><div><br>Actually, something just occurred to me about `bF`. Namely, NUL=
 termination.<br><br>All of the genuine string literals should be NUL termi=
nated, since that&#39;s how we expect literals to behave. But `bF` shouldn&=
#39;t be NUL terminated. So... what do we do?<br><br>A string literal is al=
ways considered an array in C++, so sizing information is there. But people=
 are very used to <i>discarding</i> sizing information. How many times have=
 you seen the equivalent of this:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">str </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">&quot;SomeLiteral&quot;</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span></div><=
/code></div><br>We do this all the time. Now, to be fair to us, this is in =
part because of a long-time lack of `string_view` and an appropriate litera=
l: `auto str =3D &quot;SomeLiteral&quot;sv;`.<br><br>But my point is that p=
eople frequently discard sizing information of string literals. Because of =
NUL termination, that&#39;s generally OK, if slow. NUL characters in string=
s are quite rare, thanks to long-standing practice of using NUL characters =
as terminators.<br><br>NUL characters in binary files however are very comm=
on. So using `strlen` to recompute the lost length is not workable.<br><br>=
Given that we&#39;re adding something new to the language anyway (the encod=
ing formats I used above could simply be a new case for `string-literal`, u=
sing `encoding-prefix&lt;opt&gt;`, with the exception of `b`), maybe we cou=
ld also add some language that will prevent this. Perhaps a `bF` string lit=
eral is a special &quot;binary literal&quot; that can have some different r=
ules. It could have the type `const unsigned char[X]`, but we could add lan=
guage so that the literal itself would not decay into a pointer. You could =
still do this:<br><br><div class=3D"prettyprint" style=3D"background-color:=
 rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid;=
 border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-=
prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">unsi=
gned</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">char</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">var</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">[]</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> bF</span><span style=3D"color: #080;" class=3D"styled-by-=
prettify">&quot;Filename.bin&quot;</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">unsig=
ned</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> pVar </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">var</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span></div></code></div><br>But you couldn&#39;t do thi=
s directly:<br><br><div class=3D"prettyprint" style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">unsigne=
d</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> pVar </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> bF</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">&quot;Filename.bin&quot;</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span></div></code></div><br>I do f=
eel that we should make `bF` return an array of `unsigned char`&#39;s thoug=
h.<br></div></div>

<p></p>

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

------=_Part_4144_572401418.1462375359731--
------=_Part_4143_1061668422.1462375359730--

.

On 2016-05-04 11:22, Nicol Bolas wrote:
> Actually, something just occurred to me about `bF`. Namely, NUL terminati=
on.
>=20
> All of the genuine string literals should be NUL terminated, since that's=
=20
> how we expect literals to behave. But `bF` shouldn't be NUL terminated.=
=20
> So... what do we do?

I'm not sure that's genuinely a problem=C2=B9. Many file formats, even
binary, are likely tolerant of a "stray" NUL at the end, and even if
not, I can't think how you would use such a string without specifying
the length, in which case it would be trivial to subtract 1.

(=C2=B9 Didn't we have this conversation already? It seems familiar...)

> A string literal is always considered an array in C++, so sizing=20
> information is there. But people are very used to *discarding* sizing=20
> information. How many times have you seen the equivalent of this:
>=20
> const char *str =3D "SomeLiteral";

Well, it's fine (if inefficient) for text.

> Given that we're adding something new to the language anyway (the encodin=
g=20
> formats I used above could simply be a new case for `string-literal`, usi=
ng=20
> `encoding-prefix<opt>`, with the exception of `b`), maybe we could also a=
dd=20
> some language that will prevent this. Perhaps a `bF` string literal is a
> special "binary literal" that can have some different rules. It could hav=
e=20
> the type `const unsigned char[X]`, but we could add language so that the=
=20
> literal itself would not decay into a pointer. You could still do this:
>=20
> const unsigned char var[] =3D bF"Filename.bin";
> const unsigned char* pVar =3D var;
>=20
> But you couldn't do this directly:
>=20
> const unsigned char* pVar =3D bF"Filename.bin";

Compilers should almost definitely *warn* about that. I'm less convinced
it needs to be forbidden in the standard.

--=20
Matthew

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

.

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

On Wed, May 4, 2016 at 8:08 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, May 4, 2016 at 10:23:17 AM UTC-4, Matthew Woehlke wrote:
>>
>> Ah... yes, I interpret the original example as being the same as
>> `F"foo(bar.h)foo"`, with the `R` serving only to specify binary vs. text
>> include mode. (As Nicol notes, this may be a good reason to use
>> something other than `R` for that purpose. Maybe we should use `Ft` and
>> `Fb` instead, with `F` by itself being a synonym for `Ft`?)
>>
>
> We need more than just `t` and `b` here. We need to be able to use the
> full range of encodings that C++ provides for string literals: narrow,
> wide, UTF-8, UTF-16, and UTF-32.
>
> So `u8F` would mean that the file is encoded in UTF-8, so the generated
> literal should match. I would prefer to avoid `Fu8`, because that makes
> `Fu8"filename.txt"` seem like the `u8` applies to the filename literal
> rather than the generated one.
>
> We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), `uF` (UTF-16),
> `UF` (UTF-32), and `bF` (no translation).
>

Incorrect (for once ;)).
The prefixes u8, u, U and the suffix L don't apply to the encoding of the
*source code*. They apply to the encoding of the *runtime data*.
For example:

    const char d1[] =3D "abc";
    const char d2[] =3D u8"abc";
    assert(d1[0] =3D=3D 'a');  // but not necessarily 0x61
    assert(d2[0] =3D=3D 0x61);  // but not necessarily =3D=3D 'a'

This source file can be encoded in ASCII or EBCDIC or otherwise, and
compiled for a target platform that uses ASCII or EBCDIC or otherwise; no
matter which of those 3x3 =3D 9 possibilities you pick, both asserts are
guaranteed by the Standard to pass.

The source construct that looks like "a" (no matter what source-encoded
bytes represent those three glyphs) is guaranteed to correspond at runtime
to the bytes of data that represent the letter "a" in the runtime character
encoding.
The source construct that looks like u8"a" (no matter what source-encoded
bytes represent those five glyphs) is guaranteed to correspond at runtime
to the bytes of data that represent the letter "a" in UTF-8, *regardless*
of the runtime character encoding.

Therefore, leaving aside the issue of binary (raw) data and
null-termination for a moment, the following constructs are unambiguous, if
let's say "foo.txt" contains the text "foo" in source encoding:

    const char a[] =3D F"foo.txt";  assert(strcmp(a, "foo") =3D=3D 0);
    const wchar_t b[] =3D F"foo.txt"L;  assert(wcscmp(b, "foo"L) =3D=3D 0);
    const char c[] =3D u8F"foo.txt";  assert(memcmp(c, u8"foo", 4) =3D=3D 0=
);
    const char16_t d[] =3D uF"foo.txt";  assert(memcmp(d, u"foo", 8) =3D=3D=
 0);
    const char32_t e[] =3D UF"foo.txt";  assert(memcmp(e, U"foo", 16) =3D=
=3D 0);

Andrew's proposal handles all of these cases perfectly.

The problems arise only when you don't want F"foo.txt" to behave like *any*
variety of string literal =E2=80=94 i.e., you don't want the compiler to ru=
n the
data through the "decode source encoding into glyphs" pass.
Suppose I want to achieve the effect of

    const char single_byte_weights[] =3D { 134, 150, 150 };  // toy example=
;
this array might be hundreds of elements long

So I write

    const char single_byte_weights[] =3D F"weights.bin";

where weights.bin is a 3-byte file containing the bytes 134, 150, 150 (that
is, 0x86 0x96 0x96).
Now, I happen to be on an EBCDIC system, where

    const char f[] =3D "foo";
    assert(memcmp(f, "\x86\x96\x96", 4) =3D=3D 0);

I compile my code on my EBCDIC platform, and it works fine.
Then I port my code to an ASCII platform. Obviously I don't do any kind of
translation on my weights.bin file; that's raw data and I don't want those
byte values to change. I compile my code on the ASCII platform:

    const char single_byte_weights[] =3D F"weights.bin";

and the compiler blows up! It's complaining that the byte 0x86 in
"weights.bin" doesn't correspond to any ASCII character, so it's not legal
to appear in (what's tantamount to) a string literal in my C++ source code.


Or suppose I'm on a Unix platform and I want the effect of

    const char single_byte_weights[] =3D { 13, 10 };

I compile

    const char single_byte_weights[] =3D F"weights.bin";

where weights.bin is a 2-byte file containing the bytes 13, 10.
It works fine on Unix.
Then I port my code to Windows. Obviously I don't do any kind of
translation on my weights.bin file; that's raw data and I don't want those
byte values to change. I compile my code on the Windows platform...
and the compiler happily accepts it...
but at runtime I notice that my weights are all wrong! The debugger tells
me that my code has mysteriously changed to the equivalent of

    const char single_byte_weights[] =3D { 10 };

These are the kinds of problems that a "raw" or "binary" file-input mode
would solve =E2=80=94 they're problems related to source encoding. Problems=
 related
to the runtime encoding of glyphs into bytes are already thoroughly solved
by the existing prefix/suffix system, which composes fine with the F-prefix=
..

HTH,
=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Wed, May 4, 2016 at 8:08 AM, Nicol Bolas <span dir=3D"l=
tr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@=
gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><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"><div dir=3D"ltr"><span class=3D"">On Wednesd=
ay, May 4, 2016 at 10:23:17 AM UTC-4, Matthew Woehlke wrote:<blockquote cla=
ss=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=
">Ah... yes, I interpret the original example as being the same as
<br>`F&quot;foo(bar.h)foo&quot;`, with the `R` serving only to specify bina=
ry vs. text
<br>include mode. (As Nicol notes, this may be a good reason to use
<br>something other than `R` for that purpose. Maybe we should use `Ft` and
<br>`Fb` instead, with `F` by itself being a synonym for `Ft`?)<br></blockq=
uote></span><div><br>We need more than just `t` and `b` here. We need to be=
 able to use the full range of encodings that C++ provides for string liter=
als: narrow, wide, UTF-8, UTF-16, and UTF-32.<br><br>So `u8F` would mean th=
at the file is encoded in UTF-8, so the generated literal should match. I w=
ould prefer to avoid `Fu8`, because that makes `Fu8&quot;filename.txt&quot;=
` seem like the `u8` applies to the filename literal rather than the genera=
ted one.<br><br>We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), =
`uF` (UTF-16), `UF` (UTF-32), and `bF` (no translation).<br></div></div></b=
lockquote><div><br></div><div>Incorrect (for once ;)).</div><div>The prefix=
es u8, u, U and the suffix L don&#39;t apply to the encoding of the *source=
 code*. They apply to the encoding of the *runtime data*.</div><div>For exa=
mple:</div><div><br></div><div>=C2=A0 =C2=A0 const char d1[] =3D &quot;abc&=
quot;;</div><div>=C2=A0 =C2=A0 const char d2[] =3D u8&quot;abc&quot;;</div>=
<div>=C2=A0 =C2=A0 assert(d1[0] =3D=3D &#39;a&#39;); =C2=A0// but not neces=
sarily 0x61</div><div>=C2=A0 =C2=A0 assert(d2[0] =3D=3D 0x61); =C2=A0// but=
 not necessarily =3D=3D &#39;a&#39;</div><div><br></div><div>This source fi=
le can be encoded in ASCII or EBCDIC or otherwise, and compiled for a targe=
t platform that uses ASCII or EBCDIC or otherwise; no matter which of those=
 3x3 =3D 9 possibilities you pick, both asserts are guaranteed by the Stand=
ard to pass.</div><div><br></div><div>The source construct that looks like =
<font face=3D"monospace, monospace">&quot;a&quot;</font> (no matter what so=
urce-encoded bytes represent those three glyphs) is guaranteed to correspon=
d at runtime to the bytes of data that represent the letter &quot;a&quot; i=
n the runtime character encoding.</div><div><div>The source construct that =
looks like <font face=3D"monospace, monospace">u8&quot;a&quot;</font> (no m=
atter what source-encoded bytes represent those five glyphs) is guaranteed =
to correspond at runtime to the bytes of data that represent the letter &qu=
ot;a&quot; in UTF-8, <i>regardless</i> of the runtime character encoding.</=
div></div><div><br></div><div>Therefore, leaving aside the issue of binary =
(raw) data and null-termination for a moment, the following constructs are =
unambiguous, if let&#39;s say &quot;foo.txt&quot; contains the text &quot;f=
oo&quot; in source encoding:</div><div><br></div><div>=C2=A0 =C2=A0 const c=
har a[] =3D F&quot;foo.txt&quot;; =C2=A0assert(strcmp(a, &quot;foo&quot;) =
=3D=3D 0);</div><div><div>=C2=A0 =C2=A0 const wchar_t b[] =3D F&quot;foo.tx=
t&quot;L; =C2=A0assert(wcscmp(b, &quot;foo&quot;L) =3D=3D 0);</div></div><d=
iv><div>=C2=A0 =C2=A0 const char c[] =3D u8F&quot;foo.txt&quot;; =C2=A0asse=
rt(memcmp(c, u8&quot;foo&quot;, 4) =3D=3D 0);</div></div><div><div><div>=C2=
=A0 =C2=A0 const char16_t d[] =3D uF&quot;foo.txt&quot;; =C2=A0assert(memcm=
p(d, u&quot;foo&quot;, 8) =3D=3D 0);</div></div></div><div><div>=C2=A0 =C2=
=A0 const char32_t e[] =3D UF&quot;foo.txt&quot;; =C2=A0assert(memcmp(e, U&=
quot;foo&quot;, 16) =3D=3D 0);</div></div><div><br></div><div>Andrew&#39;s =
proposal handles all of these cases perfectly.</div><div><br></div><div>The=
 problems arise only when you don&#39;t want F&quot;foo.txt&quot; to behave=
 like <i>any</i> variety of string literal =E2=80=94 i.e., you don&#39;t wa=
nt the compiler to run the data through the &quot;decode source encoding in=
to glyphs&quot; pass.</div><div>Suppose I want to achieve the effect of<br>=
</div><div><br></div><div><div>=C2=A0 =C2=A0 const char single_byte_weights=
[] =3D { 134, 150, 150 }; =C2=A0// toy example; this array might be hundred=
s of elements long</div><div><br></div></div><div>So I write</div><div><br>=
</div><div>=C2=A0 =C2=A0 const char single_byte_weights[] =3D F&quot;weight=
s.bin&quot;;</div><div><br></div><div>where weights.bin is a 3-byte file co=
ntaining the bytes 134, 150, 150 (that is, 0x86 0x96 0x96).</div><div><div>=
Now, I happen to be on an EBCDIC system, where</div><div><br></div><div>=C2=
=A0 =C2=A0 const char f[] =3D &quot;foo&quot;;</div><div>=C2=A0 =C2=A0 asse=
rt(memcmp(f, &quot;\x86\x96\x96&quot;, 4) =3D=3D 0);</div><div><br></div></=
div><div>I compile my code on my EBCDIC platform, and it works fine.</div><=
div>Then I port my code to an ASCII platform. Obviously I don&#39;t do any =
kind of translation on my weights.bin file; that&#39;s raw data and I don&#=
39;t want those byte values to change. I compile my code on the ASCII platf=
orm:</div><div><br></div><div><div>=C2=A0 =C2=A0 const char single_byte_wei=
ghts[] =3D F&quot;weights.bin&quot;;</div></div><div><br></div><div>and the=
 compiler blows up! It&#39;s complaining that the byte 0x86 in &quot;weight=
s.bin&quot; doesn&#39;t correspond to any ASCII character, so it&#39;s not =
legal to appear in (what&#39;s tantamount to) a string literal in my C++ so=
urce code.</div><div><br></div><div><br></div><div>Or suppose I&#39;m on a =
Unix platform and I want the effect of</div><div><br></div><div><div>=C2=A0=
 =C2=A0 const char single_byte_weights[] =3D { 13, 10 };</div></div><div><b=
r></div><div>I compile</div><div><br></div><div><div>=C2=A0 =C2=A0 const ch=
ar single_byte_weights[] =3D F&quot;weights.bin&quot;;</div><div><br></div>=
<div>where weights.bin is a 2-byte file containing the bytes 13, 10.</div><=
div>It works fine on Unix.</div><div>Then I port my code to Windows. Obviou=
sly I don&#39;t do any kind of translation on my weights.bin file; that&#39=
;s raw data and I don&#39;t want those byte values to change. I compile my =
code on the Windows platform...</div><div>and the compiler happily accepts =
it...</div><div>but at runtime I notice that my weights are all wrong! The =
debugger tells me that my code has mysteriously changed to the equivalent o=
f</div><div><br></div><div>=C2=A0 =C2=A0 const char single_byte_weights[] =
=3D { 10 };</div><div><br></div><div>These are the kinds of problems that a=
 &quot;raw&quot; or &quot;binary&quot; file-input mode would solve =E2=80=
=94 they&#39;re problems related to source encoding. Problems related to th=
e runtime encoding of glyphs into bytes are already thoroughly solved by th=
e existing prefix/suffix system, which composes fine with the F-prefix.</di=
v><div><br></div><div>HTH,</div><div>=E2=80=93Arthur</div></div></div></div=
></div>

<p></p>

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

--001a113db79cc7fa2b053209cd19--

.

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

On Wed, May 4, 2016 at 9:24 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2016-05-04 11:22, Nicol Bolas wrote:
> > Actually, something just occurred to me about `bF`. Namely, NUL
> termination.
> >
> > All of the genuine string literals should be NUL terminated, since that=
's
> > how we expect literals to behave. But `bF` shouldn't be NUL terminated.
> > So... what do we do?
>
> I'm not sure that's genuinely a problem=C2=B9. Many file formats, even
> binary, are likely tolerant of a "stray" NUL at the end, and even if
> not, I can't think how you would use such a string without specifying
> the length, in which case it would be trivial to subtract 1.
>

IMO this is a genuine problem.
The most obvious use-case for raw binary file input would be as a portable
replacement for "xxd -i".
If you're trying to replace

    const char data[] =3D { 0x01, 0x02, 0x03 };

with a file-input construct, well, you just can't, unless the file-input
construct allows you to specify an array that doesn't end with 0x00. If it
shoves a 0x00 at the end of every array it creates, then not only will your
executable wind up "too big" (and all your subsequent data wind up shoved
down by one byte, which can indeed cause problems for embedded systems) but
also sizeof(data) will be 4 instead of 3, so any code that uses
sizeof(data) will be wrong... It's just a mess. Let's not do that.

I believe that prefix-b or prefix-R or whatever ends up getting proposed
might as well do both things at once:
- don't apply source-encoding-to-character decoding
- don't add null terminator
that is, it should behave just like "xxd -i" (AFAIK).

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Wed, May 4, 2016 at 9:24 AM, Matthew Woehlke <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">=
mwoehlke.floss@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><span class=3D"">On 2016-05-0=
4 11:22, Nicol Bolas wrote:<br>
&gt; Actually, something just occurred to me about `bF`. Namely, NUL termin=
ation.<br>
&gt;<br>
&gt; All of the genuine string literals should be NUL terminated, since tha=
t&#39;s<br>
&gt; how we expect literals to behave. But `bF` shouldn&#39;t be NUL termin=
ated.<br>
&gt; So... what do we do?<br>
<br>
</span>I&#39;m not sure that&#39;s genuinely a problem=C2=B9. Many file for=
mats, even<br>
binary, are likely tolerant of a &quot;stray&quot; NUL at the end, and even=
 if<br>
not, I can&#39;t think how you would use such a string without specifying<b=
r>
the length, in which case it would be trivial to subtract 1.<br></blockquot=
e><div><br></div><div>IMO this is a genuine problem.</div><div>The most obv=
ious use-case for raw binary file input would be as a portable replacement =
for &quot;xxd -i&quot;.</div><div>If you&#39;re trying to replace</div><div=
><br></div><div>=C2=A0 =C2=A0 const char data[] =3D { 0x01, 0x02, 0x03 };</=
div><div><br></div><div>with a file-input construct, well, you just can&#39=
;t, unless the file-input construct allows you to specify an array that doe=
sn&#39;t end with 0x00. If it shoves a 0x00 at the end of every array it cr=
eates, then not only will your executable wind up &quot;too big&quot; (and =
all your subsequent data wind up shoved down by one byte, which can indeed =
cause problems for embedded systems) but also sizeof(data) will be 4 instea=
d of 3, so any code that uses sizeof(data) will be wrong... It&#39;s just a=
 mess. Let&#39;s not do that.</div><div><br></div><div>I believe that prefi=
x-b or prefix-R or whatever ends up getting proposed might as well do both =
things at once:</div><div>- don&#39;t apply source-encoding-to-character de=
coding</div><div>- don&#39;t add null terminator</div><div>that is, it shou=
ld behave just like &quot;xxd -i&quot; (AFAIK).</div><div><br></div><div>=
=E2=80=93Arthur</div></div></div></div>

<p></p>

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

--047d7b41495cd7fdb7053209ec75--

.

------=_Part_2683_95896453.1462403119500
Content-Type: multipart/alternative;
 boundary="----=_Part_2684_423564863.1462403119500"

------=_Part_2684_423564863.1462403119500
Content-Type: text/plain; charset=UTF-8

On Wednesday, May 4, 2016 at 4:09:34 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Wed, May 4, 2016 at 8:08 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Wednesday, May 4, 2016 at 10:23:17 AM UTC-4, Matthew Woehlke wrote:
>>>
>>> Ah... yes, I interpret the original example as being the same as
>>> `F"foo(bar.h)foo"`, with the `R` serving only to specify binary vs. text
>>> include mode. (As Nicol notes, this may be a good reason to use
>>> something other than `R` for that purpose. Maybe we should use `Ft` and
>>> `Fb` instead, with `F` by itself being a synonym for `Ft`?)
>>>
>>
>> We need more than just `t` and `b` here. We need to be able to use the
>> full range of encodings that C++ provides for string literals: narrow,
>> wide, UTF-8, UTF-16, and UTF-32.
>>
>> So `u8F` would mean that the file is encoded in UTF-8, so the generated
>> literal should match. I would prefer to avoid `Fu8`, because that makes
>> `Fu8"filename.txt"` seem like the `u8` applies to the filename literal
>> rather than the generated one.
>>
>> We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), `uF` (UTF-16),
>> `UF` (UTF-32), and `bF` (no translation).
>>
>
> Incorrect (for once ;)).
> The prefixes u8, u, U and the suffix L don't apply to the encoding of the
> *source code*. They apply to the encoding of the *runtime data*.
>

So you're saying that you will always be limited to the source character
set. So... what if the source character set doesn't include all of the
characters you want to use? What if you have a Unicode-encoded file you
want to include?

In a regular C++ file, you can work around this by escaping characters in
string literals. C++11 allows you to do `u8"\u4321"`, and it will convert
that Unicode code unit into a UTF-8 sequence.

How do I do the same with file input? There seem to be 3 alternatives:

1: Escape sequences in the included file are processed as though they were
in a non-raw string literal. That's... bad. I'm pretty sure most people
don't want to have escape sequences work that way, *especially* if they're
including text for other languages like scripting languages.

2: No escape sequences are allowed, which means that the character data for
inclusions is limited to *only* the implementation-defined source character
set. No Unicode characters, nada.

3: The user has the ability to tell the compiler what character set is
being read at the inclusion point.

#3 is what I am referring to with those prefixes.

I recognize that, with binary file loading, you can get the effective
equivalent of Unicode encoding by loading the file as binary data. But it
would be very strange indeed if you couldn't include a UTF-16 file as a
genuine `const char16_t[]` literal, if you had to do a cast from the binary
literal to a string literal.

Especially given endian conversion problems. It'd be great if we could load
a UTF-16 file into our executable and have it use the correct endian for
the platform the executable is running.

So we seem to have two semi-orthogonal dimensions of options: the format of
the source file and the desired format of the converted string literal.
Source files can be:

- Source character set
- Unicode, UTF-8
- Unicode, UTF-16
- Unicode, UTF-32
- Binary, no translation.

String literal formats include, along with their associated source
restrictions:

- Narrow characters: restricted to "source character set" inputs.
- Wide characters: restricted to "source character set" inputs.
- UTF-8: restricted to non-"Binary" inputs.
- UTF-16: restricted to non-"Binary" inputs.
- UTF-32: restricted to non-"Binary" inputs.
- Binary: restricted to "Binary" only.

Given the complexities of the needs here, I have no idea how to specify
this. I really don't want to see: `u8Fu8`, but that's pretty much the only
way I can imagine it working.

Alternatively, we can make the Unicode reading a specialized form of binary
loading. So if you say `u8bF`, what you're saying is that no text
translation will be done, but the file's data will assumed to be a UTF-8
string. Similarly, with `ubF`, the file will be read as a UTF-16 string
with no text translation. `bF` would be pure binary as `const unsigned
char[]`. The Unicode versions would be NUL terminated, but they would have
no text translation done beyond that.

The only use cases with this that would be missed are:

- Unicode transcoding. Reading a UTF-16 file and re-encoding it as UTF-8.
Probably not a compelling use case.

- Text translation with Unicode files. That is, if you have a UTF-8 file
that contains platform-specific newlines and you want it translated to
platform-neutral ones.

That's a compromise I can live with.

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

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

<div dir=3D"ltr">On Wednesday, May 4, 2016 at 4:09:34 PM UTC-4, Arthur O&#3=
9;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Wed, May 4, 2016 at 8:08 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"_rkjJVU0BgAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck...@gmai=
l.com</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><blockquote =
class=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;padding-left:=
1ex"><div dir=3D"ltr"><span>On Wednesday, May 4, 2016 at 10:23:17 AM UTC-4,=
 Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex">Ah... yes, I interpret the original=
 example as being the same as
<br>`F&quot;foo(bar.h)foo&quot;`, with the `R` serving only to specify bina=
ry vs. text
<br>include mode. (As Nicol notes, this may be a good reason to use
<br>something other than `R` for that purpose. Maybe we should use `Ft` and
<br>`Fb` instead, with `F` by itself being a synonym for `Ft`?)<br></blockq=
uote></span><div><br>We need more than just `t` and `b` here. We need to be=
 able to use the full range of encodings that C++ provides for string liter=
als: narrow, wide, UTF-8, UTF-16, and UTF-32.<br><br>So `u8F` would mean th=
at the file is encoded in UTF-8, so the generated literal should match. I w=
ould prefer to avoid `Fu8`, because that makes `Fu8&quot;filename.txt&quot;=
` seem like the `u8` applies to the filename literal rather than the genera=
ted one.<br><br>We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), =
`uF` (UTF-16), `UF` (UTF-32), and `bF` (no translation).<br></div></div></b=
lockquote><div><br></div><div>Incorrect (for once ;)).</div><div>The prefix=
es u8, u, U and the suffix L don&#39;t apply to the encoding of the *source=
 code*. They apply to the encoding of the *runtime data*.</div></div></div>=
</div></blockquote><div><br>So you&#39;re saying that you will always be li=
mited to the source character set. So... what if the source character set d=
oesn&#39;t include all of the characters you want to use? What if you have =
a Unicode-encoded file you want to include?<br><br>In a regular C++ file, y=
ou can work around this by escaping characters in string literals. C++11 al=
lows you to do `u8&quot;\u4321&quot;`, and it will convert that Unicode cod=
e unit into a UTF-8 sequence.<br><br>How do I do the same with file input? =
There seem to be 3 alternatives:<br><br>1: Escape sequences in the included=
 file are processed as though they were in a non-raw string literal. That&#=
39;s... bad. I&#39;m pretty sure most people don&#39;t want to have escape =
sequences work that way, <i>especially</i> if they&#39;re including text fo=
r other languages like scripting languages.<br><br>2: No escape sequences a=
re allowed, which means that the character data for inclusions is limited t=
o <i>only</i> the implementation-defined source character set. No Unicode c=
haracters, nada.<br><br>3: The user has the ability to tell the compiler wh=
at character set is being read at the inclusion point.<br><br>#3 is what I =
am referring to with those prefixes.<br><br>I recognize that, with binary f=
ile loading, you can get the effective equivalent of Unicode encoding by lo=
ading the file as binary data. But it would be very strange indeed if you c=
ouldn&#39;t include a UTF-16 file as a genuine `const char16_t[]` literal, =
if you had to do a cast from the binary literal to a string literal.<br><br=
>Especially given endian conversion problems. It&#39;d be great if we could=
 load a UTF-16 file into our executable and have it use the correct endian =
for the platform the executable is running.<br><br>So we seem to have two s=
emi-orthogonal dimensions of options: the format of the source file and the=
 desired format of the converted string literal. Source files can be:<br><b=
r>- Source character set<br>- Unicode, UTF-8<br>- Unicode, UTF-16<br>- Unic=
ode, UTF-32<br>- Binary, no translation.<br><br>String literal formats incl=
ude, along with their associated source restrictions:<br><br>- Narrow chara=
cters: restricted to &quot;source character set&quot; inputs.<br>- Wide cha=
racters: restricted to &quot;source character set&quot; inputs.<br>- UTF-8:=
 restricted to non-&quot;Binary&quot; inputs.<br>- UTF-16: restricted to no=
n-&quot;Binary&quot; inputs.<br>- UTF-32: restricted to non-&quot;Binary&qu=
ot; inputs.<br>- Binary: restricted to &quot;Binary&quot; only.<br><br>Give=
n the complexities of the needs here, I have no idea how to specify this. I=
 really don&#39;t want to see: `u8Fu8`, but that&#39;s pretty much the only=
 way I can imagine it working.<br><br>Alternatively, we can make the Unicod=
e reading a specialized form of binary loading. So if you say `u8bF`, what =
you&#39;re saying is that no text translation will be done, but the file&#3=
9;s data will assumed to be a UTF-8 string. Similarly, with `ubF`, the file=
 will be read as a UTF-16 string with no text translation. `bF` would be pu=
re binary as `const unsigned char[]`. The Unicode versions would be NUL ter=
minated, but they would have no text translation done beyond that.<br><br>T=
he only use cases with this that would be missed are:<br><br>- Unicode tran=
scoding. Reading a UTF-16 file and re-encoding it as UTF-8. Probably not a =
compelling use case.<br><br>- Text translation with Unicode files. That is,=
 if you have a UTF-8 file that contains platform-specific newlines and you =
want it translated to platform-neutral ones.<br><br>That&#39;s a compromise=
 I can live with.<br></div></div>

<p></p>

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

------=_Part_2684_423564863.1462403119500--
------=_Part_2683_95896453.1462403119500--

.

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

On Wed, May 4, 2016 at 4:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, May 4, 2016 at 4:09:34 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> On Wed, May 4, 2016 at 8:08 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Wednesday, May 4, 2016 at 10:23:17 AM UTC-4, Matthew Woehlke wrote:
>>>>
>>>> Ah... yes, I interpret the original example as being the same as
>>>> `F"foo(bar.h)foo"`, with the `R` serving only to specify binary vs.
>>>> text
>>>> include mode. (As Nicol notes, this may be a good reason to use
>>>> something other than `R` for that purpose. Maybe we should use `Ft` and
>>>> `Fb` instead, with `F` by itself being a synonym for `Ft`?)
>>>>
>>>
>>> We need more than just `t` and `b` here. We need to be able to use the
>>> full range of encodings that C++ provides for string literals: narrow,
>>> wide, UTF-8, UTF-16, and UTF-32.
>>>
>>> So `u8F` would mean that the file is encoded in UTF-8, so the generated
>>> literal should match. I would prefer to avoid `Fu8`, because that makes
>>> `Fu8"filename.txt"` seem like the `u8` applies to the filename literal
>>> rather than the generated one.
>>>
>>> We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), `uF`
>>> (UTF-16), `UF` (UTF-32), and `bF` (no translation).
>>>
>>
>> Incorrect (for once ;)).
>> The prefixes u8, u, U and the suffix L don't apply to the encoding of the
>> *source code*. They apply to the encoding of the *runtime data*.
>>
>
> So you're saying that you will always be limited to the source character
> set. So... what if the source character set doesn't include all of the
> characters you want to use? What if you have a Unicode-encoded file you
> want to include?
>
> In a regular C++ file, you can work around this by escaping characters in
> string literals. C++11 allows you to do `u8"\u4321"`, and it will convert
> that Unicode code unit into a UTF-8 sequence.
>
> How do I do the same with file input? There seem to be 3 alternatives:
>
> 1: Escape sequences in the included file are processed as though they were
> in a non-raw string literal. That's... bad. I'm pretty sure most people
> don't want to have escape sequences work that way, *especially* if
> they're including text for other languages like scripting languages.
>
> 2: No escape sequences are allowed, which means that the character data
> for inclusions is limited to *only* the implementation-defined source
> character set. No Unicode characters, nada.
>
> 3: The user has the ability to tell the compiler what character set is
> being read at the inclusion point.
>
> #3 is what I am referring to with those prefixes.
>

Okay, I now see the problem you're trying to solve, at least. (But maybe
I'm still missing something; see below.)
You're saying: Suppose Alice is on an EBCDIC system (source encoding),
compiling for a system whose runtime encoding is UTF-8, and Alice wants the
file-input equivalent of

    const char32_t data[] = U"\u20AC";

Alice can't represent U+20AC EURO SIGN natively in her EBCDIC source
encoding, so she can't use the "text"/"source-encoded" form of file-input
(i.e. the one in Andrew's proposal).
Alice could create a four-byte file with the contents 0x00 0x00 0x20 0xAC
and include it using the "raw"/"un-encoded" form of file-input, but that
just gets her an array[4] of bytes (say, char). You can't convert those
four bytes to a single char32_t unless you know the platform's endianness,
which is a whole *other* can of worms.
So therefore, Alice has a problem that C++11 string literals *can* solve
but file-input syntax *cannot*. This is unfortunate.


So we seem to have two semi-orthogonal dimensions of options: the format of
> the source file and the desired format of the converted string literal.
> Source files can be:
>
> - Source character set
> - Unicode, UTF-8
> - Unicode, UTF-16
> - Unicode, UTF-32
> - Binary, no translation.
>

My contentions here include:
- Saying a source file is "UTF-16" or "UTF-32" doesn't make sense, because
source files (and files in general, IMHO) are sequences of bytes. You can't
have a "file" of 16-bit or 32-bit units unless you start talking about
endianness, which is a whole can of worms.
- In current C++, u8"foo" and "foo" have the same type, so "file of UTF-8"
and "file of untranslated bytes" are pretty much the same thing in my mind.
I would agree that this state of affairs kind of sucks, but it's also kind
of nice for the people lucky enough to live in a Unicode world already
(which most of the time includes me).
- Whether the file is encoded in the source character set is technically
orthogonal to whether it undergoes newline translation (CRLF to LF, on
Windows), but newline translation is very important and we must specify it
somehow.
- Whether the file is encoded in the source character set is orthogonal to
whether the programmer wants a terminating '\0'; this is also important and
we must specify it somehow.

[...]

> Alternatively, we can make the Unicode reading a specialized form of
> binary loading. So if you say `u8bF`, what you're saying is that no text
> translation will be done, but the file's data will assumed to be a UTF-8
> string. Similarly, with `ubF`, the file will be read as a UTF-16 string
> with no text translation.
>

I contend that "the file will be read as a UTF-16 string" is
underspecified; you have to say either "the file will be read as a
little-endian UTF-16 string" or "the file will be read as a big-endian
UTF-8 string" or "the file will be read as a UTF-16 string respecting (and
discarding) the leading Byte Order Mark; if no BOM is present the file will
be treated as (big-endian, little-endian, ill-formed)".

[...]

> The only use cases with this that would be missed are:
>
> - Unicode transcoding. Reading a UTF-16 file and re-encoding it as UTF-8.
> Probably not a compelling use case.
>
> - Text translation with Unicode files. That is, if you have a UTF-8 file
> that contains platform-specific newlines and you want it translated to
> platform-neutral ones.
>

I'd agree that neither of these cases are useful enough to need solving.
However, isn't the "Unicode transcoding" case exactly the Alice case I
described above as "the problem you're trying to solve"? If you *don't*
care about that scenario... can you give me a concrete example of a Bob
case that you *do* care about, with the same level of detail?

Thanks,
Arthur

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

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

<div dir=3D"ltr">On Wed, May 4, 2016 at 4:05 PM, Nicol Bolas <span dir=3D"l=
tr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@=
gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><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"><div dir=3D"ltr">On Wednesday, May 4, 2016 a=
t 4:09:34 PM UTC-4, Arthur O&#39;Dwyer wrote:<span class=3D""><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex"><div dir=3D"ltr">On Wed, May 4, 2016 at 8:08 AM, Nicol Bolas <span dir=
=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br=
><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span>On=
 Wednesday, May 4, 2016 at 10:23:17 AM UTC-4, Matthew Woehlke wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex">Ah... yes, I interpret the original example as being the same as
<br>`F&quot;foo(bar.h)foo&quot;`, with the `R` serving only to specify bina=
ry vs. text
<br>include mode. (As Nicol notes, this may be a good reason to use
<br>something other than `R` for that purpose. Maybe we should use `Ft` and
<br>`Fb` instead, with `F` by itself being a synonym for `Ft`?)<br></blockq=
uote></span><div><br>We need more than just `t` and `b` here. We need to be=
 able to use the full range of encodings that C++ provides for string liter=
als: narrow, wide, UTF-8, UTF-16, and UTF-32.<br><br>So `u8F` would mean th=
at the file is encoded in UTF-8, so the generated literal should match. I w=
ould prefer to avoid `Fu8`, because that makes `Fu8&quot;filename.txt&quot;=
` seem like the `u8` applies to the filename literal rather than the genera=
ted one.<br><br>We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), =
`uF` (UTF-16), `UF` (UTF-32), and `bF` (no translation).<br></div></div></b=
lockquote><div><br></div><div>Incorrect (for once ;)).</div><div>The prefix=
es u8, u, U and the suffix L don&#39;t apply to the encoding of the *source=
 code*. They apply to the encoding of the *runtime data*.</div></div></div>=
</div></blockquote></span><div><br>So you&#39;re saying that you will alway=
s be limited to the source character set. So... what if the source characte=
r set doesn&#39;t include all of the characters you want to use? What if yo=
u have a Unicode-encoded file you want to include?<br><br>In a regular C++ =
file, you can work around this by escaping characters in string literals. C=
++11 allows you to do `u8&quot;\u4321&quot;`, and it will convert that Unic=
ode code unit into a UTF-8 sequence.<br><br>How do I do the same with file =
input? There seem to be 3 alternatives:<br><br>1: Escape sequences in the i=
ncluded file are processed as though they were in a non-raw string literal.=
 That&#39;s... bad. I&#39;m pretty sure most people don&#39;t want to have =
escape sequences work that way, <i>especially</i> if they&#39;re including =
text for other languages like scripting languages.<br><br>2: No escape sequ=
ences are allowed, which means that the character data for inclusions is li=
mited to <i>only</i> the implementation-defined source character set. No Un=
icode characters, nada.<br><br>3: The user has the ability to tell the comp=
iler what character set is being read at the inclusion point.<br><br>#3 is =
what I am referring to with those prefixes.<br></div></div></blockquote><di=
v><br></div><div>Okay, I now see the problem you&#39;re trying to solve, at=
 least. (But maybe I&#39;m still missing something; see below.)</div><div>Y=
ou&#39;re saying: Suppose Alice is on an EBCDIC system (source encoding), c=
ompiling for a system whose runtime encoding is UTF-8, and Alice wants the =
file-input equivalent of</div><div><br></div><div>=C2=A0 =C2=A0 const char3=
2_t data[] =3D U&quot;\u20AC&quot;;</div><div><br></div><div>Alice can&#39;=
t represent U+20AC EURO SIGN natively in her EBCDIC source encoding, so she=
 can&#39;t use the &quot;text&quot;/&quot;source-encoded&quot; form of file=
-input (i.e. the one in Andrew&#39;s proposal).</div><div>Alice could creat=
e a four-byte file with the contents 0x00 0x00 0x20 0xAC and include it usi=
ng the &quot;raw&quot;/&quot;un-encoded&quot; form of file-input, but that =
just gets her an array[4] of bytes (say, char). You can&#39;t convert those=
 four bytes to a single char32_t unless you know the platform&#39;s endiann=
ess, which is a whole *other* can of worms.</div><div>So therefore, Alice h=
as a problem that C++11 string literals <i>can</i> solve but file-input syn=
tax <i>cannot</i>. This is unfortunate.</div><div><br></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;p=
adding-left:1ex"><div dir=3D"ltr"><div>So we seem to have two semi-orthogon=
al dimensions of options: the format of the source file and the desired for=
mat of the converted string literal. Source files can be:<br><br>- Source c=
haracter set<br>- Unicode, UTF-8<br>- Unicode, UTF-16<br>- Unicode, UTF-32<=
br>- Binary, no translation.<br></div></div></blockquote><div><br></div><di=
v>My contentions here include:</div><div>- Saying a source file is &quot;UT=
F-16&quot; or &quot;UTF-32&quot; doesn&#39;t make sense, because source fil=
es (and files in general, IMHO) are sequences of bytes. You can&#39;t have =
a &quot;file&quot; of 16-bit or 32-bit units unless you start talking about=
 endianness, which is a whole can of worms.</div><div>- In current C++, u8&=
quot;foo&quot; and &quot;foo&quot; have the same type, so &quot;file of UTF=
-8&quot; and &quot;file of untranslated bytes&quot; are pretty much the sam=
e thing in my mind. I would agree that this state of affairs kind of sucks,=
 but it&#39;s also kind of nice for the people lucky enough to live in a Un=
icode world already (which most of the time includes me).</div><div>- Wheth=
er the file is encoded in the source character set is technically orthogona=
l to whether it undergoes newline translation (CRLF to LF, on Windows), but=
 newline translation is very important and we must specify it somehow.</div=
><div>- Whether the file is encoded in the source character set is orthogon=
al to whether the programmer wants a terminating &#39;\0&#39;; this is also=
 important and we must specify it somehow.</div><div><br></div><div>[...]</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><div dir=3D"ltr"><div>Alternatively, we can make the U=
nicode reading a specialized form of binary loading. So if you say `u8bF`, =
what you&#39;re saying is that no text translation will be done, but the fi=
le&#39;s data will assumed to be a UTF-8 string. Similarly, with `ubF`, the=
 file will be read as a UTF-16 string with no text translation.</div></div>=
</blockquote><div><br></div><div>I contend that &quot;the file will be read=
 as a UTF-16 string&quot; is underspecified; you have to say either &quot;t=
he file will be read as a little-endian UTF-16 string&quot; or &quot;the fi=
le will be read as a big-endian UTF-8 string&quot; or &quot;the file will b=
e read as a UTF-16 string respecting (and discarding) the leading Byte Orde=
r Mark; if no BOM is present the file will be treated as (big-endian, littl=
e-endian, ill-formed)&quot;.</div><div>=C2=A0</div><div>[...]</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>The only use cases with this that would be m=
issed are:<br><br>- Unicode transcoding. Reading a UTF-16 file and re-encod=
ing it as UTF-8. Probably not a compelling use case.<br><br>- Text translat=
ion with Unicode files. That is, if you have a UTF-8 file that contains pla=
tform-specific newlines and you want it translated to platform-neutral ones=
..<br></div></div></blockquote><div><br></div><div>I&#39;d agree that neithe=
r of these cases are useful enough to need solving. However, isn&#39;t the =
&quot;Unicode transcoding&quot; case exactly the Alice case I described abo=
ve as &quot;the problem you&#39;re trying to solve&quot;? If you <i>don&#39=
;t</i> care about that scenario... can you give me a concrete example of a =
Bob case that you <i>do</i> care about, with the same level of detail?</div=
><div><br></div><div>Thanks,</div><div>Arthur</div></div></div></div>

<p></p>

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

--001a1147ce7a5d7a3005320e13a1--

.

--94eb2c12458887ddac05320f3306
Content-Type: text/plain; charset=UTF-8

"Big-endian UTF-8" is nonsensical.  UTF-8 has no byte-wise endianness.

Big-endian UTF-16 is spelled UTF-16BE.

Little-endian UTF-16 is spelled UTF-16LE.

A file encoded in UTF-16 means it is either encoded in UTF-16LE or
UTF-16BE.  The platform endianness has no impact on that.  They are two
different encodings.  You have to know which of the two encodings the file
is in to decode it, which can be deduced from a BOM if present.

We can talk about a sequence of 16-bit integer code units being encoded in
UTF-16 without talking about endianness.  This is because the code units
have already been decoded from bytes to integers.

My current design has two input formats.  Binary and text.  The text
encoding format is the usual source encoding for your source files (the
overwhelming default these days is UTF-8).  If you have a text file in a
different encoding, then you can transcode it into source encoding within
your source files.  It will then undergo the usual source-to-execution
transcoding that the bodies of raw string literals undergo. Alternatively,
you can read it in as a binary file and then transcode it yourself into
execution encoding with constexpr programming in whatever fashion you want.

Beyond these two options, I do not think futher built-in support for a
specific set of different source text encoding formats is necessary.

I am struggling with the binary file literal size issue.  I do not think
that null-termination should be present on binary file literals, to
discourage use.  Binary file literals in the general case do contain
embedded nulls.  I would like them to be arrays of char, but they would
then easily coerce to const char* which looks like a C string.  I would
like to be able to write a constexpr function f such that both f(F"foo")
and f(bF"foo") will work and properly get the range of bytes that the two
literals present.  It is conceivable using unsigned char instead of char
for the binary file literals would help here:

   void f(const char* cstr);  // use cstr[0] through cstr[strlen(cstr)-1]

   template<size_t N>
   void f(const unsigned char (&arr)[N]); // use arr[0] through arr[N-1]

Ultimately I would like this to work:

   constexpr string_view sv = bF"foo";

It is unclear to me if the seemingly necessary reinterpret cast of the
const unsigned char* to the const char* is allowed in constexpr
programming.  This is where I am stuck currently.


On Thu, May 5, 2016 at 3:15 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Wed, May 4, 2016 at 4:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Wednesday, May 4, 2016 at 4:09:34 PM UTC-4, Arthur O'Dwyer wrote:
>>>
>>> On Wed, May 4, 2016 at 8:08 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Wednesday, May 4, 2016 at 10:23:17 AM UTC-4, Matthew Woehlke wrote:
>>>>>
>>>>> Ah... yes, I interpret the original example as being the same as
>>>>> `F"foo(bar.h)foo"`, with the `R` serving only to specify binary vs.
>>>>> text
>>>>> include mode. (As Nicol notes, this may be a good reason to use
>>>>> something other than `R` for that purpose. Maybe we should use `Ft`
>>>>> and
>>>>> `Fb` instead, with `F` by itself being a synonym for `Ft`?)
>>>>>
>>>>
>>>> We need more than just `t` and `b` here. We need to be able to use the
>>>> full range of encodings that C++ provides for string literals: narrow,
>>>> wide, UTF-8, UTF-16, and UTF-32.
>>>>
>>>> So `u8F` would mean that the file is encoded in UTF-8, so the generated
>>>> literal should match. I would prefer to avoid `Fu8`, because that makes
>>>> `Fu8"filename.txt"` seem like the `u8` applies to the filename literal
>>>> rather than the generated one.
>>>>
>>>> We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), `uF`
>>>> (UTF-16), `UF` (UTF-32), and `bF` (no translation).
>>>>
>>>
>>> Incorrect (for once ;)).
>>> The prefixes u8, u, U and the suffix L don't apply to the encoding of
>>> the *source code*. They apply to the encoding of the *runtime data*.
>>>
>>
>> So you're saying that you will always be limited to the source character
>> set. So... what if the source character set doesn't include all of the
>> characters you want to use? What if you have a Unicode-encoded file you
>> want to include?
>>
>> In a regular C++ file, you can work around this by escaping characters in
>> string literals. C++11 allows you to do `u8"\u4321"`, and it will convert
>> that Unicode code unit into a UTF-8 sequence.
>>
>> How do I do the same with file input? There seem to be 3 alternatives:
>>
>> 1: Escape sequences in the included file are processed as though they
>> were in a non-raw string literal. That's... bad. I'm pretty sure most
>> people don't want to have escape sequences work that way, *especially*
>> if they're including text for other languages like scripting languages.
>>
>> 2: No escape sequences are allowed, which means that the character data
>> for inclusions is limited to *only* the implementation-defined source
>> character set. No Unicode characters, nada.
>>
>> 3: The user has the ability to tell the compiler what character set is
>> being read at the inclusion point.
>>
>> #3 is what I am referring to with those prefixes.
>>
>
> Okay, I now see the problem you're trying to solve, at least. (But maybe
> I'm still missing something; see below.)
> You're saying: Suppose Alice is on an EBCDIC system (source encoding),
> compiling for a system whose runtime encoding is UTF-8, and Alice wants the
> file-input equivalent of
>
>     const char32_t data[] = U"\u20AC";
>
> Alice can't represent U+20AC EURO SIGN natively in her EBCDIC source
> encoding, so she can't use the "text"/"source-encoded" form of file-input
> (i.e. the one in Andrew's proposal).
> Alice could create a four-byte file with the contents 0x00 0x00 0x20 0xAC
> and include it using the "raw"/"un-encoded" form of file-input, but that
> just gets her an array[4] of bytes (say, char). You can't convert those
> four bytes to a single char32_t unless you know the platform's endianness,
> which is a whole *other* can of worms.
> So therefore, Alice has a problem that C++11 string literals *can* solve
> but file-input syntax *cannot*. This is unfortunate.
>
>
> So we seem to have two semi-orthogonal dimensions of options: the format
>> of the source file and the desired format of the converted string literal.
>> Source files can be:
>>
>> - Source character set
>> - Unicode, UTF-8
>> - Unicode, UTF-16
>> - Unicode, UTF-32
>> - Binary, no translation.
>>
>
> My contentions here include:
> - Saying a source file is "UTF-16" or "UTF-32" doesn't make sense, because
> source files (and files in general, IMHO) are sequences of bytes. You can't
> have a "file" of 16-bit or 32-bit units unless you start talking about
> endianness, which is a whole can of worms.
> - In current C++, u8"foo" and "foo" have the same type, so "file of UTF-8"
> and "file of untranslated bytes" are pretty much the same thing in my mind.
> I would agree that this state of affairs kind of sucks, but it's also kind
> of nice for the people lucky enough to live in a Unicode world already
> (which most of the time includes me).
> - Whether the file is encoded in the source character set is technically
> orthogonal to whether it undergoes newline translation (CRLF to LF, on
> Windows), but newline translation is very important and we must specify it
> somehow.
> - Whether the file is encoded in the source character set is orthogonal to
> whether the programmer wants a terminating '\0'; this is also important and
> we must specify it somehow.
>
> [...]
>
>> Alternatively, we can make the Unicode reading a specialized form of
>> binary loading. So if you say `u8bF`, what you're saying is that no text
>> translation will be done, but the file's data will assumed to be a UTF-8
>> string. Similarly, with `ubF`, the file will be read as a UTF-16 string
>> with no text translation.
>>
>
> I contend that "the file will be read as a UTF-16 string" is
> underspecified; you have to say either "the file will be read as a
> little-endian UTF-16 string" or "the file will be read as a big-endian
> UTF-8 string" or "the file will be read as a UTF-16 string respecting (and
> discarding) the leading Byte Order Mark; if no BOM is present the file will
> be treated as (big-endian, little-endian, ill-formed)".
>
> [...]
>
>> The only use cases with this that would be missed are:
>>
>> - Unicode transcoding. Reading a UTF-16 file and re-encoding it as UTF-8.
>> Probably not a compelling use case.
>>
>> - Text translation with Unicode files. That is, if you have a UTF-8 file
>> that contains platform-specific newlines and you want it translated to
>> platform-neutral ones.
>>
>
> I'd agree that neither of these cases are useful enough to need solving.
> However, isn't the "Unicode transcoding" case exactly the Alice case I
> described above as "the problem you're trying to solve"? If you *don't*
> care about that scenario... can you give me a concrete example of a Bob
> case that you *do* care about, with the same level of detail?
>
> Thanks,
> Arthur
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BDjUDqprR8VvuqUJMMaP9LhGepOKpEAbnvB%2BTk6VAwoQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BDjUDqprR8VvuqUJMMaP9LhGepOKpEAbnvB%2BTk6VAwoQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr">&quot;Big-endian UTF-8&quot; is nonsensical.=C2=A0 UTF-8 h=
as no byte-wise endianness.<div><br></div><div>Big-endian UTF-16 is spelled=
 UTF-16BE.</div><div><br></div><div>Little-endian UTF-16 is spelled UTF-16L=
E.</div><div><br></div><div>A file encoded in UTF-16 means it is either enc=
oded in UTF-16LE or UTF-16BE.=C2=A0 The platform endianness has no impact o=
n that.=C2=A0 They are two different encodings.=C2=A0 You have to know whic=
h of the two encodings the file is in to decode it, which can be deduced fr=
om a BOM if present.</div><div><br></div><div>We can talk about a sequence =
of 16-bit integer code units being encoded in UTF-16 without talking about =
endianness.=C2=A0 This is because the code units have already been decoded =
from bytes to integers.</div><div><br></div><div>My current design has two =
input formats.=C2=A0 Binary and text.=C2=A0 The text encoding format is the=
 usual source encoding for your source files (the overwhelming default thes=
e days is UTF-8).=C2=A0 If you have a text file in a different encoding, th=
en you can transcode it into source encoding within your source files.=C2=
=A0 It will then undergo the usual source-to-execution transcoding that the=
 bodies of raw string literals undergo. Alternatively, you can read it in a=
s a binary file and then transcode it yourself into execution encoding with=
 constexpr programming in whatever fashion you want.</div><div><br></div><d=
iv>Beyond these two options, I do not think futher built-in support for a s=
pecific set of different source text encoding formats is necessary.</div><d=
iv><br></div><div>I am struggling with the binary file literal size issue.=
=C2=A0 I do not think that null-termination should be present on binary fil=
e literals, to discourage use.=C2=A0 Binary file literals in the general ca=
se do contain embedded nulls.=C2=A0 I would like them to be arrays of char,=
 but they would then easily coerce to const char* which looks like a C stri=
ng.=C2=A0 I would like to be able to write a constexpr function f such that=
 both f(F&quot;foo&quot;) and f(bF&quot;foo&quot;) will work and properly g=
et the range of bytes that the two literals present.=C2=A0 It is conceivabl=
e using unsigned char instead of char for the binary file literals would he=
lp here:</div><div><br></div><div>=C2=A0 =C2=A0void f(const char* cstr); =
=C2=A0// use cstr[0] through cstr[strlen(cstr)-1]</div><div><br></div><div>=
=C2=A0 =C2=A0template&lt;size_t N&gt;</div><div>=C2=A0 =C2=A0void f(const u=
nsigned char (&amp;arr)[N]); // use arr[0] through arr[N-1]</div><div><br><=
/div><div>Ultimately I would like this to work:</div><div><br></div><div>=
=C2=A0 =C2=A0constexpr string_view sv =3D bF&quot;foo&quot;;</div><div><br>=
</div><div>It is unclear to me if the seemingly necessary reinterpret cast =
of the const unsigned char* to the const char* is allowed in constexpr prog=
ramming.=C2=A0 This is where I am stuck currently.</div><div><br></div><div=
><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Thu, Ma=
y 5, 2016 at 3:15 AM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<span>On Wed, May 4, 2016 at 4:05 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, May 4, 2016=
 at 4:09:34 PM UTC-4, Arthur O&#39;Dwyer wrote:<span><blockquote class=3D"g=
mail_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"><div =
dir=3D"ltr">On Wed, May 4, 2016 at 8:08 AM, Nicol Bolas <span dir=3D"ltr">&=
lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br><div><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span>On Wednesday=
, May 4, 2016 at 10:23:17 AM UTC-4, Matthew Woehlke wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
Ah... yes, I interpret the original example as being the same as
<br>`F&quot;foo(bar.h)foo&quot;`, with the `R` serving only to specify bina=
ry vs. text
<br>include mode. (As Nicol notes, this may be a good reason to use
<br>something other than `R` for that purpose. Maybe we should use `Ft` and
<br>`Fb` instead, with `F` by itself being a synonym for `Ft`?)<br></blockq=
uote></span><div><br>We need more than just `t` and `b` here. We need to be=
 able to use the full range of encodings that C++ provides for string liter=
als: narrow, wide, UTF-8, UTF-16, and UTF-32.<br><br>So `u8F` would mean th=
at the file is encoded in UTF-8, so the generated literal should match. I w=
ould prefer to avoid `Fu8`, because that makes `Fu8&quot;filename.txt&quot;=
` seem like the `u8` applies to the filename literal rather than the genera=
ted one.<br><br>We need to have: `F` (narrow), `LF` (wide), `u8F` (UTF-8), =
`uF` (UTF-16), `UF` (UTF-32), and `bF` (no translation).<br></div></div></b=
lockquote><div><br></div><div>Incorrect (for once ;)).</div><div>The prefix=
es u8, u, U and the suffix L don&#39;t apply to the encoding of the *source=
 code*. They apply to the encoding of the *runtime data*.</div></div></div>=
</div></blockquote></span><div><br>So you&#39;re saying that you will alway=
s be limited to the source character set. So... what if the source characte=
r set doesn&#39;t include all of the characters you want to use? What if yo=
u have a Unicode-encoded file you want to include?<br><br>In a regular C++ =
file, you can work around this by escaping characters in string literals. C=
++11 allows you to do `u8&quot;\u4321&quot;`, and it will convert that Unic=
ode code unit into a UTF-8 sequence.<br><br>How do I do the same with file =
input? There seem to be 3 alternatives:<br><br>1: Escape sequences in the i=
ncluded file are processed as though they were in a non-raw string literal.=
 That&#39;s... bad. I&#39;m pretty sure most people don&#39;t want to have =
escape sequences work that way, <i>especially</i> if they&#39;re including =
text for other languages like scripting languages.<br><br>2: No escape sequ=
ences are allowed, which means that the character data for inclusions is li=
mited to <i>only</i> the implementation-defined source character set. No Un=
icode characters, nada.<br><br>3: The user has the ability to tell the comp=
iler what character set is being read at the inclusion point.<br><br>#3 is =
what I am referring to with those prefixes.<br></div></div></blockquote><di=
v><br></div></span><div>Okay, I now see the problem you&#39;re trying to so=
lve, at least. (But maybe I&#39;m still missing something; see below.)</div=
><div>You&#39;re saying: Suppose Alice is on an EBCDIC system (source encod=
ing), compiling for a system whose runtime encoding is UTF-8, and Alice wan=
ts the file-input equivalent of</div><div><br></div><div>=C2=A0 =C2=A0 cons=
t char32_t data[] =3D U&quot;\u20AC&quot;;</div><div><br></div><div>Alice c=
an&#39;t represent U+20AC EURO SIGN natively in her EBCDIC source encoding,=
 so she can&#39;t use the &quot;text&quot;/&quot;source-encoded&quot; form =
of file-input (i.e. the one in Andrew&#39;s proposal).</div><div>Alice coul=
d create a four-byte file with the contents 0x00 0x00 0x20 0xAC and include=
 it using the &quot;raw&quot;/&quot;un-encoded&quot; form of file-input, bu=
t that just gets her an array[4] of bytes (say, char). You can&#39;t conver=
t those four bytes to a single char32_t unless you know the platform&#39;s =
endianness, which is a whole *other* can of worms.</div><div>So therefore, =
Alice has a problem that C++11 string literals <i>can</i> solve but file-in=
put syntax <i>cannot</i>. This is unfortunate.</div><span><div><br></div><d=
iv><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"><div dir=3D"ltr"><div>So we seem to have two =
semi-orthogonal dimensions of options: the format of the source file and th=
e desired format of the converted string literal. Source files can be:<br><=
br>- Source character set<br>- Unicode, UTF-8<br>- Unicode, UTF-16<br>- Uni=
code, UTF-32<br>- Binary, no translation.<br></div></div></blockquote><div>=
<br></div></span><div>My contentions here include:</div><div>- Saying a sou=
rce file is &quot;UTF-16&quot; or &quot;UTF-32&quot; doesn&#39;t make sense=
, because source files (and files in general, IMHO) are sequences of bytes.=
 You can&#39;t have a &quot;file&quot; of 16-bit or 32-bit units unless you=
 start talking about endianness, which is a whole can of worms.</div><div>-=
 In current C++, u8&quot;foo&quot; and &quot;foo&quot; have the same type, =
so &quot;file of UTF-8&quot; and &quot;file of untranslated bytes&quot; are=
 pretty much the same thing in my mind. I would agree that this state of af=
fairs kind of sucks, but it&#39;s also kind of nice for the people lucky en=
ough to live in a Unicode world already (which most of the time includes me=
).</div><div>- Whether the file is encoded in the source character set is t=
echnically orthogonal to whether it undergoes newline translation (CRLF to =
LF, on Windows), but newline translation is very important and we must spec=
ify it somehow.</div><div>- Whether the file is encoded in the source chara=
cter set is orthogonal to whether the programmer wants a terminating &#39;\=
0&#39;; this is also important and we must specify it somehow.</div><div><b=
r></div><div>[...]</div><span><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>Altern=
atively, we can make the Unicode reading a specialized form of binary loadi=
ng. So if you say `u8bF`, what you&#39;re saying is that no text translatio=
n will be done, but the file&#39;s data will assumed to be a UTF-8 string. =
Similarly, with `ubF`, the file will be read as a UTF-16 string with no tex=
t translation.</div></div></blockquote><div><br></div></span><div>I contend=
 that &quot;the file will be read as a UTF-16 string&quot; is underspecifie=
d; you have to say either &quot;the file will be read as a little-endian UT=
F-16 string&quot; or &quot;the file will be read as a big-endian UTF-8 stri=
ng&quot; or &quot;the file will be read as a UTF-16 string respecting (and =
discarding) the leading Byte Order Mark; if no BOM is present the file will=
 be treated as (big-endian, little-endian, ill-formed)&quot;.</div><div>=C2=
=A0</div><div>[...]</div><span><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>The o=
nly use cases with this that would be missed are:<br><br>- Unicode transcod=
ing. Reading a UTF-16 file and re-encoding it as UTF-8. Probably not a comp=
elling use case.<br><br>- Text translation with Unicode files. That is, if =
you have a UTF-8 file that contains platform-specific newlines and you want=
 it translated to platform-neutral ones.<br></div></div></blockquote><div><=
br></div></span><div>I&#39;d agree that neither of these cases are useful e=
nough to need solving. However, isn&#39;t the &quot;Unicode transcoding&quo=
t; case exactly the Alice case I described above as &quot;the problem you&#=
39;re trying to solve&quot;? If you <i>don&#39;t</i> care about that scenar=
io... can you give me a concrete example of a Bob case that you <i>do</i> c=
are about, with the same level of detail?</div><div><br></div><div>Thanks,<=
/div><div>Arthur</div></div></div></div><span>

<p></p>

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

<p></p>

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

--94eb2c12458887ddac05320f3306--

.

On 2016-05-04 19:05, Nicol Bolas wrote:
> Alternatively, we can make the Unicode reading a specialized form of binary
> loading. So if you say `u8bF`, what you're saying is that no text
> translation will be done, but the file's data will assumed to be a UTF-8
> string. Similarly, with `ubF`, the file will be read as a UTF-16 string
> with no text translation. `bF` would be pure binary as `const unsigned
> char[]`. The Unicode versions would be NUL terminated, but they would have
> no text translation done beyond that.
>
> The only use cases with this that would be missed are:
>
> - Unicode transcoding. Reading a UTF-16 file and re-encoding it as UTF-8.
> Probably not a compelling use case.
>
> - Text translation with Unicode files. That is, if you have a UTF-8 file
> that contains platform-specific newlines and you want it translated to
> platform-neutral ones.
>
> That's a compromise I can live with.

Personally, I'd prefer if the source (if text) is required to be in
Unicode with a BOM, *but* newline translation is performed. If we
require a BOM (except in UTF-8; lack of a BOM would therefore imply
UTF-8), we can trivially identify which flavor of Unicode is used by the
input file.

Losing newline translation seems... unfortunate.

I suppose the major problem would be if a file needs to be used both via
this C++ include mechanism and also some other context (e.g. a source
file of some other language that is both embedded and also used directly
by that language's compiler/interpreter).

That said... keep in mind that compile-time string processing may
provide a better (more flexible, at least, if almost certainly far more
verbose) mechanism for coping with these issues. For example, per
Andrew's comment, if you *must* read a file in other than the source
encoding, you could read it in binary and run it through such mechanism
to produce whatever run-time representation is required.

I have to wonder, again, if we're trying to overengineer the feature...

--
Matthew

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

.

On 5/5/2016 10:52 AM, Matthew Woehlke wrote:
> Personally, I'd prefer if the source (if text) is required to be in
> Unicode with a BOM...

Please, no.  On non-ASCII based systems, forcing Unicode would be a
significant burden to users.

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/724360e0-61db-81f4-55bb-9e671f84e4b7%40honermann.net.

.

On 2016-05-05 11:01, Tom Honermann wrote:
> On 5/5/2016 10:52 AM, Matthew Woehlke wrote:
>> Personally, I'd prefer if the source (if text) is required to be in
>> Unicode with a BOM...
>=20
> Please, no.  On non-ASCII based systems, forcing Unicode would be a
> significant burden to users.

Uh, you *do* realize that ASCII is a subset of UTF-8, yes? Requiring
input files to be Unicode with BOM (no BOM =E2=86=92 UTF-8) would be fully
compatible with ASCII-conforming input files.

--=20
Matthew

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

.

On 5/5/2016 11:15 AM, Matthew Woehlke wrote:
> On 2016-05-05 11:01, Tom Honermann wrote:
>> On 5/5/2016 10:52 AM, Matthew Woehlke wrote:
>>> Personally, I'd prefer if the source (if text) is required to be in
>>> Unicode with a BOM...
>> Please, no.  On non-ASCII based systems, forcing Unicode would be a
>> significant burden to users.
> Uh, you *do* realize that ASCII is a subset of UTF-8, yes? Requiring
> input files to be Unicode with BOM (no BOM =E2=86=92 UTF-8) would be full=
y
> compatible with ASCII-conforming input files.
>
I said on *non*-ASCII based systems.

Also, UTF-8 files may have a BOM.

Tom.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/753c1978-69d0-5a27-79e3-238d871769c3%40honermann=
..net.

.

------=_Part_180_931478677.1462461996011
Content-Type: multipart/alternative;
 boundary="----=_Part_181_1174125489.1462461996011"

------=_Part_181_1174125489.1462461996011
Content-Type: text/plain; charset=UTF-8

On Wednesday, May 4, 2016 at 10:35:55 PM UTC-4, Andrew Tomazos wrote:
>
> My current design has two input formats.  Binary and text.  The text
> encoding format is the usual source encoding for your source files (the
> overwhelming default these days is UTF-8).  If you have a text file in a
> different encoding, then you can transcode it into source encoding within
> your source files. It will then undergo the usual source-to-execution
> transcoding that the bodies of raw string literals undergo.
>

Source encodings are *not* required to be able to support all of Unicode.
And without escape characters and `\U`, I have no way to "transcode it into
source encoding" because the source encoding *cannot support it*.  If I
have a Unicode-encoded file under your rules, the only thing I can do is
load it as binary. And thanks to cross-compiling, the executable
environment may have a different endian than the source environment.

Beyond these two options, I do not think futher built-in support for a
> specific set of different source text encoding formats is necessary.
>

Internationalization is *not optional*. Nor is cross-compilation support.


>   I would like to be able to write a constexpr function f such that both
> f(F"foo") and f(bF"foo") will work and properly get the range of bytes that
> the two literals present.
>

.... why? Generally speaking, functions that process text and functions that
process binary data are *different* functions. Unless your binary data
actually is text, but that doesn't really make sense.

Ultimately I would like this to work:
>
>    constexpr string_view sv = bF"foo";
>

Why? `string_view`, as the name suggests, is for *strings*. The class you
want is called `span<unsigned char>`. That's how we spell "array of
arbitrary bytes" in C++.

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

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

<div dir=3D"ltr">On Wednesday, May 4, 2016 at 10:35:55 PM UTC-4, Andrew Tom=
azos wrote:<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"><d=
iv></div><div>My current design has two input formats.=C2=A0 Binary and tex=
t.=C2=A0 The text encoding format is the usual source encoding for your sou=
rce files (the overwhelming default these days is UTF-8).=C2=A0 If you have=
 a text file in a different encoding, then you can transcode it into source=
 encoding within your source files. It will then undergo the usual source-t=
o-execution transcoding that the bodies of raw string literals undergo. </d=
iv></div></blockquote><div><br>Source encodings are <i>not</i> required to =
be able to support all of Unicode. And without escape characters and `\U`, =
I have no way to &quot;transcode it into source encoding&quot; because the =
source encoding <i>cannot support it</i>.=C2=A0 If I have a Unicode-encoded=
 file under your rules, the only thing I can do is load it as binary. And t=
hanks to cross-compiling, the executable environment may have a different e=
ndian than the source environment.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Beyond these two options=
, I do not think futher built-in support for a specific set of different so=
urce text encoding formats is necessary.</div></div></blockquote><div><br>I=
nternationalization is <i>not optional</i>. Nor is cross-compilation suppor=
t.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div>=C2=A0 I would like to be able to write a constexpr fu=
nction f such that both f(F&quot;foo&quot;) and f(bF&quot;foo&quot;) will w=
ork and properly get the range of bytes that the two literals present.</div=
></div></blockquote><div><br>... why? Generally speaking, functions that pr=
ocess text and functions that process binary data are <i>different</i> func=
tions. Unless your binary data actually is text, but that doesn&#39;t reall=
y make sense.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div></div><div>Ultimately I would like this to work:</div><d=
iv><br></div><div>=C2=A0 =C2=A0constexpr string_view sv =3D bF&quot;foo&quo=
t;;</div></div></blockquote><div><br>Why? `string_view`, as the name sugges=
ts, is for <i>strings</i>. The class you want is called `span&lt;unsigned c=
har&gt;`. That&#39;s how we spell &quot;array of arbitrary bytes&quot; in C=
++.</div></div>

<p></p>

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

------=_Part_181_1174125489.1462461996011--
------=_Part_180_931478677.1462461996011--

.

On 2016-05-05 11:18, Tom Honermann wrote:
> On 5/5/2016 11:15 AM, Matthew Woehlke wrote:
>> On 2016-05-05 11:01, Tom Honermann wrote:
>>> On 5/5/2016 10:52 AM, Matthew Woehlke wrote:
>>>> Personally, I'd prefer if the source (if text) is required to be in
>>>> Unicode with a BOM...
>>> Please, no.  On non-ASCII based systems, forcing Unicode would be a
>>> significant burden to users.
>> Uh, you *do* realize that ASCII is a subset of UTF-8, yes? Requiring
>> input files to be Unicode with BOM (no BOM =E2=86=92 UTF-8) would be ful=
ly
>> compatible with ASCII-conforming input files.
>>
> I said on *non*-ASCII based systems.

Ah, sorry, misread :-). But in that case, Andrew's suggestion (just read
it as source encoding, and if you need something else, "too bad"=C2=B9)
works. I'm more inclined to that anyway.

(=C2=B9 Use compile-time text processing for this case if you simply *must*
have it.)

--=20
Matthew

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

.

------=_Part_5602_1444183611.1462463384473
Content-Type: multipart/alternative;
 boundary="----=_Part_5603_2064761386.1462463384473"

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

On Thursday, May 5, 2016 at 11:29:49 AM UTC-4, Matthew Woehlke wrote:
>
> On 2016-05-05 11:18, Tom Honermann wrote:=20
> > On 5/5/2016 11:15 AM, Matthew Woehlke wrote:=20
> >> On 2016-05-05 11:01, Tom Honermann wrote:=20
> >>> On 5/5/2016 10:52 AM, Matthew Woehlke wrote:=20
> >>>> Personally, I'd prefer if the source (if text) is required to be in=
=20
> >>>> Unicode with a BOM...=20
> >>> Please, no.  On non-ASCII based systems, forcing Unicode would be a=
=20
> >>> significant burden to users.=20
> >> Uh, you *do* realize that ASCII is a subset of UTF-8, yes? Requiring=
=20
> >> input files to be Unicode with BOM (no BOM =E2=86=92 UTF-8) would be f=
ully=20
> >> compatible with ASCII-conforming input files.=20
> >>=20
> > I said on *non*-ASCII based systems.=20
>
> Ah, sorry, misread :-).

=20
>
But in that case, Andrew's suggestion (just read=20
> it as source encoding, and if you need something else, "too bad"=C2=B9)=
=20
> works. I'm more inclined to that anyway.
>

It's silly to give up now that we're so close to a functional design. You=
=20
pointed out that you can identify Unicode-encoded files by their BOMs. So=
=20
instead of the giant number of sources, we actually only have:

- Source character set
- Unicode, in a format as identified by BOMs
- Binary

`F` would mean source character set. `Fb` would mean binary. And `Fu` would=
=20
mean Unicode, as identified by BOMs. You can still apply the encoding=20
prefixes to the non-binary forms, and indeed you *must* provide one for=20
`Fu`. For example:

- u8F: Read source character set, convert to UTF-8.
- uFu: Read Unicode text, convert to UTF-16.

And so forth.

`Fu` would specifically mean:

- Platform-specific text translation (new-lines and so forth).
- BOM to identify the source Unicode encoding and endian. Lack of BOM=20
automatically means UTF-8, but the UTF-8 BOM will also mean UTF-8. BOM is=
=20
stripped out.
- NUL-terminated.

The encoding prefix allows cross-Unicode conversion. So if you have a=20
UTF-16 text file and you want to store it as UTF-8, you use `u8Fu`.

It's a simple and elegant solution to the source encoding problem.


> (=C2=B9 Use compile-time text processing for this case if you simply *mus=
t*=20
> have it.)=20
>

The problem with that is that you are assuming that Unicode-encoded files=
=20
represent a minor province of what people do. I disagree. "Must have it" is=
=20
something that a *lot* of people will need.

There's a *reason* why C++11 added explicit support for Unicode-encoded=20
literals. Even if they are written in the source character set, the fact=20
that you get Unicode-defined results for them is important.

People will want to use textual inclusion for many kinds of data tables.=20
Some of these tables *will include* Internationalization strings. And that=
=20
requires Unicode support.

Furthermore, it is not clear to me at all that one actually *can* implement=
=20
compile-time conversion support. It seems to me that lengthy compile-time=
=20
conversions could run afoul of compiler limitations, depending on the size=
=20
of the input data. Whereas built-in support would not only be faster but=20
far less likely to encounter such limits.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9d02c518-bee6-4b2c-a5c6-7975263d20a4%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, May 5, 2016 at 11:29:49 AM UTC-4, Matthew Woe=
hlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-05-05 11:18=
, Tom Honermann wrote:
<br>&gt; On 5/5/2016 11:15 AM, Matthew Woehlke wrote:
<br>&gt;&gt; On 2016-05-05 11:01, Tom Honermann wrote:
<br>&gt;&gt;&gt; On 5/5/2016 10:52 AM, Matthew Woehlke wrote:
<br>&gt;&gt;&gt;&gt; Personally, I&#39;d prefer if the source (if text) is =
required to be in
<br>&gt;&gt;&gt;&gt; Unicode with a BOM...
<br>&gt;&gt;&gt; Please, no. =C2=A0On non-ASCII based systems, forcing Unic=
ode would be a
<br>&gt;&gt;&gt; significant burden to users.
<br>&gt;&gt; Uh, you *do* realize that ASCII is a subset of UTF-8, yes? Req=
uiring
<br>&gt;&gt; input files to be Unicode with BOM (no BOM =E2=86=92 UTF-8) wo=
uld be fully
<br>&gt;&gt; compatible with ASCII-conforming input files.
<br>&gt;&gt;
<br>&gt; I said on *non*-ASCII based systems.
<br>
<br>Ah, sorry, misread :-).</blockquote><blockquote style=3D"margin: 0px 0p=
x 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"=
 class=3D"gmail_quote"><div>=C2=A0</div></blockquote><div></div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">But in that case, Andrew&#39;s suggestion=
 (just read
<br>it as source encoding, and if you need something else, &quot;too bad&qu=
ot;=C2=B9)
<br>works. I&#39;m more inclined to that anyway.<br></blockquote><div><br>I=
t&#39;s silly to give up now that we&#39;re so close to a functional design=
.. You pointed out that you can identify Unicode-encoded files by their BOMs=
.. So instead of the giant number of sources, we actually only have:<br><br>=
- Source character set<br>- Unicode, in a format as identified by BOMs<br>-=
 Binary<br><br>`F` would mean source character set. `Fb` would mean binary.=
 And `Fu` would mean Unicode, as identified by BOMs. You can still apply th=
e encoding prefixes to the non-binary forms, and indeed you <i>must</i> pro=
vide one for `Fu`. For example:<br><br>- u8F: Read source character set, co=
nvert to UTF-8.<br>- uFu: Read Unicode text, convert to UTF-16.<br><br>And =
so forth.<br><br>`Fu` would specifically mean:<br><br>- Platform-specific t=
ext translation (new-lines and so forth).<br>- BOM to identify the source U=
nicode encoding and endian. Lack of BOM automatically means UTF-8, but the =
UTF-8 BOM will also mean UTF-8. BOM is stripped out.<br>- NUL-terminated.<b=
r><br>The encoding prefix allows cross-Unicode conversion. So if you have a=
 UTF-16 text file and you want to store it as UTF-8, you use `u8Fu`.<br><br=
>It&#39;s a simple and elegant solution to the source encoding problem.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>(=C2=B9 Use compile-time text processing for this case if you simply *m=
ust*
<br>have it.)
<br></blockquote><div><br>The problem with that is that you are assuming th=
at Unicode-encoded files represent a minor province of what people do. I di=
sagree. &quot;Must have it&quot; is something that a <i>lot</i> of people w=
ill need.<br><br>There&#39;s a <i>reason</i> why C++11 added explicit suppo=
rt for Unicode-encoded literals. Even if they are written in the source cha=
racter set, the fact that you get Unicode-defined results for them is impor=
tant.<br><br>People will want to use textual inclusion for many kinds of da=
ta tables. Some of these tables <i>will include</i> Internationalization st=
rings. And that requires Unicode support.<br><br>Furthermore, it is not cle=
ar to me at all that one actually <i>can</i> implement compile-time convers=
ion support. It seems to me that lengthy compile-time conversions could run=
 afoul of compiler limitations, depending on the size of the input data. Wh=
ereas built-in support would not only be faster but far less likely to enco=
unter such limits.<br></div></div>

<p></p>

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

------=_Part_5603_2064761386.1462463384473--
------=_Part_5602_1444183611.1462463384473--

.

--94eb2c12371232891705321a4bdb
Content-Type: text/plain; charset=UTF-8

On Thu, May 5, 2016 at 5:26 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, May 4, 2016 at 10:35:55 PM UTC-4, Andrew Tomazos wrote:
>>
>> My current design has two input formats.  Binary and text.  The text
>> encoding format is the usual source encoding for your source files (the
>> overwhelming default these days is UTF-8).  If you have a text file in a
>> different encoding, then you can transcode it into source encoding within
>> your source files. It will then undergo the usual source-to-execution
>> transcoding that the bodies of raw string literals undergo.
>>
>
> Source encodings are *not* required to be able to support all of Unicode.
> And without escape characters and `\U`, I have no way to "transcode it into
> source encoding" because the source encoding *cannot support it*.  If I
> have a Unicode-encoded file under your rules, the only thing I can do is
> load it as binary. And thanks to cross-compiling, the executable
> environment may have a different endian than the source environment.
>

It's very rare to be cross-compiling from a build system that is less
powerful than the target system in this fashion.

Nevertheless, in such very rare cases the binary option I outlined works
fine.  You can compile-time configure the constexpr-programmed transcoding
to produce whatever execution encoding or endianness you want.


>
> Beyond these two options, I do not think futher built-in support for a
>> specific set of different source text encoding formats is necessary.
>>
>
> Internationalization is *not optional*. Nor is cross-compilation support.
>

The second option works for both internationalization and cross-compilation.


>
>
>>   I would like to be able to write a constexpr function f such that both
>> f(F"foo") and f(bF"foo") will work and properly get the range of bytes that
>> the two literals present.
>>
>
> ... why? Generally speaking, functions that process text and functions
> that process binary data are *different* functions. Unless your binary
> data actually is text, but that doesn't really make sense.
>
> Ultimately I would like this to work:
>>
>>    constexpr string_view sv = bF"foo";
>>
>
> Why? `string_view`, as the name suggests, is for *strings*. The class you
> want is called `span<unsigned char>`. That's how we spell "array of
> arbitrary bytes" in C++.
>

People use string_view to address ranges of "raw memory", and not just for
text.

span hasn't been standardized yet, and may never be.

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

--94eb2c12371232891705321a4bdb
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, May 5, 2016 at 5:26 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Wednesday, May 4, 2016 at 10:35:55 PM UTC-4, Andrew Tomazos wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>My=
 current design has two input formats.=C2=A0 Binary and text.=C2=A0 The tex=
t encoding format is the usual source encoding for your source files (the o=
verwhelming default these days is UTF-8).=C2=A0 If you have a text file in =
a different encoding, then you can transcode it into source encoding within=
 your source files. It will then undergo the usual source-to-execution tran=
scoding that the bodies of raw string literals undergo. </div></div></block=
quote></span><div><br>Source encodings are <i>not</i> required to be able t=
o support all of Unicode. And without escape characters and `\U`, I have no=
 way to &quot;transcode it into source encoding&quot; because the source en=
coding <i>cannot support it</i>.=C2=A0 If I have a Unicode-encoded file und=
er your rules, the only thing I can do is load it as binary. And thanks to =
cross-compiling, the executable environment may have a different endian tha=
n the source environment.<br></div></div></blockquote><div><br></div><div>I=
t&#39;s very rare to be cross-compiling from a build system that is less po=
werful than the target system in this fashion.</div><div><br></div><div>Nev=
ertheless, in such very rare cases the binary option I outlined works fine.=
=C2=A0 You can compile-time configure the constexpr-programmed transcoding =
to produce whatever execution encoding or endianness you want.</div><div>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></=
div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div></div><div>Beyond these two options, I do not think futher built-in=
 support for a specific set of different source text encoding formats is ne=
cessary.</div></div></blockquote></span><div><br>Internationalization is <i=
>not optional</i>. Nor is cross-compilation support.<br></div></div></block=
quote><div><br></div><div>The second option works for both internationaliza=
tion and cross-compilation.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div></div><span class=3D""><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0 I would like =
to be able to write a constexpr function f such that both f(F&quot;foo&quot=
;) and f(bF&quot;foo&quot;) will work and properly get the range of bytes t=
hat the two literals present.</div></div></blockquote></span><div><br>... w=
hy? Generally speaking, functions that process text and functions that proc=
ess binary data are <i>different</i> functions. Unless your binary data act=
ually is text, but that doesn&#39;t really make sense.<br><br></div><span c=
lass=3D""><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"><div></d=
iv><div>Ultimately I would like this to work:</div><div><br></div><div>=C2=
=A0 =C2=A0constexpr string_view sv =3D bF&quot;foo&quot;;</div></div></bloc=
kquote></span><div><br>Why? `string_view`, as the name suggests, is for <i>=
strings</i>. The class you want is called `span&lt;unsigned char&gt;`. That=
&#39;s how we spell &quot;array of arbitrary bytes&quot; in C++.</div></div=
></blockquote><div><br></div><div>People use string_view to address ranges =
of &quot;raw memory&quot;, and not just for text.</div><div><br></div><div>=
span hasn&#39;t been standardized yet, and may never be.</div><div><br></di=
v></div></div></div>

<p></p>

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

--94eb2c12371232891705321a4bdb--

.

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

On Thu, May 5, 2016 at 5:49 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, May 5, 2016 at 11:29:49 AM UTC-4, Matthew Woehlke wrote:
>>
>> On 2016-05-05 11:18, Tom Honermann wrote:
>> > On 5/5/2016 11:15 AM, Matthew Woehlke wrote:
>> >> On 2016-05-05 11:01, Tom Honermann wrote:
>> >>> On 5/5/2016 10:52 AM, Matthew Woehlke wrote:
>> >>>> Personally, I'd prefer if the source (if text) is required to be in
>> >>>> Unicode with a BOM...
>> >>> Please, no.  On non-ASCII based systems, forcing Unicode would be a
>> >>> significant burden to users.
>> >> Uh, you *do* realize that ASCII is a subset of UTF-8, yes? Requiring
>> >> input files to be Unicode with BOM (no BOM =E2=86=92 UTF-8) would be =
fully
>> >> compatible with ASCII-conforming input files.
>> >>
>> > I said on *non*-ASCII based systems.
>>
>> Ah, sorry, misread :-).
>
>
>>
> But in that case, Andrew's suggestion (just read
>> it as source encoding, and if you need something else, "too bad"=C2=B9)
>> works. I'm more inclined to that anyway.
>>
>
> It's silly to give up now that we're so close to a functional design. You
> pointed out that you can identify Unicode-encoded files by their BOMs. So
> instead of the giant number of sources, we actually only have:
>
> - Source character set
> - Unicode, in a format as identified by BOMs
> - Binary
>
> `F` would mean source character set. `Fb` would mean binary. And `Fu`
> would mean Unicode, as identified by BOMs. You can still apply the encodi=
ng
> prefixes to the non-binary forms, and indeed you *must* provide one for
> `Fu`. For example:
>
> - u8F: Read source character set, convert to UTF-8.
> - uFu: Read Unicode text, convert to UTF-16.
>
> And so forth.
>
> `Fu` would specifically mean:
>
> - Platform-specific text translation (new-lines and so forth).
> - BOM to identify the source Unicode encoding and endian. Lack of BOM
> automatically means UTF-8, but the UTF-8 BOM will also mean UTF-8. BOM is
> stripped out.
> - NUL-terminated.
>
> The encoding prefix allows cross-Unicode conversion. So if you have a
> UTF-16 text file and you want to store it as UTF-8, you use `u8Fu`.
>
> It's a simple and elegant solution to the source encoding problem.
>
>
>> (=C2=B9 Use compile-time text processing for this case if you simply *mu=
st*
>> have it.)
>>
>
> The problem with that is that you are assuming that Unicode-encoded files
> represent a minor province of what people do.
>

That's not the claim.  The claim is that the number of people using both an
unusual source encoding and a Unicode execution encoding is very small.  I
think that is correct.

That given, supporting that small (or perhaps even nonexistant) group with
the DIY constexpr/binary option, seems more reasonable than introducing the
complexity of multi-source-encoding into the feature.

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

--94eb2c096b7a61694e05321a9402
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, May 5, 2016 at 5:49 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Thursday, May 5, 2016 at 11:29:49 AM UTC-4, Matthew Woehlke wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">On 2016-05-05 11:18, Tom Honermann =
wrote:
<br>&gt; On 5/5/2016 11:15 AM, Matthew Woehlke wrote:
<br>&gt;&gt; On 2016-05-05 11:01, Tom Honermann wrote:
<br>&gt;&gt;&gt; On 5/5/2016 10:52 AM, Matthew Woehlke wrote:
<br>&gt;&gt;&gt;&gt; Personally, I&#39;d prefer if the source (if text) is =
required to be in
<br>&gt;&gt;&gt;&gt; Unicode with a BOM...
<br>&gt;&gt;&gt; Please, no.=C2=A0 On non-ASCII based systems, forcing Unic=
ode would be a
<br>&gt;&gt;&gt; significant burden to users.
<br>&gt;&gt; Uh, you *do* realize that ASCII is a subset of UTF-8, yes? Req=
uiring
<br>&gt;&gt; input files to be Unicode with BOM (no BOM =E2=86=92 UTF-8) wo=
uld be fully
<br>&gt;&gt; compatible with ASCII-conforming input files.
<br>&gt;&gt;
<br>&gt; I said on *non*-ASCII based systems.
<br>
<br>Ah, sorry, misread :-).</blockquote><blockquote style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=
=3D"gmail_quote"><div>=C2=A0</div></blockquote><div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">But in that case, Andrew&#39;s suggestion (just read
<br>it as source encoding, and if you need something else, &quot;too bad&qu=
ot;=C2=B9)
<br>works. I&#39;m more inclined to that anyway.<br></blockquote></span><di=
v><br>It&#39;s silly to give up now that we&#39;re so close to a functional=
 design. You pointed out that you can identify Unicode-encoded files by the=
ir BOMs. So instead of the giant number of sources, we actually only have:<=
br><br>- Source character set<br>- Unicode, in a format as identified by BO=
Ms<br>- Binary<br><br>`F` would mean source character set. `Fb` would mean =
binary. And `Fu` would mean Unicode, as identified by BOMs. You can still a=
pply the encoding prefixes to the non-binary forms, and indeed you <i>must<=
/i> provide one for `Fu`. For example:<br><br>- u8F: Read source character =
set, convert to UTF-8.<br>- uFu: Read Unicode text, convert to UTF-16.<br><=
br>And so forth.<br><br>`Fu` would specifically mean:<br><br>- Platform-spe=
cific text translation (new-lines and so forth).<br>- BOM to identify the s=
ource Unicode encoding and endian. Lack of BOM automatically means UTF-8, b=
ut the UTF-8 BOM will also mean UTF-8. BOM is stripped out.<br>- NUL-termin=
ated.<br><br>The encoding prefix allows cross-Unicode conversion. So if you=
 have a UTF-16 text file and you want to store it as UTF-8, you use `u8Fu`.=
<br><br>It&#39;s a simple and elegant solution to the source encoding probl=
em.<br><br></div><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<br>(=C2=B9 Use compile-time text processing for this case if you simply *m=
ust*
<br>have it.)
<br></blockquote></span><div><br>The problem with that is that you are assu=
ming that Unicode-encoded files represent a minor province of what people d=
o.</div></div></blockquote><div><br></div><div>That&#39;s not the claim.=C2=
=A0 The claim is that the number of people using both an unusual source enc=
oding and a Unicode execution encoding is very small.=C2=A0 I think that is=
 correct.</div><div><br></div><div>That given, supporting that small (or pe=
rhaps even nonexistant) group with the DIY constexpr/binary option, seems m=
ore reasonable than introducing the complexity of multi-source-encoding int=
o the feature.</div><div><br></div></div></div></div>

<p></p>

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

--94eb2c096b7a61694e05321a9402--

.

------=_Part_613_471297678.1462465029246
Content-Type: multipart/alternative;
 boundary="----=_Part_614_919351455.1462465029246"

------=_Part_614_919351455.1462465029246
Content-Type: text/plain; charset=UTF-8



On Thursday, May 5, 2016 at 11:49:57 AM UTC-4, Andrew Tomazos wrote:
>
> On Thu, May 5, 2016 at 5:26 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Wednesday, May 4, 2016 at 10:35:55 PM UTC-4, Andrew Tomazos wrote:
>>>
>>> My current design has two input formats.  Binary and text.  The text
>>> encoding format is the usual source encoding for your source files (the
>>> overwhelming default these days is UTF-8).  If you have a text file in a
>>> different encoding, then you can transcode it into source encoding within
>>> your source files. It will then undergo the usual source-to-execution
>>> transcoding that the bodies of raw string literals undergo.
>>>
>>
>> Source encodings are *not* required to be able to support all of
>> Unicode. And without escape characters and `\U`, I have no way to
>> "transcode it into source encoding" because the source encoding *cannot
>> support it*.  If I have a Unicode-encoded file under your rules, the
>> only thing I can do is load it as binary. And thanks to cross-compiling,
>> the executable environment may have a different endian than the source
>> environment.
>>
>
> It's very rare to be cross-compiling from a build system that is less
> powerful than the target system in this fashion.
>

Endian-ness has nothing to do with "power". If I'm on a desktop machine
(little-endian), and I'm compiling for Android (usually big-endian), that's
a problem.

And such cross-compilation is not exactly "rare" these days either.

Ultimately I would like this to work:
>>
>>    constexpr string_view sv = bF"foo";
>>
>
> Why? `string_view`, as the name suggests, is for *strings*. The class you
> want is called `span<unsigned char>`. That's how we spell "array of
> arbitrary bytes" in C++.
>
> People use string_view to address ranges of "raw memory", and not just for
> text.
>

No, people using string_view for that because `span<unsigned char>` is not
available to them.

We should not *encourage* the continued abuse of such types.

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

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

<div dir=3D"ltr"><br><br>On Thursday, May 5, 2016 at 11:49:57 AM UTC-4, And=
rew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote">On Thu, May 5, 2016 at 5:26 PM, Nicol =
Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"wTcwxr50BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><span>On Wednesday, May 4, 2016 at 1=
0:35:55 PM UTC-4, Andrew Tomazos wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div></div><div>My current design has two input format=
s.=C2=A0 Binary and text.=C2=A0 The text encoding format is the usual sourc=
e encoding for your source files (the overwhelming default these days is UT=
F-8).=C2=A0 If you have a text file in a different encoding, then you can t=
ranscode it into source encoding within your source files. It will then und=
ergo the usual source-to-execution transcoding that the bodies of raw strin=
g literals undergo. </div></div></blockquote></span><div><br>Source encodin=
gs are <i>not</i> required to be able to support all of Unicode. And withou=
t escape characters and `\U`, I have no way to &quot;transcode it into sour=
ce encoding&quot; because the source encoding <i>cannot support it</i>.=C2=
=A0 If I have a Unicode-encoded file under your rules, the only thing I can=
 do is load it as binary. And thanks to cross-compiling, the executable env=
ironment may have a different endian than the source environment.<br></div>=
</div></blockquote><div><br></div><div>It&#39;s very rare to be cross-compi=
ling from a build system that is less powerful than the target system in th=
is fashion.</div></div></div></div></blockquote><div><br>Endian-ness has no=
thing to do with &quot;power&quot;. If I&#39;m on a desktop machine (little=
-endian), and I&#39;m compiling for Android (usually big-endian), that&#39;=
s a problem.<br><br>And such cross-compilation is not exactly &quot;rare&qu=
ot; these days either.<br><br></div><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"><div><div class=3D"gmail_quote"><div dir=3D"ltr"><di=
v></div><span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>Ultimately I would like this to work:</div><div><br></div><div>=C2=A0 =C2=
=A0constexpr string_view sv =3D bF&quot;foo&quot;;</div></div></blockquote>=
</span><div><br>Why? `string_view`, as the name suggests, is for <i>strings=
</i>. The class you want is called `span&lt;unsigned char&gt;`. That&#39;s =
how we spell &quot;array of arbitrary bytes&quot; in C++.</div></div><div><=
br></div><div>People use string_view to address ranges of &quot;raw memory&=
quot;, and not just for text.</div></div></div></div></blockquote><div><br>=
No, people using string_view for that because `span&lt;unsigned char&gt;` i=
s not available to them.<br><br>We should not <i>encourage</i> the continue=
d abuse of such types.</div></div>

<p></p>

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

------=_Part_614_919351455.1462465029246--
------=_Part_613_471297678.1462465029246--

.

------=_Part_1848_492565448.1462465337949
Content-Type: multipart/alternative;
 boundary="----=_Part_1849_823301353.1462465337949"

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

On Thursday, May 5, 2016 at 12:10:25 PM UTC-4, Andrew Tomazos wrote:
>
> On Thu, May 5, 2016 at 5:49 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> It's silly to give up now that we're so close to a functional design. Yo=
u=20
>> pointed out that you can identify Unicode-encoded files by their BOMs. S=
o=20
>> instead of the giant number of sources, we actually only have:
>>
>> - Source character set
>> - Unicode, in a format as identified by BOMs
>> - Binary
>>
>> `F` would mean source character set. `Fb` would mean binary. And `Fu`=20
>> would mean Unicode, as identified by BOMs. You can still apply the encod=
ing=20
>> prefixes to the non-binary forms, and indeed you *must* provide one for=
=20
>> `Fu`. For example:
>>
>> - u8F: Read source character set, convert to UTF-8.
>> - uFu: Read Unicode text, convert to UTF-16.
>>
>> And so forth.
>>
>> `Fu` would specifically mean:
>>
>> - Platform-specific text translation (new-lines and so forth).
>> - BOM to identify the source Unicode encoding and endian. Lack of BOM=20
>> automatically means UTF-8, but the UTF-8 BOM will also mean UTF-8. BOM i=
s=20
>> stripped out.
>> - NUL-terminated.
>>
>> The encoding prefix allows cross-Unicode conversion. So if you have a=20
>> UTF-16 text file and you want to store it as UTF-8, you use `u8Fu`.
>>
>> It's a simple and elegant solution to the source encoding problem.
>>
>>
>>> (=C2=B9 Use compile-time text processing for this case if you simply *m=
ust*=20
>>> have it.)=20
>>>
>>
>> The problem with that is that you are assuming that Unicode-encoded file=
s=20
>> represent a minor province of what people do.
>>
>
> That's not the claim.  The claim is that the number of people using both=
=20
> an unusual source encoding and a Unicode execution encoding is very small=
.. =20
> I think that is correct.
>

What is "an unusual source encoding?" Unicode is not "unusual".

That given, supporting that small (or perhaps even nonexistant) group with=
=20
> the DIY constexpr/binary option, seems more reasonable than introducing t=
he=20
> complexity of multi-source-encoding into the feature.
>

Given that we have no evidence that "DIY constexpr/binary option" is even=
=20
*possible* (for example, how do you detect what endian your execution=20
environment is?) I see no reason to ignore such use cases.

Also, what "complexity" are we talking about? I added a single suffix to=20
`F`. That's not exactly complex.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5e0f5d02-9ab6-4464-9df4-f783130594a0%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, May 5, 2016 at 12:10:25 PM UTC-4, Andrew Toma=
zos wrote:<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"><di=
v><div class=3D"gmail_quote">On Thu, May 5, 2016 at 5:49 PM, Nicol Bolas <s=
pan dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"Biku09x1BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>It&#39;s silly to give up now that we&#=
39;re so close to a functional design. You pointed out that you can identif=
y Unicode-encoded files by their BOMs. So instead of the giant number of so=
urces, we actually only have:<br><br>- Source character set<br>- Unicode, i=
n a format as identified by BOMs<br>- Binary<br><br>`F` would mean source c=
haracter set. `Fb` would mean binary. And `Fu` would mean Unicode, as ident=
ified by BOMs. You can still apply the encoding prefixes to the non-binary =
forms, and indeed you <i>must</i> provide one for `Fu`. For example:<br><br=
>- u8F: Read source character set, convert to UTF-8.<br>- uFu: Read Unicode=
 text, convert to UTF-16.<br><br>And so forth.<br><br>`Fu` would specifical=
ly mean:<br><br>- Platform-specific text translation (new-lines and so fort=
h).<br>- BOM to identify the source Unicode encoding and endian. Lack of BO=
M automatically means UTF-8, but the UTF-8 BOM will also mean UTF-8. BOM is=
 stripped out.<br>- NUL-terminated.<br><br>The encoding prefix allows cross=
-Unicode conversion. So if you have a UTF-16 text file and you want to stor=
e it as UTF-8, you use `u8Fu`.<br><br>It&#39;s a simple and elegant solutio=
n to the source encoding problem.<br><br></div><span><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<br>(=C2=B9 Use compile-time text processing for this case if you simply *m=
ust*
<br>have it.)
<br></blockquote></span><div><br>The problem with that is that you are assu=
ming that Unicode-encoded files represent a minor province of what people d=
o.</div></div></blockquote><div><br></div><div>That&#39;s not the claim.=C2=
=A0 The claim is that the number of people using both an unusual source enc=
oding and a Unicode execution encoding is very small.=C2=A0 I think that is=
 correct.</div></div></div></div></blockquote><div><br>What is &quot;an unu=
sual source encoding?&quot; Unicode is not &quot;unusual&quot;.<br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div></div><div>That given, supporting that small (or =
perhaps even nonexistant) group with the DIY constexpr/binary option, seems=
 more reasonable than introducing the complexity of multi-source-encoding i=
nto the feature.</div></div></div></div></blockquote><div><br>Given that we=
 have no evidence that &quot;DIY constexpr/binary option&quot; is even <i>p=
ossible</i> (for example, how do you detect what endian your execution envi=
ronment is?) I see no reason to ignore such use cases.<br><br>Also, what &q=
uot;complexity&quot; are we talking about? I added a single suffix to `F`. =
That&#39;s not exactly complex. </div></div>

<p></p>

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

------=_Part_1849_823301353.1462465337949--
------=_Part_1848_492565448.1462465337949--

.

On quinta-feira, 5 de maio de 2016 08:26:35 PDT Nicol Bolas wrote:
> If I
> have a Unicode-encoded file under your rules, the only thing I can do is
> load it as binary. And thanks to cross-compiling, the executable
> environment may have a different endian than the source environment.

If we add this feature to the language, then you must be able to do a
constexpr byte-swapping of the entire contents and reverse the endianness to
the native of your target platform.

Let me emphasise: you MUST be able to. This kind of constexpr transformation
is a requirement of the feature. If it is not possible to do it, if instead we
have to rely on other tools to do the transformation before the compiler is
run, then we don't need this feature at all.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

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

On Thu, May 5, 2016 at 6:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, May 5, 2016 at 12:10:25 PM UTC-4, Andrew Tomazos wrote:
>>
>> On Thu, May 5, 2016 at 5:49 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> It's silly to give up now that we're so close to a functional design.
>>> You pointed out that you can identify Unicode-encoded files by their BO=
Ms.
>>> So instead of the giant number of sources, we actually only have:
>>>
>>> - Source character set
>>> - Unicode, in a format as identified by BOMs
>>> - Binary
>>>
>>> `F` would mean source character set. `Fb` would mean binary. And `Fu`
>>> would mean Unicode, as identified by BOMs. You can still apply the enco=
ding
>>> prefixes to the non-binary forms, and indeed you *must* provide one for
>>> `Fu`. For example:
>>>
>>> - u8F: Read source character set, convert to UTF-8.
>>> - uFu: Read Unicode text, convert to UTF-16.
>>>
>>> And so forth.
>>>
>>> `Fu` would specifically mean:
>>>
>>> - Platform-specific text translation (new-lines and so forth).
>>> - BOM to identify the source Unicode encoding and endian. Lack of BOM
>>> automatically means UTF-8, but the UTF-8 BOM will also mean UTF-8. BOM =
is
>>> stripped out.
>>> - NUL-terminated.
>>>
>>> The encoding prefix allows cross-Unicode conversion. So if you have a
>>> UTF-16 text file and you want to store it as UTF-8, you use `u8Fu`.
>>>
>>> It's a simple and elegant solution to the source encoding problem.
>>>
>>>
>>>> (=C2=B9 Use compile-time text processing for this case if you simply *=
must*
>>>> have it.)
>>>>
>>>
>>> The problem with that is that you are assuming that Unicode-encoded
>>> files represent a minor province of what people do.
>>>
>>
>> That's not the claim.  The claim is that the number of people using both
>> an unusual source encoding and a Unicode execution encoding is very smal=
l.
>> I think that is correct.
>>
>
> What is "an unusual source encoding?" Unicode is not "unusual".
>

One that "cannot support all of Unicode".  Yes, of course Unicode is not
unusual - it is the norm these days.

In order to not be able to use my first solution (that is manually
transcode your source file for the text file literal into source encoding
before checking it in with your source files), the source encoding must be
unusual.

That given, supporting that small (or perhaps even nonexistant) group with
>> the DIY constexpr/binary option, seems more reasonable than introducing =
the
>> complexity of multi-source-encoding into the feature.
>>
>
> Given that we have no evidence that "DIY constexpr/binary option" is even
> *possible *(for example, how do you detect what endian your execution
> environment is?) I see no reason to ignore such use cases.
>

It works fine.  I've done much more complicated things with constexpr
programming than transcoding some text.

As for "detecting the endianness" of your execution environment, you can
either get it from your compiler predefined macros / intrinsics (if
available) or specify it explicitly as part of your build configuration
(setting for example a macro or constexpr variable).  It's not a big deal.


> Also, what "complexity" are we talking about? I added a single suffix to
> `F`. That's not exactly complex.
>
> It increases the number of encoding prefixes quadratically for everyone -
to solve what seems to be a small problem for which there are adequate
simpler solutions.

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

--001a11c16614da969d05321b04cf
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, May 5, 2016 at 6:22 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@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">On Th=
ursday, May 5, 2016 at 12:10:25 PM UTC-4, Andrew Tomazos wrote:<span class=
=3D""><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"><div><div cl=
ass=3D"gmail_quote">On Thu, May 5, 2016 at 5:49 PM, Nicol Bolas <span dir=
=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It&#39;s silly to giv=
e up now that we&#39;re so close to a functional design. You pointed out th=
at you can identify Unicode-encoded files by their BOMs. So instead of the =
giant number of sources, we actually only have:<br><br>- Source character s=
et<br>- Unicode, in a format as identified by BOMs<br>- Binary<br><br>`F` w=
ould mean source character set. `Fb` would mean binary. And `Fu` would mean=
 Unicode, as identified by BOMs. You can still apply the encoding prefixes =
to the non-binary forms, and indeed you <i>must</i> provide one for `Fu`. F=
or example:<br><br>- u8F: Read source character set, convert to UTF-8.<br>-=
 uFu: Read Unicode text, convert to UTF-16.<br><br>And so forth.<br><br>`Fu=
` would specifically mean:<br><br>- Platform-specific text translation (new=
-lines and so forth).<br>- BOM to identify the source Unicode encoding and =
endian. Lack of BOM automatically means UTF-8, but the UTF-8 BOM will also =
mean UTF-8. BOM is stripped out.<br>- NUL-terminated.<br><br>The encoding p=
refix allows cross-Unicode conversion. So if you have a UTF-16 text file an=
d you want to store it as UTF-8, you use `u8Fu`.<br><br>It&#39;s a simple a=
nd elegant solution to the source encoding problem.<br><br></div><span><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<br>(=C2=B9 Use compile-time text processing for this case if you simply *m=
ust*
<br>have it.)
<br></blockquote></span><div><br>The problem with that is that you are assu=
ming that Unicode-encoded files represent a minor province of what people d=
o.</div></div></blockquote><div><br></div><div>That&#39;s not the claim.=C2=
=A0 The claim is that the number of people using both an unusual source enc=
oding and a Unicode execution encoding is very small.=C2=A0 I think that is=
 correct.</div></div></div></div></blockquote></span><div><br>What is &quot=
;an unusual source encoding?&quot; Unicode is not &quot;unusual&quot;.<br><=
/div></div></blockquote><div><br></div><div>One that &quot;cannot support a=
ll of Unicode&quot;.=C2=A0 Yes, of course Unicode is not unusual - it is th=
e norm these days.</div><div><br></div><div>In order to not be able to use =
my first solution (that is manually transcode your source file for the text=
 file literal into source encoding before checking it in with your source f=
iles), the source encoding must be unusual.</div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><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"><div><div class=3D"gmail_quote"><div></=
div><div>That given, supporting that small (or perhaps even nonexistant) gr=
oup with the DIY constexpr/binary option, seems more reasonable than introd=
ucing the complexity of multi-source-encoding into the feature.</div></div>=
</div></div></blockquote></span><div><br>Given that we have no evidence tha=
t &quot;DIY constexpr/binary option&quot; is even <i>possible=C2=A0</i>(for=
 example, how do you detect what endian your execution environment is?) I s=
ee no reason to ignore such use cases.</div></div></blockquote><div><br></d=
iv><div>It works fine.=C2=A0 I&#39;ve done much more complicated things wit=
h constexpr programming than transcoding some text.</div><div><br></div><di=
v>As for &quot;detecting the endianness&quot; of your execution environment=
, you can either get it from your compiler predefined macros / intrinsics (=
if available) or specify it explicitly as part of your build configuration =
(setting for example a macro or constexpr variable).=C2=A0 It&#39;s not a b=
ig deal.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>Also, what &quot;complexity&quot; are we talking about? I added a =
single suffix to `F`. That&#39;s not exactly complex. </div></div><span cla=
ss=3D"">

<p></p></span></blockquote></div>It increases the number of encoding prefix=
es quadratically for everyone - to solve what seems to be a small problem f=
or which there are adequate simpler solutions.</div><div class=3D"gmail_ext=
ra"><br></div></div>

<p></p>

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

--001a11c16614da969d05321b04cf--

.

On 2016-05-05 11:49, Nicol Bolas wrote:
> On Thursday, May 5, 2016 at 11:29:49 AM UTC-4, Matthew Woehlke wrote:
>> (=C2=B9 Use compile-time text processing for this case if you simply *mu=
st*=20
>> have it.)=20
>=20
> The problem with that is that you are assuming that Unicode-encoded files=
=20
> represent a minor province of what people do. I disagree. "Must have it" =
is=20
> something that a *lot* of people will need.

Rather, I expect that most people will only need to read source
character set. (Bearing in mind that for many people, "source character
set" is already UTF-8...)

Also, I'm thinking more of esoteric cases where the input and/or output
are not Unicode.

Having three input modes (source character set, auto-detected flavor of
unicode, binary / no translation) seems sane, and allows explicit
support for e.g. reading UTF-16 with arbitrary endianness into the
correct run-time representation. This is not much of an addition from
only two modes (SCS, binary).

--=20
Matthew

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

.

------=_Part_446_695528102.1462470529617
Content-Type: multipart/alternative;
 boundary="----=_Part_447_1704906768.1462470529617"

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

On Thursday, May 5, 2016 at 12:41:52 PM UTC-4, Andrew Tomazos wrote:
>
> On Thu, May 5, 2016 at 6:22 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Thursday, May 5, 2016 at 12:10:25 PM UTC-4, Andrew Tomazos wrote:
>>>
>>> On Thu, May 5, 2016 at 5:49 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> It's silly to give up now that we're so close to a functional design.=
=20
>>>> You pointed out that you can identify Unicode-encoded files by their B=
OMs.=20
>>>> So instead of the giant number of sources, we actually only have:
>>>>
>>>> - Source character set
>>>> - Unicode, in a format as identified by BOMs
>>>> - Binary
>>>>
>>>> `F` would mean source character set. `Fb` would mean binary. And `Fu`=
=20
>>>> would mean Unicode, as identified by BOMs. You can still apply the enc=
oding=20
>>>> prefixes to the non-binary forms, and indeed you *must* provide one=20
>>>> for `Fu`. For example:
>>>>
>>>> - u8F: Read source character set, convert to UTF-8.
>>>> - uFu: Read Unicode text, convert to UTF-16.
>>>>
>>>> And so forth.
>>>>
>>>> `Fu` would specifically mean:
>>>>
>>>> - Platform-specific text translation (new-lines and so forth).
>>>> - BOM to identify the source Unicode encoding and endian. Lack of BOM=
=20
>>>> automatically means UTF-8, but the UTF-8 BOM will also mean UTF-8. BOM=
 is=20
>>>> stripped out.
>>>> - NUL-terminated.
>>>>
>>>> The encoding prefix allows cross-Unicode conversion. So if you have a=
=20
>>>> UTF-16 text file and you want to store it as UTF-8, you use `u8Fu`.
>>>>
>>>> It's a simple and elegant solution to the source encoding problem.
>>>>
>>>>
>>>>> (=C2=B9 Use compile-time text processing for this case if you simply =
*must*=20
>>>>> have it.)=20
>>>>>
>>>>
>>>> The problem with that is that you are assuming that Unicode-encoded=20
>>>> files represent a minor province of what people do.
>>>>
>>>
>>> That's not the claim.  The claim is that the number of people using bot=
h=20
>>> an unusual source encoding and a Unicode execution encoding is very sma=
ll. =20
>>> I think that is correct.
>>>
>>
>> What is "an unusual source encoding?" Unicode is not "unusual".
>>
>
> One that "cannot support all of Unicode".  Yes, of course Unicode is not=
=20
> unusual - it is the norm these days.
>
> In order to not be able to use my first solution (that is manually=20
> transcode your source file for the text file literal into source encoding=
=20
> before checking it in with your source files)
>

Wait a second, I just realized something.

The whole point of file inclusions is to *avoid* "manually transcoding your=
=20
source file", right? After all, if you're going to do that, if you have=20
integrated such transcoding into the build process... why not just go all=
=20
the way to an actual C++ source file? If your source character set can=20
actual handle this, just turn the file into an actual RAW string literal or=
=20
whatever and just #include it.

So you seem to have undermined the very purpose of your own proposal. Why=
=20
should some users have to "manually transcode" their text files while other=
=20
users don't?
=20

> , the source encoding must be unusual.
>

ASCII is not "unusual" for a source character set. The default source=20
character set for quite a few compilers does not natively handle embedded=
=20
Unicode characters.

That given, supporting that small (or perhaps even nonexistant) group with=
=20
>>> the DIY constexpr/binary option, seems more reasonable than introducing=
 the=20
>>> complexity of multi-source-encoding into the feature.
>>>
>>
>> Given that we have no evidence that "DIY constexpr/binary option" is eve=
n=20
>> *possible *(for example, how do you detect what endian your execution=20
>> environment is?) I see no reason to ignore such use cases.
>>
>
> It works fine.  I've done much more complicated things with constexpr=20
> programming than transcoding some text.=20
>
=20
>
As for "detecting the endianness" of your execution environment, you can=20
> either get it from your compiler predefined macros / intrinsics (if=20
> available) or specify it explicitly as part of your build configuration=
=20
> (setting for example a macro or constexpr variable).  It's not a big deal=
..
>

So it's not something you can put in the standard library. It's a thing=20
everyone has to write individually.

I fail to see why adding a simple source encoding suffix is a worse=20
alternative.
=20

> Also, what "complexity" are we talking about? I added a single suffix to=
=20
>> `F`. That's not exactly complex.=20
>>
>> It increases the number of encoding prefixes quadratically for everyone =
-=20
> to solve what seems to be a small problem for which there are adequate=20
> simpler solutions.
>

Please look at the actual design I posted. It doesn't increase the number=
=20
of encoding prefixes *at all*. It adds a different *loading* prefix. `F`=20
for source character set, `Fb` for binary, and `Fu` for Unicode. None of=20
those are prefixes.

There is no quadratic increase of anything.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f9d035ab-0ceb-440f-b1c5-2ea2c4c64140%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, May 5, 2016 at 12:41:52 PM UTC-4, Andrew Toma=
zos wrote:<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"><di=
v><div class=3D"gmail_quote">On Thu, May 5, 2016 at 6:22 PM, Nicol Bolas <s=
pan dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"l_kSEJR3BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">On Thursday, May 5, 2016 at 12:10:25 PM UTC-=
4, Andrew Tomazos wrote:<span><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, May 5, 2016 at 5:49 PM,=
 Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@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"><div=
>It&#39;s silly to give up now that we&#39;re so close to a functional desi=
gn. You pointed out that you can identify Unicode-encoded files by their BO=
Ms. So instead of the giant number of sources, we actually only have:<br><b=
r>- Source character set<br>- Unicode, in a format as identified by BOMs<br=
>- Binary<br><br>`F` would mean source character set. `Fb` would mean binar=
y. And `Fu` would mean Unicode, as identified by BOMs. You can still apply =
the encoding prefixes to the non-binary forms, and indeed you <i>must</i> p=
rovide one for `Fu`. For example:<br><br>- u8F: Read source character set, =
convert to UTF-8.<br>- uFu: Read Unicode text, convert to UTF-16.<br><br>An=
d so forth.<br><br>`Fu` would specifically mean:<br><br>- Platform-specific=
 text translation (new-lines and so forth).<br>- BOM to identify the source=
 Unicode encoding and endian. Lack of BOM automatically means UTF-8, but th=
e UTF-8 BOM will also mean UTF-8. BOM is stripped out.<br>- NUL-terminated.=
<br><br>The encoding prefix allows cross-Unicode conversion. So if you have=
 a UTF-16 text file and you want to store it as UTF-8, you use `u8Fu`.<br><=
br>It&#39;s a simple and elegant solution to the source encoding problem.<b=
r><br></div><span><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>(=C2=B9 Use compile-time text processing for this case if you simply *m=
ust*
<br>have it.)
<br></blockquote></span><div><br>The problem with that is that you are assu=
ming that Unicode-encoded files represent a minor province of what people d=
o.</div></div></blockquote><div><br></div><div>That&#39;s not the claim.=C2=
=A0 The claim is that the number of people using both an unusual source enc=
oding and a Unicode execution encoding is very small.=C2=A0 I think that is=
 correct.</div></div></div></div></blockquote></span><div><br>What is &quot=
;an unusual source encoding?&quot; Unicode is not &quot;unusual&quot;.<br><=
/div></div></blockquote><div><br></div><div>One that &quot;cannot support a=
ll of Unicode&quot;.=C2=A0 Yes, of course Unicode is not unusual - it is th=
e norm these days.</div><div><br></div><div>In order to not be able to use =
my first solution (that is manually transcode your source file for the text=
 file literal into source encoding before checking it in with your source f=
iles)</div></div></div></div></blockquote><div><br>Wait a second, I just re=
alized something.<br><br>The whole point of file inclusions is to <i>avoid<=
/i> &quot;manually transcoding your source file&quot;, right? After all, if=
 you&#39;re going to do that, if you have integrated such transcoding into =
the build process... why not just go all the way to an actual C++ source fi=
le? If your source character set can actual handle this, just turn the file=
 into an actual RAW string literal or whatever and just #include it.<br><br=
>So you seem to have undermined the very purpose of your own proposal. Why =
should some users have to &quot;manually transcode&quot; their text files w=
hile other users don&#39;t?<br>=C2=A0</div><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"><div><div class=3D"gmail_quote"><div>, the so=
urce encoding must be unusual.</div></div></div></div></blockquote><div><br=
>ASCII is not &quot;unusual&quot; for a source character set. The default s=
ource character set for quite a few compilers does not natively handle embe=
dded Unicode characters.<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><di=
v>That given, supporting that small (or perhaps even nonexistant) group wit=
h the DIY constexpr/binary option, seems more reasonable than introducing t=
he complexity of multi-source-encoding into the feature.</div></div></div><=
/div></blockquote></span><div><br>Given that we have no evidence that &quot=
;DIY constexpr/binary option&quot; is even <i>possible=C2=A0</i>(for exampl=
e, how do you detect what endian your execution environment is?) I see no r=
eason to ignore such use cases.</div></div></blockquote><div><br></div><div=
>It works fine.=C2=A0 I&#39;ve done much more complicated things with const=
expr programming than transcoding some text. <br></div></div></div></div></=
blockquote><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"><d=
iv><div class=3D"gmail_quote"><div>=C2=A0</div></div></div></div></blockquo=
te><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"><div><div =
class=3D"gmail_quote"><div>As for &quot;detecting the endianness&quot; of y=
our execution environment, you can either get it from your compiler predefi=
ned macros / intrinsics (if available) or specify it explicitly as part of =
your build configuration (setting for example a macro or constexpr variable=
).=C2=A0 It&#39;s not a big deal.</div></div></div></div></blockquote><div>=
<br>So it&#39;s not something you can put in the standard library. It&#39;s=
 a thing everyone has to write individually.<br><br>I fail to see why addin=
g a simple source encoding suffix is a worse alternative.<br>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>Also, what &quot;complexity&quot; are we talking about? I added a sin=
gle suffix to `F`. That&#39;s not exactly complex. </div></div><span>

<p></p></span></blockquote></div>It increases the number of encoding prefix=
es quadratically for everyone - to solve what seems to be a small problem f=
or which there are adequate simpler solutions.</div></div></blockquote><div=
><br>Please look at the actual design I posted. It doesn&#39;t increase the=
 number of encoding prefixes <i>at all</i>. It adds a different <i>loading<=
/i> prefix. `F` for source character set, `Fb` for binary, and `Fu` for Uni=
code. None of those are prefixes.<br><br>There is no quadratic increase of =
anything.<br></div></div>

<p></p>

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

------=_Part_447_1704906768.1462470529617--
------=_Part_446_695528102.1462470529617--

.

On 2016-05-05 12:41, Andrew Tomazos wrote:
> On Thu, May 5, 2016 at 6:22 PM, Nicol Bolas wrote:
>> Also, what "complexity" are we talking about? I added a single suffix to
>> `F`. That's not exactly complex.
>
> It increases the number of encoding prefixes quadratically for everyone -
> to solve what seems to be a small problem for which there are adequate
> simpler solutions.

I'm not convinced that's true. Yes, the *possible combinations* increase
geometrically, but the actual complexity increase can be linear=C2=B9, as t=
he
input and output / run-time encoding are orthogonal.

First, let's set aside binary mode. I don't think it makes sense to even
permit transcoding of binary, e.g. `uFb` would be illegal. So we have a
prefix of the form `<out>F<in>`, where `<out>` is any of the usual `u`,
`u8`, ``, etc. and `<in>` is `u` or ``.

Now, except for the case of source encoding =3D=3D run-time encoding, the
compiler *already* needs to be able to transcode=C2=B2, and can do so by
converting the input text into One True Format (probably some form of
Unicode), which is then converted into the requested output format. The
point is, these steps are *separable*, so adding additional input
formats is O(n), not O(n=C2=B2).

For `<out>Fu`, the compiler reads the file, transcodes the text into an
internal representation (also normalizing line endings), then transcodes
the intermediary result into the requested run-time format.

(=C2=B9 Compilers *may*, but are not *required*, to implement direct
transcoding paths without using an intermediary "universal" encoding.
But see also next note.)

(=C2=B2 ...and if the compiler doesn't do its own transcoding, almost
certainly it is using a library that already handles arbitrary in and
out encodings.)

Do we need this? I'm inclined to think "yes". Given a modern compiler
with UTF-8 source encoding, 1) transcoding is already implemented for
wide Unicode strings and 2) it's not *that* unreasonable to want this
feature for UTF-16 input files.

--=20
Matthew

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

.

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

On Thu, May 5, 2016 at 7:48 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, May 5, 2016 at 12:41:52 PM UTC-4, Andrew Tomazos wrote:
>>
>> On Thu, May 5, 2016 at 6:22 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Thursday, May 5, 2016 at 12:10:25 PM UTC-4, Andrew Tomazos wrote:
>>>>
>>>> On Thu, May 5, 2016 at 5:49 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>>
>>>>> It's silly to give up now that we're so close to a functional design.
>>>>> You pointed out that you can identify Unicode-encoded files by their =
BOMs.
>>>>> So instead of the giant number of sources, we actually only have:
>>>>>
>>>>> - Source character set
>>>>> - Unicode, in a format as identified by BOMs
>>>>> - Binary
>>>>>
>>>>> `F` would mean source character set. `Fb` would mean binary. And `Fu`
>>>>> would mean Unicode, as identified by BOMs. You can still apply the en=
coding
>>>>> prefixes to the non-binary forms, and indeed you *must* provide one
>>>>> for `Fu`. For example:
>>>>>
>>>>> - u8F: Read source character set, convert to UTF-8.
>>>>> - uFu: Read Unicode text, convert to UTF-16.
>>>>>
>>>>> And so forth.
>>>>>
>>>>> `Fu` would specifically mean:
>>>>>
>>>>> - Platform-specific text translation (new-lines and so forth).
>>>>> - BOM to identify the source Unicode encoding and endian. Lack of BOM
>>>>> automatically means UTF-8, but the UTF-8 BOM will also mean UTF-8. BO=
M is
>>>>> stripped out.
>>>>> - NUL-terminated.
>>>>>
>>>>> The encoding prefix allows cross-Unicode conversion. So if you have a
>>>>> UTF-16 text file and you want to store it as UTF-8, you use `u8Fu`.
>>>>>
>>>>> It's a simple and elegant solution to the source encoding problem.
>>>>>
>>>>>
>>>>>> (=C2=B9 Use compile-time text processing for this case if you simply
>>>>>> *must*
>>>>>> have it.)
>>>>>>
>>>>>
>>>>> The problem with that is that you are assuming that Unicode-encoded
>>>>> files represent a minor province of what people do.
>>>>>
>>>>
>>>> That's not the claim.  The claim is that the number of people using
>>>> both an unusual source encoding and a Unicode execution encoding is ve=
ry
>>>> small.  I think that is correct.
>>>>
>>>
>>> What is "an unusual source encoding?" Unicode is not "unusual".
>>>
>>
>> One that "cannot support all of Unicode".  Yes, of course Unicode is not
>> unusual - it is the norm these days.
>>
>> In order to not be able to use my first solution (that is manually
>> transcode your source file for the text file literal into source encodin=
g
>> before checking it in with your source files)
>>
>
> Wait a second, I just realized something.
>
> The whole point of file inclusions is to *avoid* "manually transcoding
> your source file", right? After all, if you're going to do that, if you
> have integrated such transcoding into the build process... why not just g=
o
> all the way to an actual C++ source file? If your source character set ca=
n
> actual handle this, just turn the file into an actual RAW string literal =
or
> whatever and just #include it.
>
> So you seem to have undermined the very purpose of your own proposal. Why
> should some users have to "manually transcode" their text files while oth=
er
> users don't?
>

You're forgetting this is a corner case.  In almost all cases the source
encoding is UTF-8, and the text files for input to text file literals will
already be in that format.


> , the source encoding must be unusual.
>>
>
> ASCII is not "unusual" for a source character set. The default source
> character set for quite a few compilers does not natively handle embedded
> Unicode characters.
>

I don't think that is true.  Please list a few of those quite a few
compilers.

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

--94eb2c11b6cc6f22bd05321c6275
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, May 5, 2016 at 7:48 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@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">On Th=
ursday, May 5, 2016 at 12:41:52 PM UTC-4, Andrew Tomazos wrote:<span class=
=3D""><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"><div><div cl=
ass=3D"gmail_quote">On Thu, May 5, 2016 at 6:22 PM, Nicol Bolas <span dir=
=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, May 5, 2016 a=
t 12:10:25 PM UTC-4, Andrew Tomazos wrote:<span><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, May 5=
, 2016 at 5:49 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jm=
ck...@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"><di=
v dir=3D"ltr"><div>It&#39;s silly to give up now that we&#39;re so close to=
 a functional design. You pointed out that you can identify Unicode-encoded=
 files by their BOMs. So instead of the giant number of sources, we actuall=
y only have:<br><br>- Source character set<br>- Unicode, in a format as ide=
ntified by BOMs<br>- Binary<br><br>`F` would mean source character set. `Fb=
` would mean binary. And `Fu` would mean Unicode, as identified by BOMs. Yo=
u can still apply the encoding prefixes to the non-binary forms, and indeed=
 you <i>must</i> provide one for `Fu`. For example:<br><br>- u8F: Read sour=
ce character set, convert to UTF-8.<br>- uFu: Read Unicode text, convert to=
 UTF-16.<br><br>And so forth.<br><br>`Fu` would specifically mean:<br><br>-=
 Platform-specific text translation (new-lines and so forth).<br>- BOM to i=
dentify the source Unicode encoding and endian. Lack of BOM automatically m=
eans UTF-8, but the UTF-8 BOM will also mean UTF-8. BOM is stripped out.<br=
>- NUL-terminated.<br><br>The encoding prefix allows cross-Unicode conversi=
on. So if you have a UTF-16 text file and you want to store it as UTF-8, yo=
u use `u8Fu`.<br><br>It&#39;s a simple and elegant solution to the source e=
ncoding problem.<br><br></div><span><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<br>(=C2=B9 Use compile-time text processing for this case if you simply *m=
ust*
<br>have it.)
<br></blockquote></span><div><br>The problem with that is that you are assu=
ming that Unicode-encoded files represent a minor province of what people d=
o.</div></div></blockquote><div><br></div><div>That&#39;s not the claim.=C2=
=A0 The claim is that the number of people using both an unusual source enc=
oding and a Unicode execution encoding is very small.=C2=A0 I think that is=
 correct.</div></div></div></div></blockquote></span><div><br>What is &quot=
;an unusual source encoding?&quot; Unicode is not &quot;unusual&quot;.<br><=
/div></div></blockquote><div><br></div><div>One that &quot;cannot support a=
ll of Unicode&quot;.=C2=A0 Yes, of course Unicode is not unusual - it is th=
e norm these days.</div><div><br></div><div>In order to not be able to use =
my first solution (that is manually transcode your source file for the text=
 file literal into source encoding before checking it in with your source f=
iles)</div></div></div></div></blockquote></span><div><br>Wait a second, I =
just realized something.<br><br>The whole point of file inclusions is to <i=
>avoid</i> &quot;manually transcoding your source file&quot;, right? After =
all, if you&#39;re going to do that, if you have integrated such transcodin=
g into the build process... why not just go all the way to an actual C++ so=
urce file? If your source character set can actual handle this, just turn t=
he file into an actual RAW string literal or whatever and just #include it.=
<br><br>So you seem to have undermined the very purpose of your own proposa=
l. Why should some users have to &quot;manually transcode&quot; their text =
files while other users don&#39;t?<br></div></div></blockquote><div><br></d=
iv><div>You&#39;re forgetting this is a corner case.=C2=A0 In almost all ca=
ses the source encoding is UTF-8, and the text files for input to text file=
 literals will already be in that format.</div><div>=C2=A0<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v>, the source encoding must be unusual.</div></div></div></div></blockquot=
e></span><div><br>ASCII is not &quot;unusual&quot; for a source character s=
et. The default source character set for quite a few compilers does not nat=
ively handle embedded Unicode characters.<br></div></div></blockquote><div>=
<br></div><div>I don&#39;t think that is true.=C2=A0 Please list a few of t=
hose quite a few compilers.</div><div><div dir=3D"ltr"><div><br></div></div=
></div></div></div></div>

<p></p>

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

--94eb2c11b6cc6f22bd05321c6275--

.

This is a multi-part message in MIME format.
--------------44B85F496FAE86289AAE9510
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 5/5/2016 2:19 PM, Andrew Tomazos wrote:
> In almost all cases the source encoding is UTF-8, and the text files=20
> for input to text file literals will already be in that format.

I keep hearing this echoed on various C++ standard mailing lists, but in=20
my experience, this just isn't true.  I think Clang assumes that the=20
source encoding is UTF-8, but gcc, the Microsoft compiler, IBM's=20
compilers, etc... use the current locale at the time of compilation to=20
determine the source encoding in the absence of a UTF-8 BOM (rare),=20
#pragma (rare, somewhat common for IBM compilers, at least in header=20
files) or explicit compiler option (also rare, and only very recently an=20
option for the Microsoft compiler [1]). It is certainly common for=20
source files to be limited to ASCII and therefore UTF-8 compatible, but=20
I don't think it is fair to state this is true in "almost all cases".
>
>         , the source encoding must be unusual.
>
>
>     ASCII is not "unusual" for a source character set. The default
>     source character set for quite a few compilers does not natively
>     handle embedded Unicode characters.
>
>
> I don't think that is true.  Please list a few of those quite a few=20
> compilers.

The most obvious example is IBM's z/OS C++ compiler.  But again, by=20
default, gcc and Microsoft use the current locale at the time of=20
compilation to determine the source character set.  The current locale=20
may specify a character set that is not ASCII compatible; Shift JIS, for=20
example, encodes a yen symbol (=C2=A5) at the code point (0x5c) that is use=
d=20
for backslash (\) in ASCII.

Tom.

[1]:=20
https://blogs.msdn.microsoft.com/vcblog/2016/02/22/new-options-for-managing=
-character-sets-in-the-microsoft-cc-compiler/=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/73afa19b-6ce0-a209-b2e6-82962511ebea%40honermann=
..net.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 5/5/2016 2:19 PM, Andrew Tomazos
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAB+4KHK5Eqpe-BJM+x26PX3cDL0CO5E+mt31NQAb4y5djYmL6w@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">In almost all cases the source
            encoding is UTF-8, and the text files for input to text file
            literals will already be in that format.</div>
        </div>
      </div>
    </blockquote>
    <br>
    I keep hearing this echoed on various C++ standard mailing lists,
    but in my experience, this just isn't true.=C2=A0 I think Clang assumes
    that the source encoding is UTF-8, but gcc, the Microsoft compiler,
    IBM's compilers, etc... use the current locale at the time of
    compilation to determine the source encoding in the absence of a
    UTF-8 BOM (rare), #pragma (rare, somewhat common for IBM compilers,
    at least in header files) or explicit compiler option (also rare,
    and only very recently an option for the Microsoft compiler [1]).=C2=A0
    It is certainly common for source files to be limited to ASCII and
    therefore UTF-8 compatible, but I don't think it is fair to state
    this is true in "almost all cases".<br>
    <blockquote
cite=3D"mid:CAB+4KHK5Eqpe-BJM+x26PX3cDL0CO5E+mt31NQAb4y5djYmL6w@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>=C2=A0<br>
            </div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr"><span class=3D"">
                  <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">
                      <div>
                        <div class=3D"gmail_quote">
                          <div>, the source encoding must be unusual.</div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </span>
                <div><br>
                  ASCII is not "unusual" for a source character set. The
                  default source character set for quite a few compilers
                  does not natively handle embedded Unicode characters.<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I don't think that is true.=C2=A0 Please list a few of tho=
se
              quite a few compilers.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    The most obvious example is IBM's z/OS C++ compiler.=C2=A0 But again, b=
y
    default, gcc and Microsoft use the current locale at the time of
    compilation to determine the source character set.=C2=A0 The current
    locale may specify a character set that is not ASCII compatible;
    Shift JIS, for example, encodes a yen symbol (=C2=A5) at the code point
    (0x5c) that is used for backslash (\) in ASCII.<br>
    <br>
    Tom.<br>
    <br>
    [1]:
<a class=3D"moz-txt-link-freetext" href=3D"https://blogs.msdn.microsoft.com=
/vcblog/2016/02/22/new-options-for-managing-character-sets-in-the-microsoft=
-cc-compiler/">https://blogs.msdn.microsoft.com/vcblog/2016/02/22/new-optio=
ns-for-managing-character-sets-in-the-microsoft-cc-compiler/</a>
  </body>
</html>

<p></p>

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

--------------44B85F496FAE86289AAE9510--

.

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

On Thursday, 5 May 2016 03:35:55 UTC+1, Andrew Tomazos  wrote:
> I am struggling with the binary file literal size issue.=C2=A0 I do not t=
hink that null-termination should be present on binary file literals, to di=
scourage use.=C2=A0 Binary file literals in the general case do contain emb=
edded nulls.=C2=A0 I would like them to be arrays of char, but they would t=
hen easily coerce to const char* which looks like a C string.=C2=A0 I would=
 like to be able to write a constexpr function f such that both f(F"foo") a=
nd f(bF"foo") will work and properly get the range of bytes that the two li=
terals present.=C2=A0=20

Have you considered expanding binary file literals to a braced-init-list ra=
ther than a string literal? A braced-init-list will not bind to a pointer, =
but it can bind to an array reference and will initialize an array of unspe=
cified length with the correct size.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/09700f9e-a633-4820-b649-0621e4d7908f%40isocpp.or=
g.

------=_Part_80_78539964.1462488568659--

.

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

On Thu, May 5, 2016 at 9:26 PM, Tom Honermann <tom@honermann.net> wrote:

> On 5/5/2016 2:19 PM, Andrew Tomazos wrote:
>
> In almost all cases the source encoding is UTF-8, and the text files for
> input to text file literals will already be in that format.
>
>
> I keep hearing this echoed on various C++ standard mailing lists, but in
> my experience, this just isn't true.  I think Clang assumes that the sour=
ce
> encoding is UTF-8, but gcc,
>

From the GCC manual:

"The files input to CPP might be in any character set at all. CPP's very
first action, before it even looks for line boundaries, is to convert the
file into the character set it uses for internal processing. That set is
what the C standard calls the source character set. It must be isomorphic
with ISO 10646, also known as Unicode. CPP uses the UTF-8 encoding of
Unicode."

Can you please tell me where you get the idea that gcc uses the current
locale to select the source encoding at the time of compilation?  I believe
the default of -finput-charset is UTF-8.

the Microsoft compiler, IBM's compilers, etc... use the current locale at
> the time of compilation to determine the source encoding in the absence o=
f
> a UTF-8 BOM (rare), #pragma (rare, somewhat common for IBM compilers, at
> least in header files) or explicit compiler option (also rare, and only
> very recently an option for the Microsoft compiler [1]).  It is certainly
> common for source files to be limited to ASCII and therefore UTF-8
> compatible, but I don't think it is fair to state this is true in "almost
> all cases".
>
>
>
>> , the source encoding must be unusual.
>>>
>>
>> ASCII is not "unusual" for a source character set. The default source
>> character set for quite a few compilers does not natively handle embedde=
d
>> Unicode characters.
>>
>
> I don't think that is true.  Please list a few of those quite a few
> compilers.
>
>
> The most obvious example is IBM's z/OS C++ compiler.  But again, by
> default, gcc and Microsoft use the current locale at the time of
> compilation to determine the source character set.  The current locale ma=
y
> specify a character set that is not ASCII compatible; Shift JIS, for
> example, encodes a yen symbol (=C2=A5) at the code point (0x5c) that is u=
sed for
> backslash (\) in ASCII.
>
> Tom.
>
> [1]:
> https://blogs.msdn.microsoft.com/vcblog/2016/02/22/new-options-for-managi=
ng-character-sets-in-the-microsoft-cc-compiler/
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/73afa19b-6ce=
0-a209-b2e6-82962511ebea%40honermann.net
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/73afa19b-6c=
e0-a209-b2e6-82962511ebea%40honermann.net?utm_medium=3Demail&utm_source=3Df=
ooter>
> .
>

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

--001a113e2fd8dc9a7005322b8d3c
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, May 5, 2016 at 9:26 PM, Tom Honermann <span dir=3D"ltr">&lt;<a =
href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@honermann.net</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    <div>On 5/5/2016 2:19 PM, Andrew Tomazos
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">In almost all cases the source
            encoding is UTF-8, and the text files for input to text file
            literals will already be in that format.</div>
        </div>
      </div>
    </blockquote>
    <br></span>
    I keep hearing this echoed on various C++ standard mailing lists,
    but in my experience, this just isn&#39;t true.=C2=A0 I think Clang ass=
umes
    that the source encoding is UTF-8, but gcc, </div></blockquote><div><br=
></div><div>From the GCC manual:</div><div><br></div><div>&quot;<span style=
=3D"color:rgb(0,0,0);font-family:Times;font-size:medium">The files input to=
 CPP might be in any character set at all. CPP&#39;s very first action, bef=
ore it even looks for line boundaries, is to convert the file into the char=
acter set it uses for internal processing. That set is what the C standard =
calls the=C2=A0</span><dfn style=3D"color:rgb(0,0,0);font-family:Times;font=
-size:medium">source</dfn><span style=3D"color:rgb(0,0,0);font-family:Times=
;font-size:medium">=C2=A0character set. It must be isomorphic with ISO 1064=
6, also known as Unicode. CPP uses the UTF-8 encoding of Unicode.&quot;</sp=
an></div></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quo=
te">Can you please tell me where you get the idea that gcc uses the current=
 locale to select the source encoding at the time of compilation?=C2=A0 I b=
elieve the default of=C2=A0<samp style=3D"color:rgb(0,0,0)"><span class=3D"=
">-finput-charset</span></samp><span style=3D"color:rgb(0,0,0);font-family:=
monospace">=C2=A0</span>is UTF-8.</div><div class=3D"gmail_quote"><br></div=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-l=
eft-color:rgb(204,204,204);padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000">the Microsoft compiler,
    IBM&#39;s compilers, etc... use the current locale at the time of
    compilation to determine the source encoding in the absence of a
    UTF-8 BOM (rare), #pragma (rare, somewhat common for IBM compilers,
    at least in header files) or explicit compiler option (also rare,
    and only very recently an option for the Microsoft compiler [1]).=C2=A0
    It is certainly common for source files to be limited to ASCII and
    therefore UTF-8 compatible, but I don&#39;t think it is fair to state
    this is true in &quot;almost all cases&quot;.<span class=3D""><br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>=C2=A0<br>
            </div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex">
              <div dir=3D"ltr"><span>
                  <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex">
                    <div dir=3D"ltr">
                      <div>
                        <div class=3D"gmail_quote">
                          <div>, the source encoding must be unusual.</div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </span>
                <div><br>
                  ASCII is not &quot;unusual&quot; for a source character s=
et. The
                  default source character set for quite a few compilers
                  does not natively handle embedded Unicode characters.<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I don&#39;t think that is true.=C2=A0 Please list a few of=
 those
              quite a few compilers.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    The most obvious example is IBM&#39;s z/OS C++ compiler.=C2=A0 But agai=
n, by
    default, gcc and Microsoft use the current locale at the time of
    compilation to determine the source character set.=C2=A0 The current
    locale may specify a character set that is not ASCII compatible;
    Shift JIS, for example, encodes a yen symbol (=C2=A5) at the code point
    (0x5c) that is used for backslash (\) in ASCII.<br>
    <br>
    Tom.<br>
    <br>
    [1]:
<a href=3D"https://blogs.msdn.microsoft.com/vcblog/2016/02/22/new-options-f=
or-managing-character-sets-in-the-microsoft-cc-compiler/" target=3D"_blank"=
>https://blogs.msdn.microsoft.com/vcblog/2016/02/22/new-options-for-managin=
g-character-sets-in-the-microsoft-cc-compiler/</a>
  </div><span class=3D"">


<p></p>

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

<p></p>

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

--001a113e2fd8dc9a7005322b8d3c--

.

On 2016-05-06 08:25, Andrew Tomazos wrote:
> From the GCC manual:
>
> "The files input to CPP might be in any character set at all. CPP's very
> first action, before it even looks for line boundaries, is to convert the
> file into the character set it uses for internal processing. That set is
> what the C standard calls the source character set. It must be isomorphic
> with ISO 10646, also known as Unicode. CPP uses the UTF-8 encoding of
> Unicode."
>
> Can you please tell me where you get the idea that gcc uses the current
> locale to select the source encoding at the time of compilation?  I believe
> the default of -finput-charset is UTF-8.

(From the GCC 4.9 documentation; emphasis added:)

  -finput-charset=CHARSET
    Set the input character set, used for translation from the
    character set of the input file to the source character set used by
    GCC. *If the locale does not specify*, or GCC cannot get this
    information from the locale, the default is UTF-8.

The *fallback* is UTF-8. The "default" is 'as specified by the current
locale'. (At least, that's what the documentation claims; I haven't
actually attempted to test it.)

--
Matthew

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

.

On 5/6/2016 11:03 AM, Matthew Woehlke wrote:
> On 2016-05-06 08:25, Andrew Tomazos wrote:
>>  From the GCC manual:
>>
>> "The files input to CPP might be in any character set at all. CPP's very
>> first action, before it even looks for line boundaries, is to convert th=
e
>> file into the character set it uses for internal processing. That set is
>> what the C standard calls the source character set. It must be isomorphi=
c
>> with ISO 10646, also known as Unicode. CPP uses the UTF-8 encoding of
>> Unicode."
I believe the above indicates that gcc's internal character set is=20
UTF-8; this doesn't indicate a default input file character set.
>>
>> Can you please tell me where you get the idea that gcc uses the current
>> locale to select the source encoding at the time of compilation?  I beli=
eve
>> the default of -finput-charset is UTF-8.
> (From the GCC 4.9 documentation; emphasis added:)
>
>    -finput-charset=3DCHARSET
>      Set the input character set, used for translation from the
>      character set of the input file to the source character set used by
>      GCC. *If the locale does not specify*, or GCC cannot get this
>      information from the locale, the default is UTF-8.
>
> The *fallback* is UTF-8. The "default" is 'as specified by the current
> locale'. (At least, that's what the documentation claims; I haven't
> actually attempted to test it.)
>
Despite the documentation, I can't seem to get my gcc builds to=20
differentiate behavior based on locale settings.

Regardless, the default I see looks like ISO8859-1, not UTF-8.  My gcc=20
builds accepts the following input that is ill-formed UTF-8.

$ cat t.cpp
#include <stdio.h>
int main() {
     unsigned char c =3D '=C2=A3'; // 0xA3
     printf("0x%X\n", (unsigned int)c);
}

# Note 'a3' at offset 0x67.
$ od -t x1 t.cpp
0000000 23 69 6e 63 6c 75 64 65 20 3c 73 74 64 69 6f 2e
0000020 68 3e 0a 69 6e 74 20 6d 61 69 6e 28 29 20 7b 0a
0000040 20 20 20 20 75 6e 73 69 67 6e 65 64 20 63 68 61
0000060 72 20 63 20 3d 20 27 a3 27 3b 20 2f 2f 20 30 78
0000100 41 33 0a 20 20 20 20 70 72 69 6e 74 66 28 22 30
0000120 78 25 58 5c 6e 22 2c 20 28 75 6e 73 69 67 6e 65
0000140 64 20 69 6e 74 29 63 29 3b 0a 7d 0a
0000154

$ iconv -f utf-8 -t utf-8 t.cpp
#include <stdio.h>
int main() {
     unsigned char c =3D 'iconv: illegal input sequence at position 55

$ g++ t.cpp -o t
$ ./t
0xA3

Tom.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8c73973a-f273-9859-c3d8-736b1d4f849c%40honermann=
..net.

.

This is a multi-part message in MIME format.
--------------010809010909070308070005
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 2016-05-06 11:46, Tom Honermann wrote:
> On 5/6/2016 11:03 AM, Matthew Woehlke wrote:
>> (From the GCC 4.9 documentation; emphasis added:)
>>
>>    -finput-charset=3DCHARSET
>>      Set the input character set, used for translation from the
>>      character set of the input file to the source character set used by
>>      GCC. *If the locale does not specify*, or GCC cannot get this
>>      information from the locale, the default is UTF-8.
>>
>> The *fallback* is UTF-8. The "default" is 'as specified by the current
>> locale'. (At least, that's what the documentation claims; I haven't
>> actually attempted to test it.)
>
> Despite the documentation, I can't seem to get my gcc builds to
> differentiate behavior based on locale settings.
>=20
> Regardless, the default I see looks like ISO8859-1, not UTF-8.  My gcc
> builds accepts the following input that is ill-formed UTF-8.
> [snipped]

Interesting; *mine* clearly expects UTF-8=C2=B9. See the attached source fi=
le
in latin1 (a.k.a. ISO 8859-1) encoding. I get:

  $ g++ -std=3Dc++11 latin1.cpp && ./a.out
  =EF=BF=BD5, please
  $ g++ -std=3Dc++11 -finput-charset=3Dlatin1 latin1.cpp && ./a.out
  =C2=A35, please

If I convert the source file to UTF-8:

  $ g++ -std=3Dc++11 -finput-charset=3Dlatin1 utf8.cpp && ./a.out
  =C3=82=C2=A35, please!

(Interestingly, I can't seem to get -finput-charset=3Dutf16 to work:
`error: failure to convert UTF-16 to UTF-8`...)

(=C2=B9 ...which is consistent with my locale, en_US.UTF-8. What is your lo=
cale?)

--=20
Matthew

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

--------------010809010909070308070005
Content-Type: text/x-c++src;
 name="latin1.cpp"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="latin1.cpp"

#include <cstdio>

int main()
{
    printf("%s", u8"=A35, please\n");
    return 0;
}

--------------010809010909070308070005--


.

On sexta-feira, 6 de maio de 2016 11:03:34 PDT Matthew Woehlke wrote:
>   -finput-charset=CHARSET
>     Set the input character set, used for translation from the
>     character set of the input file to the source character set used by
>     GCC. *If the locale does not specify*, or GCC cannot get this
>     information from the locale, the default is UTF-8.
>
> The *fallback* is UTF-8. The "default" is 'as specified by the current
> locale'. (At least, that's what the documentation claims; I haven't
> actually attempted to test it.)

The documentation is wrong. GCC does not attempt to identify the current
locale's charset and directly falls back to UTF-8.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

This is a multi-part message in MIME format.
--------------040406070204070800060603
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 05/06/2016 01:15 PM, Matthew Woehlke wrote:
> On 2016-05-06 11:46, Tom Honermann wrote:
>> On 5/6/2016 11:03 AM, Matthew Woehlke wrote:
>>> (From the GCC 4.9 documentation; emphasis added:)
>>>
>>>     -finput-charset=3DCHARSET
>>>       Set the input character set, used for translation from the
>>>       character set of the input file to the source character set used =
by
>>>       GCC. *If the locale does not specify*, or GCC cannot get this
>>>       information from the locale, the default is UTF-8.
>>>
>>> The *fallback* is UTF-8. The "default" is 'as specified by the current
>>> locale'. (At least, that's what the documentation claims; I haven't
>>> actually attempted to test it.)
>> Despite the documentation, I can't seem to get my gcc builds to
>> differentiate behavior based on locale settings.
>>
>> Regardless, the default I see looks like ISO8859-1, not UTF-8.  My gcc
>> builds accepts the following input that is ill-formed UTF-8.
>> [snipped]
> Interesting; *mine* clearly expects UTF-8=C2=B9. See the attached source =
file
> in latin1 (a.k.a. ISO 8859-1) encoding. I get:
>
>    $ g++ -std=3Dc++11 latin1.cpp && ./a.out
>    =EF=BF=BD5, please
>    $ g++ -std=3Dc++11 -finput-charset=3Dlatin1 latin1.cpp && ./a.out
>    =C2=A35, please
>
> If I convert the source file to UTF-8:
>
>    $ g++ -std=3Dc++11 -finput-charset=3Dlatin1 utf8.cpp && ./a.out
>    =C3=82=C2=A35, please!
I get the same behavior with your test case (I'm using a gcc 6.0.0 build).
> (Interestingly, I can't seem to get -finput-charset=3Dutf16 to work:
> `error: failure to convert UTF-16 to UTF-8`...)
>
> (=C2=B9 ...which is consistent with my locale, en_US.UTF-8. What is your =
locale?)

My locale is also en_US.UTF-8.

I played around a bit more.  It looks like gcc accepts wtutf8 by=20
default; ill-formed UTF-8 code unit sequences are copied verbatim=20
without being transcoded (not even to a replacement character), the same=20
as for hex escape sequences.  Using the attached test:

$ g++ -std=3Dc++11 t.cpp -o t
$ ./t
narrow string:
   0xA3
   0x0
narrow string (hex escape):
   0xA3
   0x0
UTF-8 string:
   0xA3
   0x0
UTF-8 string (hex escape):
   0xA3
   0x0

$ g++ -std=3Dc++11 -finput-charset=3Diso8859-1 t.cpp -o t
$ ./t
narrow string:
   0xC2
   0xA3
   0x0
narrow string (hex escape):
   0xA3
   0x0
UTF-8 string:
   0xC2
   0xA3
   0x0
UTF-8 string (hex escape):
   0xA3
   0x0

Tom.

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

--------------040406070204070800060603
Content-Type: text/x-c++src;
 name="t.cpp"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename="t.cpp"

#include <cstdio>
int main()
{
    printf("narrow string: (well-formed UTF-8)\n");
    for (unsigned char c : "  ") { // 0xC2 0xA3
        printf("  0x%X\n", (unsigned int)c);
    }
    printf("narrow string: (ill-formed UTF-8)\n");
    for (unsigned char c : " ") { // 0xA3
        printf("  0x%X\n", (unsigned int)c);
    }
    printf("narrow string (hex escape):\n");
    for (unsigned char c : "\xa3") {
        printf("  0x%X\n", (unsigned int)c);
    }
    printf("UTF-8 string: (well-formed UTF-8)\n");
    for (unsigned char c : u8"  ") { // 0xC2 0xA3
        printf("  0x%X\n", (unsigned int)c);
    }
    printf("UTF-8 string: (ill-formed UTF-8)\n");
    for (unsigned char c : u8" ") { // 0xA3
        printf("  0x%X\n", (unsigned int)c);
    }
    printf("UTF-8 string (hex escape):\n");
    for (unsigned char c : u8"\xa3") {
        printf("  0x%X\n", (unsigned int)c);
    }
}

--------------040406070204070800060603--

.

On 05/06/2016 05:37 PM, Thiago Macieira wrote:
> On sexta-feira, 6 de maio de 2016 11:03:34 PDT Matthew Woehlke wrote:
>>    -finput-charset=CHARSET
>>      Set the input character set, used for translation from the
>>      character set of the input file to the source character set used by
>>      GCC. *If the locale does not specify*, or GCC cannot get this
>>      information from the locale, the default is UTF-8.
>>
>> The *fallback* is UTF-8. The "default" is 'as specified by the current
>> locale'. (At least, that's what the documentation claims; I haven't
>> actually attempted to test it.)
> The documentation is wrong. GCC does not attempt to identify the current
> locale's charset and directly falls back to UTF-8.
>
If gcc doesn't consult the locale, then there isn't anything to fall
back from (unrecognized -finput-charset operands are rejected).  The
test I supplied demonstrated that gcc doesn't reject ill-formed UTF-8,
so I think it is imprecise to state it uses UTF-8 as the default input
encoding.  Per my response to Matthew, it looks like it uses wtutf8.

Tom.

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

.

On 05/07/2016 12:16 PM, Tom Honermann wrote:
> I played around a bit more.  It looks like gcc accepts wtutf8 by
> default; ill-formed UTF-8 code unit sequences are copied verbatim
> without being transcoded (not even to a replacement character), the
> same as for hex escape sequences.  Using the attached test:
>
> $ g++ -std=c++11 t.cpp -o t
> $ ./t
> narrow string:
>   0xA3
>   0x0
> narrow string (hex escape):
>   0xA3
>   0x0
> UTF-8 string:
>   0xA3
>   0x0
> UTF-8 string (hex escape):
>   0xA3
>   0x0
>
> $ g++ -std=c++11 -finput-charset=iso8859-1 t.cpp -o t
> $ ./t
> narrow string:
>   0xC2
>   0xA3
>   0x0
> narrow string (hex escape):
>   0xA3
>   0x0
> UTF-8 string:
>   0xC2
>   0xA3
>   0x0
> UTF-8 string (hex escape):
>   0xA3
>   0x0

Bah, I had modified the test case to add testing of well-formed UTF-8
code unit sequences, but forgot to update the output above. The
differences above are the only part actually interesting for this
discussion, but for completeness, here is the correct output:

$ g++ -std=c++11 t.cpp -o t
$ ./t
narrow string: (well-formed UTF-8)
   0xC2
   0xA3
   0x0
narrow string: (ill-formed UTF-8)
   0xA3
   0x0
narrow string (hex escape):
   0xA3
   0x0
UTF-8 string: (well-formed UTF-8)
   0xC2
   0xA3
   0x0
UTF-8 string: (ill-formed UTF-8)
   0xA3
   0x0
UTF-8 string (hex escape):
   0xA3
   0x0

$ g++ -std=c++11 -finput-charset=iso8859-1 t.cpp -o t
$ ./t
narrow string: (well-formed UTF-8)
   0xC3
   0x82
   0xC2
   0xA3
   0x0
narrow string: (ill-formed UTF-8)
   0xC2
   0xA3
   0x0
narrow string (hex escape):
   0xA3
   0x0
UTF-8 string: (well-formed UTF-8)
   0xC3
   0x82
   0xC2
   0xA3
   0x0
UTF-8 string: (ill-formed UTF-8)
   0xC2
   0xA3
   0x0
UTF-8 string (hex escape):
   0xA3
   0x0

Tom.

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

.

------=_Part_351_253964185.1462658237781
Content-Type: multipart/alternative;
 boundary="----=_Part_352_1501829420.1462658237781"

------=_Part_352_1501829420.1462658237781
Content-Type: text/plain; charset=UTF-8

On Saturday, May 7, 2016 at 12:23:24 PM UTC-4, Tom Honermann wrote:
>
>
> If gcc doesn't consult the locale, then there isn't anything to fall
> back from (unrecognized -finput-charset operands are rejected).  The
> test I supplied demonstrated that gcc doesn't reject ill-formed UTF-8,
> so I think it is imprecise to state it uses UTF-8 as the default input
> encoding.  Per my response to Matthew, it looks like it uses wtutf8.
>

What is wtutf8? I've never heard of this term before.

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

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

<div dir=3D"ltr">On Saturday, May 7, 2016 at 12:23:24 PM UTC-4, Tom Honerma=
nn wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>If gcc doesn&#39;=
t consult the locale, then there isn&#39;t anything to fall=20
<br>back from (unrecognized -finput-charset operands are rejected). =C2=A0T=
he=20
<br>test I supplied demonstrated that gcc doesn&#39;t reject ill-formed UTF=
-8,=20
<br>so I think it is imprecise to state it uses UTF-8 as the default input=
=20
<br>encoding. =C2=A0Per my response to Matthew, it looks like it uses wtutf=
8.
<br></blockquote><div><br>What is wtutf8? I&#39;ve never heard of this term=
 before.<br></div></div>

<p></p>

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

------=_Part_352_1501829420.1462658237781--
------=_Part_351_253964185.1462658237781--

.

On s=C3=A1bado, 7 de maio de 2016 12:23:21 PDT Tom Honermann wrote:
> If gcc doesn't consult the locale, then there isn't anything to fall
> back from (unrecognized -finput-charset operands are rejected).  The
> test I supplied demonstrated that gcc doesn't reject ill-formed UTF-8,
> so I think it is imprecise to state it uses UTF-8 as the default input
> encoding.  Per my response to Matthew, it looks like it uses wtutf8.

Your test was invalid because it contained invalid UTF-8 sequences and my=
=20
editor destroyed them.

This discussion is also going off-topic. GCC behaviour should be discussed =
in=20
a GCC mailing list. Sending files over the network and sharing with other=
=20
people in other operating systems, with possibly different locale encodings=
,=20
is not part of the C++ standard.

I'm not joking. The standard doesn't take that into account. Sharing files =
with=20
other people and getting the same compilation requires stepping outside of =
the=20
standard and and into compiler-specific territory.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

On May 7, 2016, at 5:57 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> What is wtutf8? I've never heard of this term

It's a colloquial term that might be more readily recognized if spelled "wtf utf-8".

I believe I first heard it used to describe how Clang attempts to interpret file names for presentation purposes (perhaps in diagnostics? Or when generating preprocessing line control directives? I don't recall).

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/A0225AB0-98DF-4EB4-AAE0-3CB8073156FE%40honermann.net.

.

------=_Part_1751_1991637335.1462675689911
Content-Type: multipart/alternative;
 boundary="----=_Part_1752_661921009.1462675689912"

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

On Saturday, May 7, 2016 at 7:18:33 PM UTC-4, Thiago Macieira wrote:
>
> On s=C3=A1bado, 7 de maio de 2016 12:23:21 PDT Tom Honermann wrote:=20
> > If gcc doesn't consult the locale, then there isn't anything to fall=20
> > back from (unrecognized -finput-charset operands are rejected).  The=20
> > test I supplied demonstrated that gcc doesn't reject ill-formed UTF-8,=
=20
> > so I think it is imprecise to state it uses UTF-8 as the default input=
=20
> > encoding.  Per my response to Matthew, it looks like it uses wtutf8.=20
>
> Your test was invalid because it contained invalid UTF-8 sequences and my=
=20
> editor destroyed them.
>

An implementation of UTF-8 must also disallow illegal UTF-8 sequences. Just=
=20
like an implementation of C++ must disallow illegal C++.
=20

> This discussion is also going off-topic. GCC behaviour should be discusse=
d=20
> in=20
> a GCC mailing list.


The point of discussing it *here* is to answer a very important question:=
=20
what source character sets are the defaults for compilers, and how many=20
don't default to some form of Unicode? If 20% of compilers (by use) default=
=20
to ASCII or whatever, then literal inclusion of text files would be=20
significantly hampered due to the inability of people to use it for Unicode=
=20
strings or Internationalization of any kind.
=20

> Sending files over the network and sharing with other=20
> people in other operating systems, with possibly different locale=20
> encodings,=20
> is not part of the C++ standard.=20
>
> I'm not joking. The standard doesn't take that into account. Sharing file=
s=20
> with=20
> other people and getting the same compilation requires stepping outside o=
f=20
> the=20
> standard and and into compiler-specific territory.
>

That's true, the standard doesn't provide any such guarantees.

That doesn't mean that this file inclusion mechanism *shouldn't*. After=20
all, the whole point of allowing binary inclusion is to allow people to be=
=20
able to store literal binary data cross-platform, *exactly* as it was in=20
the file. With `Fb`, each compiler is required to store the same stream of=
=20
`unsigned char` that would have been read from an untranslated `fopen` or=
=20
`iostream` or whatever.

That's as cross-compiler as it gets.

Allowing a way to do this with text, through the use of Unicode, is not a=
=20
bad idea. It would also be a very *useful* idea. And unlike mandating some=
=20
form of Unicode as the source character set for actual source files, it=20
wouldn't impact any existing systems. Anything could implement it.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/89846d6d-12d4-4607-94b7-163c50842aea%40isocpp.or=
g.

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

<div dir=3D"ltr">On Saturday, May 7, 2016 at 7:18:33 PM UTC-4, Thiago Macie=
ira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On s=C3=A1bado, 7 de=
 maio de 2016 12:23:21 PDT Tom Honermann wrote:
<br>&gt; If gcc doesn&#39;t consult the locale, then there isn&#39;t anythi=
ng to fall
<br>&gt; back from (unrecognized -finput-charset operands are rejected). =
=C2=A0The
<br>&gt; test I supplied demonstrated that gcc doesn&#39;t reject ill-forme=
d UTF-8,
<br>&gt; so I think it is imprecise to state it uses UTF-8 as the default i=
nput
<br>&gt; encoding. =C2=A0Per my response to Matthew, it looks like it uses =
wtutf8.
<br>
<br>Your test was invalid because it contained invalid UTF-8 sequences and =
my=20
<br>editor destroyed them.<br></blockquote><div><br>An implementation of UT=
F-8 must also disallow illegal UTF-8 sequences. Just like an implementation=
 of C++ must disallow illegal C++.<br>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">
This discussion is also going off-topic. GCC behaviour should be discussed =
in=20
<br>a GCC mailing list.</blockquote><div><br>The point of discussing it <i>=
here</i> is to answer a very important question: what source character sets=
 are the defaults for compilers, and how many don&#39;t default to some for=
m of Unicode? If 20% of compilers (by use) default to ASCII or whatever, th=
en literal inclusion of text files would be significantly hampered due to t=
he inability of people to use it for Unicode strings or Internationalizatio=
n of any kind.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
Sending files over the network and sharing with other=20
<br>people in other operating systems, with possibly different locale encod=
ings,=20
<br>is not part of the C++ standard.
<br>
<br>I&#39;m not joking. The standard doesn&#39;t take that into account. Sh=
aring files with=20
<br>other people and getting the same compilation requires stepping outside=
 of the=20
<br>standard and and into compiler-specific territory.<br></blockquote><div=
><br>That&#39;s true, the standard doesn&#39;t provide any such guarantees.=
<br><br>That doesn&#39;t mean that this file inclusion mechanism <i>shouldn=
&#39;t</i>. After all, the whole point of allowing binary inclusion is to a=
llow people to be able to store literal binary data cross-platform, <i>exac=
tly</i> as it was in the file. With `Fb`, each compiler is required to stor=
e the same stream of `unsigned char` that would have been read from an untr=
anslated `fopen` or `iostream` or whatever.<br><br>That&#39;s as cross-comp=
iler as it gets.<br><br>Allowing a way to do this with text, through the us=
e of Unicode, is not a bad idea. It would also be a very <i>useful</i> idea=
.. And unlike mandating some form of Unicode as the source character set for=
 actual source files, it wouldn&#39;t impact any existing systems. Anything=
 could implement it.<br></div></div>

<p></p>

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

------=_Part_1752_661921009.1462675689912--
------=_Part_1751_1991637335.1462675689911--

.

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

On Sat, May 7, 2016 at 6:35 PM, Tom Honermann <tom@honermann.net> wrote:

> On May 7, 2016, at 5:57 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> > What is wtutf8? I've never heard of this term
>
> It's a colloquial term that might be more readily recognized if spelled
> "wtf utf-8".
>
> I believe I first heard it used to describe how Clang attempts to
> interpret file names for presentation purposes (perhaps in diagnostics? Or
> when generating preprocessing line control directives? I don't recall).
>

I think what you're referring to is WTF-8? (See
https://simonsapin.github.io/wtf-8/).

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

--001a113abd1cacf4a605324d1eee
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 S=
at, May 7, 2016 at 6:35 PM, Tom Honermann <span dir=3D"ltr">&lt;<a href=3D"=
mailto:tom@honermann.net" target=3D"_blank">tom@honermann.net</a>&gt;</span=
> wrote:<br><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-s=
tyle:solid;padding-left:1ex"><span class=3D"">On May 7, 2016, at 5:57 PM, N=
icol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</=
a>&gt; wrote:<br>
&gt; What is wtutf8? I&#39;ve never heard of this term<br>
<br>
</span>It&#39;s a colloquial term that might be more readily recognized if =
spelled &quot;wtf utf-8&quot;.<br>
<br>
I believe I first heard it used to describe how Clang attempts to interpret=
 file names for presentation purposes (perhaps in diagnostics? Or when gene=
rating preprocessing line control directives? I don&#39;t recall).<br></blo=
ckquote><div><br></div><div>I think what you&#39;re referring to is WTF-8? =
(See <a href=3D"https://simonsapin.github.io/wtf-8/">https://simonsapin.git=
hub.io/wtf-8/</a>).<br></div></div></div></div>

<p></p>

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

--001a113abd1cacf4a605324d1eee--

.

On s=C3=A1bado, 7 de maio de 2016 19:48:09 PDT Nicol Bolas wrote:
> > Your test was invalid because it contained invalid UTF-8 sequences and =
my
> > editor destroyed them.
>=20
> An implementation of UTF-8 must also disallow illegal UTF-8 sequences. Ju=
st
> like an implementation of C++ must disallow illegal C++.

Right, it "disallowed" the invalid sequences by destroying them. They were=
=20
replaced by the replacement character.

> > This discussion is also going off-topic. GCC behaviour should be discus=
sed
> > in
> > a GCC mailing list.
>=20
> The point of discussing it *here* is to answer a very important question:
> what source character sets are the defaults for compilers, and how many
> don't default to some form of Unicode? If 20% of compilers (by use) defau=
lt
> to ASCII or whatever, then literal inclusion of text files would be
> significantly hampered due to the inability of people to use it for Unico=
de
> strings or Internationalization of any kind.

Given the discussion about trigraphs, I'm guessing only IBM currently still=
=20
cares about a non-ASCII encoding of source code.

Maybe if we ask Michael Wong directly for his opinion on this matter, we'll=
=20
get somewhere.

> > Sending files over the network and sharing with other
> > people in other operating systems, with possibly different locale
> > encodings,
> > is not part of the C++ standard.
> >=20
> > I'm not joking. The standard doesn't take that into account. Sharing fi=
les
> > with
> > other people and getting the same compilation requires stepping outside=
 of
> > the
> > standard and and into compiler-specific territory.
>=20
> That's true, the standard doesn't provide any such guarantees.
>=20
> That doesn't mean that this file inclusion mechanism *shouldn't*. After
> all, the whole point of allowing binary inclusion is to allow people to b=
e
> able to store literal binary data cross-platform, *exactly* as it was in
> the file. With `Fb`, each compiler is required to store the same stream o=
f
> `unsigned char` that would have been read from an untranslated `fopen` or
> `iostream` or whatever.
>=20
> That's as cross-compiler as it gets.

Well, you're assuming that the target platform has bytes the same size as t=
he=20
host platform that is compiling the source code. The C++ standard cannot=20
guarantee that. That means the only possible solution is "implementation-
defined".

I don't see the point in making binary files any more sharable than source =
code=20
itself.

> Allowing a way to do this with text, through the use of Unicode, is not a
> bad idea. It would also be a very *useful* idea. And unlike mandating som=
e
> form of Unicode as the source character set for actual source files, it
> wouldn't impact any existing systems. Anything could implement it.

The non-binary file inclusion options are much simpler, indeed.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

------=_Part_2022_1545712657.1462716731429
Content-Type: multipart/alternative;
 boundary="----=_Part_2023_1546610672.1462716731437"

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



On Sunday, May 8, 2016 at 2:36:45 AM UTC-4, Thiago Macieira wrote:
>
> On s=C3=A1bado, 7 de maio de 2016 19:48:09 PDT Nicol Bolas wrote:=20
> > > Your test was invalid because it contained invalid UTF-8 sequences an=
d=20
> my=20
> > > editor destroyed them.=20
> >=20
> > An implementation of UTF-8 must also disallow illegal UTF-8 sequences.=
=20
> Just=20
> > like an implementation of C++ must disallow illegal C++.=20
>
> Right, it "disallowed" the invalid sequences by destroying them. They wer=
e=20
> replaced by the replacement character.=20
>
> > > This discussion is also going off-topic. GCC behaviour should be=20
> discussed=20
> > > in=20
> > > a GCC mailing list.=20
> >=20
> > The point of discussing it *here* is to answer a very important=20
> question:=20
> > what source character sets are the defaults for compilers, and how many=
=20
> > don't default to some form of Unicode? If 20% of compilers (by use)=20
> default=20
> > to ASCII or whatever, then literal inclusion of text files would be=20
> > significantly hampered due to the inability of people to use it for=20
> Unicode=20
> > strings or Internationalization of any kind.=20
>
> Given the discussion about trigraphs, I'm guessing only IBM currently=20
> still=20
> cares about a non-ASCII encoding of source code.
>

You don't seem to understand the goal here.

The goal is for a user to be able to write text file literals that can be=
=20
used with every compiler. This is a very useful thing to be able to do, and=
=20
if we're going to have file literals, they should be able to be written in=
=20
a platform-neutral. Something that you can actually *rely* upon.

More fragility is something that C++ can do without.

The question is whether that goal has already been *de-facto* achieved=20
through the source character set (based on the default inputs for=20
compilers) or whether we need a *de-jure* means of doing so with file=20
literals. That's why we want to know about what compilers take. If most=20
compilers can accept Unicode strings by default, then whether we need a=20
real mechanism is in doubt. But if there are a lot of compilers that don't,=
=20
or if they differ greatly on which Unicode encodings they take, then there=
=20
is a clear need to build one into the system.

A compiler which can only take ASCII is not part of the "de-facto achieved"=
=20
group. This is not a question of "ASCII vs. IBM's stuff". It's "Known=20
Unicode format vs. other things."

Maybe if we ask Michael Wong directly for his opinion on this matter, we'll=
=20
> get somewhere.=20
>
> > > Sending files over the network and sharing with other=20
> > > people in other operating systems, with possibly different locale=20
> > > encodings,=20
> > > is not part of the C++ standard.=20
> > >=20
> > > I'm not joking. The standard doesn't take that into account. Sharing=
=20
> files=20
> > > with=20
> > > other people and getting the same compilation requires stepping=20
> outside of=20
> > > the=20
> > > standard and and into compiler-specific territory.=20
> >=20
> > That's true, the standard doesn't provide any such guarantees.=20
> >=20
> > That doesn't mean that this file inclusion mechanism *shouldn't*. After=
=20
> > all, the whole point of allowing binary inclusion is to allow people to=
=20
> be=20
> > able to store literal binary data cross-platform, *exactly* as it was i=
n=20
> > the file. With `Fb`, each compiler is required to store the same stream=
=20
> of=20
> > `unsigned char` that would have been read from an untranslated `fopen`=
=20
> or=20
> > `iostream` or whatever.=20
> >=20
> > That's as cross-compiler as it gets.=20
>
> Well, you're assuming that the target platform has bytes the same size as=
=20
> the=20
> host platform that is compiling the source code.


No, I am not. If the host platform can compile to the target platform, then=
=20
the host platform knows the byte size of the target. Otherwise it would be=
=20
unable to convert even a literal string to the target platform's `char`=20
type. Armed with such knowledge, the host compiler can do whatever internal=
=20
conversion is needed to make it work as if the target platform loaded it.

The `char` sequence you get from a binary file literal is as if you had=20
read the file through a stream on the target platform. Generating that data=
=20
is simply a matter of the host doing whatever gymnastics are needed to=20
convert what the host platform sees to what the target platform would have=
=20
seen had it read the file.

I fail to see how this would not be possible.

The C++ standard cannot=20
> guarantee that. That means the only possible solution is "implementation-=
=20
> defined".=20
>
> I don't see the point in making binary files any more sharable than sourc=
e=20
> code=20
> itself.
>

You mean besides making it genuinely useful? And stopping people from=20
writing brittle code that works on one platform but doesn't work on another=
?

> Allowing a way to do this with text, through the use of Unicode, is not a=
=20
> > bad idea. It would also be a very *useful* idea. And unlike mandating=
=20
> some=20
> > form of Unicode as the source character set for actual source files, it=
=20
> > wouldn't impact any existing systems. Anything could implement it.=20
>
> The non-binary file inclusion options are much simpler, indeed.
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7bba4d3e-d135-4fad-b089-c3d7705aca22%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Sunday, May 8, 2016 at 2:36:45 AM UTC-4, Thiago=
 Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On s=C3=A1bado=
, 7 de maio de 2016 19:48:09 PDT Nicol Bolas wrote:
<br>&gt; &gt; Your test was invalid because it contained invalid UTF-8 sequ=
ences and my
<br>&gt; &gt; editor destroyed them.
<br>&gt;=20
<br>&gt; An implementation of UTF-8 must also disallow illegal UTF-8 sequen=
ces. Just
<br>&gt; like an implementation of C++ must disallow illegal C++.
<br>
<br>Right, it &quot;disallowed&quot; the invalid sequences by destroying th=
em. They were=20
<br>replaced by the replacement character.
<br>
<br>&gt; &gt; This discussion is also going off-topic. GCC behaviour should=
 be discussed
<br>&gt; &gt; in
<br>&gt; &gt; a GCC mailing list.
<br>&gt;=20
<br>&gt; The point of discussing it *here* is to answer a very important qu=
estion:
<br>&gt; what source character sets are the defaults for compilers, and how=
 many
<br>&gt; don&#39;t default to some form of Unicode? If 20% of compilers (by=
 use) default
<br>&gt; to ASCII or whatever, then literal inclusion of text files would b=
e
<br>&gt; significantly hampered due to the inability of people to use it fo=
r Unicode
<br>&gt; strings or Internationalization of any kind.
<br>
<br>Given the discussion about trigraphs, I&#39;m guessing only IBM current=
ly still=20
<br>cares about a non-ASCII encoding of source code.<br></blockquote><div><=
br>You don&#39;t seem to understand the goal here.<br><br>The goal is for a=
 user to be able to write text file literals that can be used with every co=
mpiler. This is a very useful thing to be able to do, and if we&#39;re goin=
g to have file literals, they should be able to be written in a platform-ne=
utral. Something that you can actually <i>rely</i> upon.<br><br>More fragil=
ity is something that C++ can do without.<br><br>The question is whether th=
at goal has already been <i>de-facto</i> achieved through the source charac=
ter set (based on the default inputs for compilers) or whether we need a <i=
>de-jure</i> means of doing so with file literals. That&#39;s why we want t=
o know about what compilers take. If most compilers can accept Unicode stri=
ngs by default, then whether we need a real mechanism is in doubt. But if t=
here are a lot of compilers that don&#39;t, or if they differ greatly on wh=
ich Unicode encodings they take, then there is a clear need to build one in=
to the system.<br><br>A compiler which can only take ASCII is not part of t=
he &quot;de-facto achieved&quot; group. This is not a question of &quot;ASC=
II vs. IBM&#39;s stuff&quot;. It&#39;s &quot;Known Unicode format vs. other=
 things.&quot;<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Maybe if we ask Michael Wong directly for his opinion on this matter, we&#3=
9;ll=20
<br>get somewhere.
<br>
<br>&gt; &gt; Sending files over the network and sharing with other
<br>&gt; &gt; people in other operating systems, with possibly different lo=
cale
<br>&gt; &gt; encodings,
<br>&gt; &gt; is not part of the C++ standard.
<br>&gt; &gt;=20
<br>&gt; &gt; I&#39;m not joking. The standard doesn&#39;t take that into a=
ccount. Sharing files
<br>&gt; &gt; with
<br>&gt; &gt; other people and getting the same compilation requires steppi=
ng outside of
<br>&gt; &gt; the
<br>&gt; &gt; standard and and into compiler-specific territory.
<br>&gt;=20
<br>&gt; That&#39;s true, the standard doesn&#39;t provide any such guarant=
ees.
<br>&gt;=20
<br>&gt; That doesn&#39;t mean that this file inclusion mechanism *shouldn&=
#39;t*. After
<br>&gt; all, the whole point of allowing binary inclusion is to allow peop=
le to be
<br>&gt; able to store literal binary data cross-platform, *exactly* as it =
was in
<br>&gt; the file. With `Fb`, each compiler is required to store the same s=
tream of
<br>&gt; `unsigned char` that would have been read from an untranslated `fo=
pen` or
<br>&gt; `iostream` or whatever.
<br>&gt;=20
<br>&gt; That&#39;s as cross-compiler as it gets.
<br>
<br>Well, you&#39;re assuming that the target platform has bytes the same s=
ize as the=20
<br>host platform that is compiling the source code.</blockquote><div><br>N=
o, I am not. If the host platform can compile to the target platform, then =
the host platform knows the byte size of the target. Otherwise it would be =
unable to convert even a literal string to the target platform&#39;s `char`=
 type. Armed with such knowledge, the host compiler can do whatever interna=
l conversion is needed to make it work as if the target platform loaded it.=
<br><br>The `char` sequence you get from a binary file literal is as if you=
 had read the file through a stream on the target platform. Generating that=
 data is simply a matter of the host doing whatever gymnastics are needed t=
o convert what the host platform sees to what the target platform would hav=
e seen had it read the file.<br><br>I fail to see how this would not be pos=
sible.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The C++ st=
andard cannot=20
<br>guarantee that. That means the only possible solution is &quot;implemen=
tation-
<br>defined&quot;.
<br>
<br>I don&#39;t see the point in making binary files any more sharable than=
 source code=20
<br>itself.<br></blockquote><div><br>You mean besides making it genuinely u=
seful? And stopping people from writing brittle code that works on one plat=
form but doesn&#39;t work on another?<br><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">
&gt; Allowing a way to do this with text, through the use of Unicode, is no=
t a
<br>&gt; bad idea. It would also be a very *useful* idea. And unlike mandat=
ing some
<br>&gt; form of Unicode as the source character set for actual source file=
s, it
<br>&gt; wouldn&#39;t impact any existing systems. Anything could implement=
 it.
<br>
<br>The non-binary file inclusion options are much simpler, indeed.<br></bl=
ockquote></div>

<p></p>

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

------=_Part_2023_1546610672.1462716731437--
------=_Part_2022_1545712657.1462716731429--

.

On domingo, 8 de maio de 2016 07:12:11 PDT Nicol Bolas wrote:
> > Given the discussion about trigraphs, I'm guessing only IBM currently
> > still
> > cares about a non-ASCII encoding of source code.
>=20
> You don't seem to understand the goal here.
>=20
> The goal is for a user to be able to write text file literals that can be
> used with every compiler. This is a very useful thing to be able to do, a=
nd
> if we're going to have file literals, they should be able to be written i=
n
> a platform-neutral. Something that you can actually *rely* upon.

I got that, but I don't see the point in having that if we can't rely on be=
ing=20
able to have platform-neutral source code in the first place.

I don't mean the variants that ask the compiler to interpret as UTF-8, 16 o=
r=20
32. Those are ok. I meant the binary and locale text variants of the litera=
l.

> More fragility is something that C++ can do without.
>
> The question is whether that goal has already been *de-facto* achieved
> through the source character set (based on the default inputs for
> compilers) or whether we need a *de-jure* means of doing so with file
> literals. That's why we want to know about what compilers take. If most
> compilers can accept Unicode strings by default, then whether we need a
> real mechanism is in doubt. But if there are a lot of compilers that don'=
t,
> or if they differ greatly on which Unicode encodings they take, then ther=
e
> is a clear need to build one into the system.

There's no de-facto solution. You cannot share a file that isn't strict US-
ASCII to colleagues and expect it to be compiled the same way, even with=20
modern compilers. You can share US-ASCII files, if you don't count IBM and=
=20
EBCDIC.

To be clear, I mean that this source code does not always produce the same=
=20
string literal:

  auto x =3D u"=C3=A9";

> > Well, you're assuming that the target platform has bytes the same size =
as
> > the
> > host platform that is compiling the source code.
>=20
> No, I am not. If the host platform can compile to the target platform, th=
en
> the host platform knows the byte size of the target. Otherwise it would b=
e
> unable to convert even a literal string to the target platform's `char`
> type. Armed with such knowledge, the host compiler can do whatever intern=
al
> conversion is needed to make it work as if the target platform loaded it.

This was a comment on the binary include. Suppose you're building on a regu=
lar=20
8-bit-byte platform, targetting a 9-bit-byte platform. How are you going to=
=20
represent values 256 to 512 in that byte, in your source file, when you do:

 Fb"data.bin"


> The `char` sequence you get from a binary file literal is as if you had
> read the file through a stream on the target platform. Generating that da=
ta
> is simply a matter of the host doing whatever gymnastics are needed to
> convert what the host platform sees to what the target platform would hav=
e
> seen had it read the file.

Transferring this file to the other platform implies a translation. How the=
=20
translator operates (signed bytes vs unsigned bytes) is not specified.=20
Moreover, files on that other machine may not be representable on the build=
=20
platform.

> > The C++ standard cannot
> > guarantee that. That means the only possible solution is "implementatio=
n-
> > defined".
> >=20
> > I don't see the point in making binary files any more sharable than sou=
rce
> > code
> > itself.
>=20
> You mean besides making it genuinely useful? And stopping people from
> writing brittle code that works on one platform but doesn't work on anoth=
er?

I'm not saying this isn't useful. I'm saying that making the interpretation=
 of=20
locale text files (not binary, not Unicode) as "implementation-defined" suf=
fices,=20
since it would be as useful as sharing code is today.

Summary:

* F"filename" has implementation-defined behaviour because it depends on th=
e=20
  locale charset
* Fu8"filename", Fu"filename", FU"filename" have specific behaviour because=
 the=20
  interpretation of the bytes in each is standardised
* Fb"filename" is 1:1 so long as bytes on the build and target platforms ar=
e=20
  the same. Otherwise, implementation-defined.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

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

On Sun, May 8, 2016 at 8:33 PM, Thiago Macieira <thiago@macieira.org> wrote:

> This was a comment on the binary include. Suppose you're building on a
regular 8-bit-byte platform, targetting a 9-bit-byte platform. How are you
going to represent values 256 to 512 in that byte

"Binary" really means "binary", "made of binary digits", i.e., bits, not
"made of bytes".

Then this "binary include" is a bit stream, and so, logically, it should be
copied into a contiguous region of memory, placing bits "one by one" (this
may need further specification to be fully unambiguous; or this can be
implementation-defined).

Cheers,
V.

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

--001a11c33e6cc5b1fc053259bdab
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 S=
un, May 8, 2016 at 8:33 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><div><br></div><div>&gt; This was a comment on the bina=
ry include. Suppose you&#39;re building on a regular 8-bit-byte platform, t=
argetting a 9-bit-byte platform. How are you going to represent values 256 =
to 512 in that byte</div><div><br></div><div>&quot;Binary&quot; really mean=
s &quot;binary&quot;, &quot;made of binary digits&quot;, i.e., bits, not &q=
uot;made of bytes&quot;.</div><div><br></div><div>Then this &quot;binary in=
clude&quot; is a bit stream, and so, logically, it should be copied into a =
contiguous region of memory, placing bits &quot;one by one&quot; (this may =
need further specification to be fully unambiguous; or this can be implemen=
tation-defined).</div><div><br></div><div>Cheers,</div><div>V.</div><div><b=
r></div></div></div></div>

<p></p>

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

--001a11c33e6cc5b1fc053259bdab--

.

This is a multi-part message in MIME format.
--------------BE775CFB31A0D29F98926D49
Content-Type: text/plain; charset=UTF-8; format=flowed

On 5/8/2016 12:28 AM, Richard Smith wrote:
> On Sat, May 7, 2016 at 6:35 PM, Tom Honermann <tom@honermann.net
> <mailto:tom@honermann.net>> wrote:
>
>     On May 7, 2016, at 5:57 PM, Nicol Bolas <jmckesson@gmail.com
>     <mailto:jmckesson@gmail.com>> wrote:
>     > What is wtutf8? I've never heard of this term
>
>     It's a colloquial term that might be more readily recognized if
>     spelled "wtf utf-8".
>
>     I believe I first heard it used to describe how Clang attempts to
>     interpret file names for presentation purposes (perhaps in
>     diagnostics? Or when generating preprocessing line control
>     directives? I don't recall).
>
>
> I think what you're referring to is WTF-8? (See
> https://simonsapin.github.io/wtf-8/).

So, apparently:

1) I misremembered the term.

2) Given that there is a specification, it isn't a colloquialism.

3) Having now read the specification, I can see that what it describes
is not the behavior exhibited by gcc; wtf-8 addresses lone surrogates,
but not ill-formed code unit sequences as I thought it did.

4) I am an agent of misinformation.

Sorry, and thanks for the link, Richard!

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/adb35290-6a17-e0fc-9b24-5f53b5942356%40honermann.net.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 5/8/2016 12:28 AM, Richard Smith
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAOfiQqkHe6w8p2Dcmde9zgDqDKAOvubxsuuqdnAPrk66j1zm-A@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">On Sat, May 7, 2016 at 6:35 PM, Tom
            Honermann <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@hon=
ermann.net</a>&gt;</span>
            wrote:<br>
            <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"><span
                class=3D"">On May 7, 2016, at 5:57 PM, Nicol Bolas &lt;<a
                  moz-do-not-send=3D"true"
                  href=3D"mailto:jmckesson@gmail.com"><a class=3D"moz-txt-l=
ink-abbreviated" href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a=
></a>&gt;
                wrote:<br>
                &gt; What is wtutf8? I've never heard of this term<br>
                <br>
              </span>It's a colloquial term that might be more readily
              recognized if spelled "wtf utf-8".<br>
              <br>
              I believe I first heard it used to describe how Clang
              attempts to interpret file names for presentation purposes
              (perhaps in diagnostics? Or when generating preprocessing
              line control directives? I don't recall).<br>
            </blockquote>
            <div><br>
            </div>
            <div>I think what you're referring to is WTF-8? (See <a
                moz-do-not-send=3D"true"
                href=3D"https://simonsapin.github.io/wtf-8/"><a class=3D"mo=
z-txt-link-freetext" href=3D"https://simonsapin.github.io/wtf-8/">https://s=
imonsapin.github.io/wtf-8/</a></a>).</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    So, apparently:<br>
    <br>
    1) I misremembered the term.<br>
    <br>
    2) Given that there is a specification, it isn't a colloquialism.<br>
    <br>
    3) Having now read the specification, I can see that what it
    describes is not the behavior exhibited by gcc; wtf-8 addresses lone
    surrogates, but not ill-formed code unit sequences as I thought it
    did.<br>
    <br>
    4) I am an agent of misinformation.<br>
    <br>
    Sorry, and thanks for the link, Richard!<br>
    <br>
    Tom.<br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/adb35290-6a17-e0fc-9b24-5f53b5942356%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/adb35290-6a17-e0fc-9b24-5f53b5942=
356%40honermann.net</a>.<br />

--------------BE775CFB31A0D29F98926D49--

.

On 5/7/2016 7:18 PM, Thiago Macieira wrote:
> Your test was invalid because it contained invalid UTF-8 sequences and my
> editor destroyed them.
The test source code was invalid UTF-8, but that was the point; gcc
still accepted it demonstrating that its default input file encoding is
not (strict) UTF-8.

I hope your editor at least warned you that it was mutating the file ;)
> This discussion is also going off-topic. GCC behaviour should be discussed in
> a GCC mailing list. Sending files over the network and sharing with other
> people in other operating systems, with possibly different locale encodings,
> is not part of the C++ standard.
>
> I'm not joking. The standard doesn't take that into account. Sharing files with
> other people and getting the same compilation requires stepping outside of the
> standard and and into compiler-specific territory.

I think Nicol adequately addressed this, so I won't comment further.

Tom.

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

.

On 2016-05-09 06:33, Thiago Macieira wrote:
>
> This was a comment on the binary include. Suppose you're building on a regular
> 8-bit-byte platform, targetting a 9-bit-byte platform. How are you going to
> represent values 256 to 512 in that byte, in your source file, when you do:
>
>  Fb"data.bin"

This is kind of tangential to the thread, but honestly I think it's time
we started giving serious consideration to giving up making the C++
specification tie itself in knots trying to support platforms where a
byte is not 8 bits.

Ross Smith

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

.

On domingo, 8 de maio de 2016 16:07:53 PDT Tom Honermann wrote:
> On 5/7/2016 7:18 PM, Thiago Macieira wrote:
> > Your test was invalid because it contained invalid UTF-8 sequences and my
> > editor destroyed them.
>
> The test source code was invalid UTF-8, but that was the point; gcc
> still accepted it demonstrating that its default input file encoding is
> not (strict) UTF-8.

GCC tries to be pass-through unless it is forced to interpret the contents
(u8, u & U). And, of course, GIGO.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

On domingo, 8 de maio de 2016 21:31:40 PDT Viacheslav Usov wrote:
> Then this "binary include" is a bit stream, and so, logically, it should be
> copied into a contiguous region of memory, placing bits "one by one" (this
> may need further specification to be fully unambiguous; or this can be
> implementation-defined).

Yeah, except that may not be the way it works. As I said, it depends on how
the file transfer over the network would happen (remember: networks use octets
as units, not bytes).

Then again, this is an academic discussion.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

On segunda-feira, 9 de maio de 2016 09:12:55 PDT Ross Smith wrote:
> On 2016-05-09 06:33, Thiago Macieira wrote:
> > This was a comment on the binary include. Suppose you're building on a
> > regular 8-bit-byte platform, targetting a 9-bit-byte platform. How are
> > you going to>
> > represent values 256 to 512 in that byte, in your source file, when you do:
> >  Fb"data.bin"
>
> This is kind of tangential to the thread, but honestly I think it's time
> we started giving serious consideration to giving up making the C++
> specification tie itself in knots trying to support platforms where a
> byte is not 8 bits.

Agreed. C++14 made it mandatory to be at least 8 bits, which means we've
dropped support for the 6- and 7-bit byte platforms that used to exist. 9-bit
byte platforms also existed, but were even more rare.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

--047d7b3a8f4a787c2f0532637bc5
Content-Type: text/plain; charset=UTF-8

On Mon, May 9, 2016 at 8:10 AM, Thiago Macieira <thiago@macieira.org> wrote:

> Yeah, except that may not be the way it works. As I said, it depends on
how the file transfer over the network would happen (remember: networks use
octets as units, not bytes).

Networks use bits in their lower layers. Bytes and octets happen at higher
layers.

A file can always be represented as a bit stream, and a bit-by-bit
inclusion is always possible. To make this fully unambiguous, we can have
specifiers in the include directive that say how source bytes are converted
to bits (low end vs high end), and how bits are pushed into destination
bytes (ditto). We can even specify padding. Compared with the rest of the
discussion, this is trivial.

Cheers,
V.

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

--047d7b3a8f4a787c2f0532637bc5
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 M=
on, May 9, 2016 at 8:10 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gm=
ail_quote">&gt; Yeah, except that may not be the way it works. As I said, i=
t depends on how the file transfer over the network would happen (remember:=
 networks use octets as units, not bytes).</div><div class=3D"gmail_quote">=
<br></div><div class=3D"gmail_quote">Networks use bits in their lower layer=
s. Bytes and octets happen at higher layers.</div><div class=3D"gmail_quote=
"><br></div><div class=3D"gmail_quote">A file can always be represented as =
a bit stream, and a bit-by-bit inclusion is always possible. To make this f=
ully unambiguous, we can have specifiers in the include directive that say =
how source bytes are converted to bits (low end vs high end), and how bits =
are pushed into destination bytes (ditto). We can even specify padding. Com=
pared with the rest of the discussion, this is trivial.</div><div class=3D"=
gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,</div><div class=
=3D"gmail_quote">V.</div><div class=3D"gmail_quote"><br></div></div></div>

<p></p>

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

--047d7b3a8f4a787c2f0532637bc5--

.

On segunda-feira, 9 de maio de 2016 09:08:57 PDT Viacheslav Usov wrote:
> A file can always be represented as a bit stream, and a bit-by-bit
> inclusion is always possible. To make this fully unambiguous, we can have
> specifiers in the include directive that say how source bytes are converted
> to bits (low end vs high end), and how bits are pushed into destination
> bytes (ditto). We can even specify padding. Compared with the rest of the
> discussion, this is trivial.

I'd rather just leave that part as implementation-defined, since I have
absolutely zero experience with machines with bytes that aren't of 8 bits.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

On 5/8/2016 2:33 PM, Thiago Macieira wrote:
> * F"filename" has implementation-defined behaviour because it depends on the
>    locale charset
> * Fu8"filename", Fu"filename", FU"filename" have specific behaviour because the
>    interpretation of the bytes in each is standardised
> * Fb"filename" is 1:1 so long as bytes on the build and target platforms are
>    the same. Otherwise, implementation-defined.
I agree with the above.  Just to be clear, the above expressions would
have the following types, yes?

* F"filename" -> const char[N]
* Fu8"filename" -> const char[N]
* Fu"filename" -> const char16_t[N]
* FU"filename" -> const char32_t[N]
* Fb"filename" -> const char[N]

Also, as discussed earlier, BOMs present in the Unicode variants would
be removed and all of the variants except for Fb would have a nul
character appended.

The question of whether to require normalization of end of line
sequences remains.  If that isn't specified, then I think the behavior
needs to be implementation-defined for all the above variants.

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/44dcf961-ffac-8aa2-a76a-86e33bc7a225%40honermann.net.

.

On segunda-feira, 9 de maio de 2016 08:29:27 PDT Tom Honermann wrote:
> On 5/8/2016 2:33 PM, Thiago Macieira wrote:
> > * F"filename" has implementation-defined behaviour because it depends on
> > the>
> >    locale charset
> >
> > * Fu8"filename", Fu"filename", FU"filename" have specific behaviour
> > because the>
> >    interpretation of the bytes in each is standardised
> >
> > * Fb"filename" is 1:1 so long as bytes on the build and target platforms
> > are>
> >    the same. Otherwise, implementation-defined.
>
> I agree with the above.  Just to be clear, the above expressions would
> have the following types, yes?
>
> * F"filename" -> const char[N]
> * Fu8"filename" -> const char[N]
> * Fu"filename" -> const char16_t[N]
> * FU"filename" -> const char32_t[N]
> * Fb"filename" -> const char[N]

I was expect all of those to be char[N] and that if I wanted a char16_t, I'd
have to write:

 uF"filename"
 uFu8"filename"
 uFu"filename"
 uFU"filename"

That's mighty ugly. Given my own requirement of being able to constexpr-
transform the input to the format of my liking, if I wanted an UCS-4-encoded
string out of an UTF-8 input source, I'd implement the UTF-8 decoder myself.

> Also, as discussed earlier, BOMs present in the Unicode variants would
> be removed and all of the variants except for Fb would have a nul
> character appended.
>
> The question of whether to require normalization of end of line
> sequences remains.  If that isn't specified, then I think the behavior
> needs to be implementation-defined for all the above variants.

For all non-binary variants, I'd expect line-ending normalisation.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

On 5/9/2016 12:47 PM, Thiago Macieira wrote:
>> * F"filename" -> const char[N]
>> * Fu8"filename" -> const char[N]
>> * Fu"filename" -> const char16_t[N]
>> * FU"filename" -> const char32_t[N]
>> * Fb"filename" -> const char[N]
> I was expect all of those to be char[N]
Hmm.  Would that include transcoding to the source character set for the
Fu8, Fu, and FU variants?  If so, then these would all be inherently
implementation-defined.  If not, then endianness needs to be addressed
for Fu amd FU.
> and that if I wanted a char16_t, I'd
> have to write:
>
>  uF"filename"
>  uFu8"filename"
>  uFu"filename"
>  uFU"filename"
>
> That's mighty ugly. Given my own requirement of being able to constexpr-
> transform the input to the format of my liking, if I wanted an UCS-4-encoded
> string out of an UTF-8 input source, I'd implement the UTF-8 decoder myself.
I think I prefer the match-the-filename-encoding-to-the-string-type
approach I implied above over either of these approaches.  That seems
more consistent with string literals to me anyway.
>
>> Also, as discussed earlier, BOMs present in the Unicode variants would
>> be removed and all of the variants except for Fb would have a nul
>> character appended.
>>
>> The question of whether to require normalization of end of line
>> sequences remains.  If that isn't specified, then I think the behavior
>> needs to be implementation-defined for all the above variants.
> For all non-binary variants, I'd expect line-ending normalisation.
Good, me too.

Tom.

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

.

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

On Mon, May 9, 2016 at 7:21 PM, Tom Honermann <tom@honermann.net> wrote:

> Hmm.  Would that include transcoding to the source character set for the
Fu8, Fu, and FU variants?

I would say that being able to specify transcoding is a useful option. At
least UTF-8 <-> UTF-16 <-> source encoding should just be there, and
source/target encodings should be specifiable separately. Personally, I
find the end-of-line transcoding a misfeature in C/C++ std libs, but, in
principle, it could also be specifiable.

Cheers,
V.

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

--001a113f1d684d7e7705326c5b9a
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 M=
on, May 9, 2016 at 7:21 PM, Tom Honermann <span dir=3D"ltr">&lt;<a href=3D"=
mailto:tom@honermann.net" target=3D"_blank">tom@honermann.net</a>&gt;</span=
> wrote:<br><div><br></div><div>&gt; Hmm.=C2=A0 Would that include transcod=
ing to the source character set for the Fu8, Fu, and FU variants?</div><div=
><br></div><div>I would say that being able to specify transcoding is a use=
ful option. At least UTF-8 &lt;-&gt; UTF-16 &lt;-&gt; source encoding shoul=
d just be there, and source/target encodings should be specifiable separate=
ly. Personally, I find the end-of-line transcoding a misfeature in C/C++ st=
d libs, but, in principle, it could also be specifiable.</div><div><br></di=
v><div>Cheers,</div><div>V.</div><div><br></div></div></div></div>

<p></p>

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

--001a113f1d684d7e7705326c5b9a--

.

On segunda-feira, 9 de maio de 2016 13:21:10 PDT Tom Honermann wrote:
> On 5/9/2016 12:47 PM, Thiago Macieira wrote:
> >> * F"filename" -> const char[N]
> >> * Fu8"filename" -> const char[N]
> >> * Fu"filename" -> const char16_t[N]
> >> * FU"filename" -> const char32_t[N]
> >> * Fb"filename" -> const char[N]
> >
> > I was expect all of those to be char[N]
>
> Hmm.  Would that include transcoding to the source character set for the
> Fu8, Fu, and FU variants?  If so, then these would all be inherently
> implementation-defined.  If not, then endianness needs to be addressed
> for Fu amd FU.

Yes, that was the case. But that's an ugly solution, so I am not asking for
it. Instead, let's have what you suggested and no transcoding. Not even
endianness correction: let the BOM be imported too. You can fix the endianness
and strip the BOM at constexpr time.

What should the compiler do to invalid sources?
 * UTF-8 overlong sequences
 * UTF-8 invalid sequences
 * mismatched UTF-16 surrogate pairs
 * out-of-range UTF-8 and UCS-4

Should it do any validation at all?

> >> Also, as discussed earlier, BOMs present in the Unicode variants would
> >> be removed and all of the variants except for Fb would have a nul
> >> character appended.
> >>
> >> The question of whether to require normalization of end of line
> >> sequences remains.  If that isn't specified, then I think the behavior
> >> needs to be implementation-defined for all the above variants.
> >
> > For all non-binary variants, I'd expect line-ending normalisation.
>
> Good, me too.


--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

On segunda-feira, 9 de maio de 2016 19:44:12 PDT Viacheslav Usov wrote:
> I would say that being able to specify transcoding is a useful option. At
> least UTF-8 <-> UTF-16 <-> source encoding should just be there, and
> source/target encodings should be specifiable separately. Personally, I
> find the end-of-line transcoding a misfeature in C/C++ std libs, but, in
> principle, it could also be specifiable.

You can do that with your own constexpr functions. That's a requirement of
this feature anyway.

As a side note, that's yet another example showing where a constexpr function
should not be used at runtime. At runtime, you want CPU-accelerated functions
to do this kind of transcoding.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

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

On Sun, May 8, 2016 at 11:11 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On segunda-feira, 9 de maio de 2016 09:12:55 PDT Ross Smith wrote:
> > On 2016-05-09 06:33, Thiago Macieira wrote:
> > > This was a comment on the binary include. Suppose you're building on a
> > > regular 8-bit-byte platform, targetting a 9-bit-byte platform. How are
> > > you going to>
> > > represent values 256 to 512 in that byte, in your source file, when
> you do:
> > >     Fb"data.bin"
> >
> > This is kind of tangential to the thread, but honestly I think it's time
> > we started giving serious consideration to giving up making the C++
> > specification tie itself in knots trying to support platforms where a
> > byte is not 8 bits.
>
> Agreed. C++14 made it mandatory to be at least 8 bits,


That's been mandatory since C89.

What C++14 disallowed is char being signed, only 8 bits wide, and either
sign-magnitude or 1's complement (or more generally, as C++ allows
representations other than 2s' complement, 1's complement, and
sign-magnitude, it requires that char has at least 256 distinct values).


> which means we've
> dropped support for the 6- and 7-bit byte platforms that used to exist.
> 9-bit
> byte platforms also existed, but were even more rare.

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

--001a11c13aca9bdd0005326d856f
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 S=
un, May 8, 2016 at 11:11 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</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 segu=
nda-feira, 9 de maio de 2016 09:12:55 PDT Ross Smith wrote:<br>
&gt; On 2016-05-09 06:33, Thiago Macieira wrote:<br>
&gt; &gt; This was a comment on the binary include. Suppose you&#39;re buil=
ding on a<br>
&gt; &gt; regular 8-bit-byte platform, targetting a 9-bit-byte platform. Ho=
w are<br>
&gt; &gt; you going to&gt;<br>
&gt; &gt; represent values 256 to 512 in that byte, in your source file, wh=
en you do:<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0Fb&quot;data.bin&quot;<br>
&gt;<br>
&gt; This is kind of tangential to the thread, but honestly I think it&#39;=
s time<br>
&gt; we started giving serious consideration to giving up making the C++<br=
>
&gt; specification tie itself in knots trying to support platforms where a<=
br>
&gt; byte is not 8 bits.<br>
<br>
</span>Agreed. C++14 made it mandatory to be at least 8 bits,</blockquote><=
div><br></div><div>That&#39;s been mandatory since C89.</div><div><br></div=
><div>What C++14 disallowed is char being signed, only 8 bits wide, and eit=
her sign-magnitude or 1&#39;s complement (or more generally, as C++ allows =
representations other than 2s&#39; complement, 1&#39;s complement, and sign=
-magnitude, it requires that char has at least 256 distinct values).</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">which means we&#39;ve<br>
dropped support for the 6- and 7-bit byte platforms that used to exist. 9-b=
it<br>
byte platforms also existed, but were even more rare.</blockquote></div></d=
iv></div>

<p></p>

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

--001a11c13aca9bdd0005326d856f--

.

On segunda-feira, 9 de maio de 2016 12:07:37 PDT Richard Smith wrote:
> That's been mandatory since C89.
>
> What C++14 disallowed is char being signed, only 8 bits wide, and either
> sign-magnitude or 1's complement (or more generally, as C++ allows
> representations other than 2s' complement, 1's complement, and
> sign-magnitude, it requires that char has at least 256 distinct values).

Thanks for the correction. I hadn't realised the difference.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

On 5/9/2016 2:25 PM, Thiago Macieira wrote:
> On segunda-feira, 9 de maio de 2016 13:21:10 PDT Tom Honermann wrote:
>> On 5/9/2016 12:47 PM, Thiago Macieira wrote:
>>>> * F"filename" -> const char[N]
>>>> * Fu8"filename" -> const char[N]
>>>> * Fu"filename" -> const char16_t[N]
>>>> * FU"filename" -> const char32_t[N]
>>>> * Fb"filename" -> const char[N]
>>> I was expect all of those to be char[N]
>> Hmm.  Would that include transcoding to the source character set for the
>> Fu8, Fu, and FU variants?  If so, then these would all be inherently
>> implementation-defined.  If not, then endianness needs to be addressed
>> for Fu amd FU.
> Yes, that was the case. But that's an ugly solution, so I am not asking for
> it. Instead, let's have what you suggested and no transcoding. Not even
> endianness correction: let the BOM be imported too. You can fix the endianness
> and strip the BOM at constexpr time.

I don't agree with skipping endian conversions and retaining BOMs as I
think that would be antithetical to common usage.  If a user wants to
elide endian conversions and retain BOMs, then the Fb variant is
available to do so.

> What should the compiler do to invalid sources?
>   * UTF-8 overlong sequences
>   * UTF-8 invalid sequences
>   * mismatched UTF-16 surrogate pairs
>   * out-of-range UTF-8 and UCS-4
>
> Should it do any validation at all?

Yes, I think it should validate and reject such ill-formed sources with
a diagnostic.  This would differ from handling of string literals, but
offers better correctness and portability guarantees. There will be no
ability to encode escape sequences or similar "pass-through" code unit
sequences in these sources (I hope, I don't recall anyone proposing such
support), so I see little reason to tolerate files with an ill-formed or
mismatched encoding.  Again, the Fb variant is available to import such
files.

Updated summary:

* F"filename"
   - Result type is const char[N]
   - File encoding is implementation-defined.
   - A non-normative note could mention that end of line sequences are
expected to be replaced with the \n character.
   - A '\0' character is appended following the file content.

* Fu8"filename"
   - Result type is const char[N]
   - Any leading BOM is stripped.
   - An ill-formed code unit sequence results in a diagnostic.
   - Implementation-defined end of line sequences are normalized to u8'\n'.
   - A u8'\0' character is appended following the file content.

* Fu"filename"
   - Result type is const char16_t[N]
   - Any leading BOM is stripped.
   - Endianness is detected if a BOM is present and endian conversion
performed to match the encoding of char16_t string literals.
   - An ill-formed code unit sequence results in a diagnostic.
   - Implementation-defined end of line sequences are normalized to u'\n'.
   - A u'\0' character is appended following the file content.

* FU"filename"
   - Result type is const char32_t[N]
   - Any leading BOM is stripped.
   - Endianness is detected if a BOM is present and endian conversion
performed to match the encoding of char32_t string literals.
   - An ill-formed code unit sequence results in a diagnostic.
   - Implementation-defined end of line sequences are normalized to U'\n'.
   - A U'\0' character is appended following the file content.

* Fb"filename"
   - Result type is const char[N].  Or should it be const unsigned
char[N] ?  I'm leaning towards unsigned char.
   - A NUL character is *not* appended following the file content.
   - Code units have implementation-defined values.
   - A non-normative note could mention that code unit values are
expected to match the byte values of the file, but that this may not be
possible when cross-compiling to a target that has a different byte size
than the local file system.

Tom.

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

.

On 5/9/2016 11:54 PM, Tom Honermann wrote:
> Updated summary:

I guess for completeness, add:

* FL"filename"
   - Result type is const wchar_t[N]
   - File encoding is implementation-defined.
   - A non-normative note could mention that end of line sequences are
expected to be replaced with the L'\n' character.
   - A L'\0' character is appended following the file content.

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6603ddf3-4ae6-a03e-13d3-59f7c7614a78%40honermann.net.

.

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

On Mon, May 9, 2016 at 8:26 PM, Thiago Macieira <thiago@macieira.org> wrote:

> You can do that with your own constexpr functions.

My own transcoding for UTF-8 and UTF-16, in 2017 and later? That's not even
funny.

I could agree that the standard library should have something that works
together with the include directive at the compile time to effect
transcoding that covers at least UTF-8, UTF-16 and the source encoding. But
then this include proposal should be bundled with that library feature.

Cheers,
V.

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

--001a11c3bed05226b40532784482
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 M=
on, May 9, 2016 at 8:26 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><div><br></div><div>&gt; You can do that with your own =
constexpr functions.</div><div><br></div><div>My own transcoding for UTF-8 =
and UTF-16, in 2017 and later? That&#39;s not even funny.</div><div><br></d=
iv><div>I could agree that the standard library should have something that =
works together with the include directive at the compile time to effect tra=
nscoding that covers at least UTF-8, UTF-16 and the source encoding. But th=
en this include proposal should be bundled with that library feature.</div>=
<div><br></div><div>Cheers,</div><div>V.</div></div></div></div>

<p></p>

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

--001a11c3bed05226b40532784482--

.

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

On Tue, May 10, 2016 at 9:56 AM, Viacheslav Usov <via.usov@gmail.com> wrote:

> I could agree that the standard library should have something that works
together with the include directive at the compile time to effect
transcoding that covers at least UTF-8, UTF-16 and the source encoding. But
then this include proposal should be bundled with that library feature.

Scrap it. UTF-8 and UTF-16 transcoding should just be supported by the
directive. If the input is ill-formed, the program shall be ill-formed. If
somebody wants to be smart about that, the binary mode is there.

Cheers,
V.

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

--089e0115f8c62677860532787a3f
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=
ue, May 10, 2016 at 9:56 AM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmai=
l_quote">&gt; I could agree that the standard library should have something=
 that works together with the include directive at the compile time to effe=
ct transcoding that covers at least UTF-8, UTF-16 and the source encoding. =
But then this include proposal should be bundled with that library feature.=
</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Scrap=
 it. UTF-8 and UTF-16 transcoding should just be supported by the directive=
.. If the input is ill-formed, the program shall be ill-formed. If somebody =
wants to be smart about that, the binary mode is there.</div><div class=3D"=
gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,</div><div class=
=3D"gmail_quote">V.</div></div></div>

<p></p>

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

--089e0115f8c62677860532787a3f--

.

On ter=C3=A7a-feira, 10 de maio de 2016 09:56:46 PDT Viacheslav Usov wrote:
> On Mon, May 9, 2016 at 8:26 PM, Thiago Macieira <thiago@macieira.org> wro=
te:
> > You can do that with your own constexpr functions.
>=20
> My own transcoding for UTF-8 and UTF-16, in 2017 and later? That's not ev=
en
> funny.

Indeed. I agree that they should exist in the Standard Library and that you=
=20
should be able to call them in constexpr contexts.

And that it should be fast at runtime. I can see if Intel is ok with making=
 my=20
UTF-8 hardware-accelerated algorithm available under a more permissive lice=
nce=20
as it is today.

> I could agree that the standard library should have something that works
> together with the include directive at the compile time to effect
> transcoding that covers at least UTF-8, UTF-16 and the source encoding. B=
ut
> then this include proposal should be bundled with that library feature.

I don't think that's necessary, strictly speaking.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

On 5/10/2016 1:03 PM, Thiago Macieira wrote:
> On ter=C3=A7a-feira, 10 de maio de 2016 09:56:46 PDT Viacheslav Usov wrot=
e:
>> On Mon, May 9, 2016 at 8:26 PM, Thiago Macieira <thiago@macieira.org> wr=
ote:
>>> You can do that with your own constexpr functions.
>> My own transcoding for UTF-8 and UTF-16, in 2017 and later? That's not e=
ven
>> funny.
> Indeed. I agree that they should exist in the Standard Library and that y=
ou
> should be able to call them in constexpr contexts.

I'm trying to help with that:
P0244R1: Text_view: A C++ concepts and range based character encoding=20
and code point enumeration library
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0244r1.html

Note the first two sections under Future Directions.  If anyone wishes=20
to comment further on this, please start a new email thread.

> And that it should be fast at runtime. I can see if Intel is ok with maki=
ng my
> UTF-8 hardware-accelerated algorithm available under a more permissive li=
cence
> as it is today.

That would be cool.

Tom.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/100e5c85-1287-96e4-2824-b043b1ad5412%40honermann=
..net.

.

On ter=C3=A7a-feira, 10 de maio de 2016 13:18:43 PDT Tom Honermann wrote:
> > And that it should be fast at runtime. I can see if Intel is ok with
> > making my UTF-8 hardware-accelerated algorithm available under a more
> > permissive licence as it is today.
>=20
> That would be cool.

I'll do that only after I see some movement about allowing different code t=
o=20
be run at runtime, compared to constexpr time, for the same function.

std::u16string appendWorld(const char *base)
{
 constexpr auto s =3D convertToUtf16(" World");
 return convertToUtf16(base) + s;
}

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

On 05/06/2016 05:37 PM, Thiago Macieira wrote:
> On sexta-feira, 6 de maio de 2016 11:03:34 PDT Matthew Woehlke wrote:
>>    -finput-charset=CHARSET
>>      Set the input character set, used for translation from the
>>      character set of the input file to the source character set used by
>>      GCC. *If the locale does not specify*, or GCC cannot get this
>>      information from the locale, the default is UTF-8.
>>
>> The *fallback* is UTF-8. The "default" is 'as specified by the current
>> locale'. (At least, that's what the documentation claims; I haven't
>> actually attempted to test it.)
> The documentation is wrong. GCC does not attempt to identify the current
> locale's charset and directly falls back to UTF-8.
>
There is an existing bug to get the documentation updated to remove the
incorrect description with regard to the current locale:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61896

I proposed an update to the documentation to address the behavior
exhibited elsewhere in this email thread.

Tom.

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

.