Topic: Template literal operator for string literals
Author: dobragab@gmail.com
Date: Sat, 12 Nov 2016 13:35:37 -0800 (PST)
Raw View
------=_Part_1947_56297289.1478986537394
Content-Type: multipart/alternative;
boundary="----=_Part_1948_81322018.1478986537395"
------=_Part_1948_81322018.1478986537395
Content-Type: text/plain; charset=UTF-8
My proposal / idea is about possible literal operator definitions.
Given a literal operator for integers, e.g.
Weight w1 = 15_kg;
You can write a literal operator for this in ways:
constexpr Weight operator""_kg(unsigned long long q) {
return Weight{q};
}
Weight operator""_kg(const char * str) {
// ...
}
template<char... CHARS>
constexpr Weight operator""_kg() {
// ...
}
The second one and the third one differs by one important thing: 3rd allows
us to process integer literals by individual characters in compile time. If
you write
0x7b_kg
Then you get '0', 'x', '7', 'b' characters as you expect.
But if you want to write a literal operator for a string literal, you have
only one option:
std::string operator""_x(const char * str, std::size_t len) {
// ...
}
Which is quite illogical. We have the option for integer literals to parse
them as either template<char...> or const char*, but we are denied to be
able to parse strings at compile time...
I propose there should be an option like this for string literals as well.
template<char... CHARS, std::size_t LEN>
std::string operator""x() {
// ...
}
or maybe
template<char... CHARS>
std::string operator""x(std::size_t len) {
// ...
}
Obviously, the final goal is to have something like this, without having to
specify the characters individually, initialized with a beautiful string
literal and a helper literal operator.
template<char... CHARS>
struct constexpr_str
{
static constexpr char const value[] = {CHARS..., '\0'};
};
What do you think?
--
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/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org.
------=_Part_1948_81322018.1478986537395
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>My proposal / idea is about possible literal operator=
definitions.</div><div><br></div><div>Given a literal operator for integer=
s, e.g.=C2=A0<br></div><div><font face=3D"courier new, monospace">Weight w1=
=3D 15_kg;</font></div><div><br></div><div>You can write a literal operato=
r for this in ways:</div><div><br></div><div><font face=3D"courier new, mon=
ospace">constexpr Weight operator""_kg(unsigned long long q) {</f=
ont></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 return W=
eight{q};</font></div><div><font face=3D"courier new, monospace">}</font></=
div><div><font face=3D"courier new, monospace"><br></font></div><div><div><=
span style=3D"font-family: "courier new", monospace;">Weight oper=
ator""_kg(const char * str) {</span><br></div><div><font face=3D"=
courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D=
"courier new, monospace">}</font></div></div><div><br></div><div><font face=
=3D"courier new, monospace">template<char... CHARS></font></div><div>=
<font face=3D"courier new, monospace">constexpr Weight operator""=
_kg() {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 // ...</font></div><div><font face=3D"courier new, monospace">}</font><=
/div><div><br></div><div>The second one and the third one differs by one im=
portant thing: 3rd allows us to process integer literals by individual char=
acters in compile time. If you write</div><div><font face=3D"courier new, m=
onospace">0x7b_kg</font></div><div><br></div><div>Then you get <font face=
=3D"courier new, monospace">'0', 'x', '7', 'b&#=
39;</font> characters as you expect.</div><div><br></div><div>But if you wa=
nt to write a literal operator for a string literal, you have only one opti=
on:</div><div><br></div><div><div><span style=3D"font-family: "courier=
new", monospace;">std::string operator""_x(const char * str=
, std::size_t len) {</span><br></div><div><font face=3D"courier new, monosp=
ace">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier new, monos=
pace">}</font></div></div><div><br></div><div>Which is quite illogical. We =
have the option for integer literals to parse them as either <font face=3D"=
courier new, monospace">template<char...></font> or <font face=3D"cou=
rier new, monospace">const char*</font>, but we are denied to be able to pa=
rse strings at compile time...=C2=A0</div><div><br></div><div>I propose the=
re should be an option like this for string literals as well.</div><div><br=
></div><div><div><font face=3D"courier new, monospace">template<char... =
CHARS, std::size_t LEN></font></div><div><font face=3D"courier new, mono=
space">std::string operator""x() {</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=
=3D"courier new, monospace">}</font></div></div><div><br></div><div>or mayb=
e</div><div><br></div><div><div><font face=3D"courier new, monospace">templ=
ate<char... CHARS></font></div><div><font face=3D"courier new, monosp=
ace">std::string operator""x</font><span style=3D"font-family: &q=
uot;courier new", monospace;">(</span><span style=3D"font-family: &quo=
t;courier new", monospace;">std::size_t len</span><span style=3D"font-=
family: "courier new", monospace;">) {</span></div><div><font fac=
e=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font fa=
ce=3D"courier new, monospace">}</font></div></div><div><br></div><div>Obvio=
usly, the final goal is to have something like this, without having to spec=
ify the characters individually, initialized with a beautiful string litera=
l and a helper literal operator.</div><div><br></div><div><div><font face=
=3D"courier new, monospace">template<char... CHARS></font></div><div>=
<font face=3D"courier new, monospace">struct constexpr_str</font></div><div=
><font face=3D"courier new, monospace">{</font></div><div><font face=3D"cou=
rier new, monospace">=C2=A0 =C2=A0 static constexpr char const value[] =3D =
{CHARS..., '\0'};</font></div><div><font face=3D"courier new, monos=
pace">};</font></div></div><div><br></div><div>What do you think?</div></di=
v>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/34f510eb-9b14-4e5f-9485-761f71476eaf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf=
%40isocpp.org</a>.<br />
------=_Part_1948_81322018.1478986537395--
------=_Part_1947_56297289.1478986537394--
.
Author: Chris DeVisser <chris.n.devisser@gmail.com>
Date: Sat, 12 Nov 2016 17:00:26 -0500
Raw View
--001a1142e6b2291cf7054121bd56
Content-Type: text/plain; charset=UTF-8
Your best bet here would be to support P0424
<https://github.com/ldionne/wg21/blob/master/generated/P0424R1.pdf>, where
Louis Dionne has argued for this. If you want to use this today, GCC and
Clang have implemented it as an extension.
On Sat, Nov 12, 2016 at 4:35 PM, <dobragab@gmail.com> wrote:
> My proposal / idea is about possible literal operator definitions.
>
> Given a literal operator for integers, e.g.
> Weight w1 = 15_kg;
>
> You can write a literal operator for this in ways:
>
> constexpr Weight operator""_kg(unsigned long long q) {
> return Weight{q};
> }
>
> Weight operator""_kg(const char * str) {
> // ...
> }
>
> template<char... CHARS>
> constexpr Weight operator""_kg() {
> // ...
> }
>
> The second one and the third one differs by one important thing: 3rd
> allows us to process integer literals by individual characters in compile
> time. If you write
> 0x7b_kg
>
> Then you get '0', 'x', '7', 'b' characters as you expect.
>
> But if you want to write a literal operator for a string literal, you have
> only one option:
>
> std::string operator""_x(const char * str, std::size_t len) {
> // ...
> }
>
> Which is quite illogical. We have the option for integer literals to parse
> them as either template<char...> or const char*, but we are denied to be
> able to parse strings at compile time...
>
> I propose there should be an option like this for string literals as well.
>
> template<char... CHARS, std::size_t LEN>
> std::string operator""x() {
> // ...
> }
>
> or maybe
>
> template<char... CHARS>
> std::string operator""x(std::size_t len) {
> // ...
> }
>
> Obviously, the final goal is to have something like this, without having
> to specify the characters individually, initialized with a beautiful string
> literal and a helper literal operator.
>
> template<char... CHARS>
> struct constexpr_str
> {
> static constexpr char const value[] = {CHARS..., '\0'};
> };
>
> What do you think?
>
> --
> 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/34f510eb-9b14-4e5f-
> 9485-761f71476eaf%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM6NJy5Tcet33xbikodcOGzXhzozcDqd%3DEX7pAUpH3hWkSoNvA%40mail.gmail.com.
--001a1142e6b2291cf7054121bd56
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Your best bet here would be to support=C2=A0<a href=3D"htt=
ps://github.com/ldionne/wg21/blob/master/generated/P0424R1.pdf">P0424</a>, =
where Louis Dionne has argued for this. If you want to use this today, GCC =
and Clang have implemented it as an extension.</div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Sat, Nov 12, 2016 at 4:35 PM, <span =
dir=3D"ltr"><<a href=3D"mailto:dobragab@gmail.com" target=3D"_blank">dob=
ragab@gmail.com</a>></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>My proposal / idea is about possible literal operator de=
finitions.</div><div><br></div><div>Given a literal operator for integers, =
e.g.=C2=A0<br></div><div><font face=3D"courier new, monospace">Weight w1 =
=3D 15_kg;</font></div><div><br></div><div>You can write a literal operator=
for this in ways:</div><div><br></div><div><font face=3D"courier new, mono=
space">constexpr Weight operator""_kg(unsigned long long q) {</fo=
nt></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 return We=
ight{q};</font></div><div><font face=3D"courier new, monospace">}</font></d=
iv><div><font face=3D"courier new, monospace"><br></font></div><div><div><s=
pan style=3D"font-family:"courier new",monospace">Weight operator=
""_kg(const char * str) {</span><br></div><div><font face=3D"cour=
ier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"cou=
rier new, monospace">}</font></div></div><div><br></div><div><font face=3D"=
courier new, monospace">template<char... CHARS></font></div><div><fon=
t face=3D"courier new, monospace">constexpr Weight operator""_kg(=
) {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 //=
...</font></div><div><font face=3D"courier new, monospace">}</font></div><=
div><br></div><div>The second one and the third one differs by one importan=
t thing: 3rd allows us to process integer literals by individual characters=
in compile time. If you write</div><div><font face=3D"courier new, monospa=
ce">0x7b_kg</font></div><div><br></div><div>Then you get <font face=3D"cour=
ier new, monospace">'0', 'x', '7', 'b'</fon=
t> characters as you expect.</div><div><br></div><div>But if you want to wr=
ite a literal operator for a string literal, you have only one option:</div=
><div><br></div><div><div><span style=3D"font-family:"courier new"=
;,monospace">std::string operator""_x(const char * str, std::size=
_t len) {</span><br></div><div><font face=3D"courier new, monospace">=C2=A0=
=C2=A0 // ...</font></div><div><font face=3D"courier new, monospace">}</fo=
nt></div></div><div><br></div><div>Which is quite illogical. We have the op=
tion for integer literals to parse them as either <font face=3D"courier new=
, monospace">template<char...></font> or <font face=3D"courier new, m=
onospace">const char*</font>, but we are denied to be able to parse strings=
at compile time...=C2=A0</div><div><br></div><div>I propose there should b=
e an option like this for string literals as well.</div><div><br></div><div=
><div><font face=3D"courier new, monospace">template<char... CHARS, std:=
:size_t LEN></font></div><div><font face=3D"courier new, monospace">std:=
:string operator""x() {</font></div><div><font face=3D"courier ne=
w, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier n=
ew, monospace">}</font></div></div><div><br></div><div>or maybe</div><div><=
br></div><div><div><font face=3D"courier new, monospace">template<char..=
.. CHARS></font></div><div><font face=3D"courier new, monospace">std::str=
ing operator""x</font><span style=3D"font-family:"courier ne=
w",monospace">(</span><span style=3D"font-family:"courier new&quo=
t;,monospace">std::size_t len</span><span style=3D"font-family:"courie=
r new",monospace">) {</span></div><div><font face=3D"courier new, mono=
space">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier new, mon=
ospace">}</font></div></div><div><br></div><div>Obviously, the final goal i=
s to have something like this, without having to specify the characters ind=
ividually, initialized with a beautiful string literal and a helper literal=
operator.</div><div><br></div><div><div><font face=3D"courier new, monospa=
ce">template<char... CHARS></font></div><div><font face=3D"courier ne=
w, monospace">struct constexpr_str</font></div><div><font face=3D"courier n=
ew, monospace">{</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 static constexpr char const value[] =3D {CHARS..., '\0'}=
;</font></div><div><font face=3D"courier new, monospace">};</font></div></d=
iv><div><br></div><div>What do you think?</div></div><span class=3D"HOEnZb"=
><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/34f5=
10eb-9b14-4e5f-<wbr>9485-761f71476eaf%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAM6NJy5Tcet33xbikodcOGzXhzozcDqd%3DE=
X7pAUpH3hWkSoNvA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM6NJy5Tcet33x=
bikodcOGzXhzozcDqd%3DEX7pAUpH3hWkSoNvA%40mail.gmail.com</a>.<br />
--001a1142e6b2291cf7054121bd56--
.
Author: dobragab@gmail.com
Date: Sat, 12 Nov 2016 14:05:19 -0800 (PST)
Raw View
------=_Part_1797_903859774.1478988319143
Content-Type: multipart/alternative;
boundary="----=_Part_1798_345194765.1478988319143"
------=_Part_1798_345194765.1478988319143
Content-Type: text/plain; charset=UTF-8
Thanks, this is what I'm looking for, didn't know this existed. :)
Do you think this is going to get into standard someday? I hate using
nonstandard extensions, but soon-to-be-standard solutions are acceptable
for me.
On Saturday, November 12, 2016 at 11:00:48 PM UTC+1, Chris DeVisser wrote:
>
> Your best bet here would be to support P0424
> <https://github.com/ldionne/wg21/blob/master/generated/P0424R1.pdf>,
> where Louis Dionne has argued for this. If you want to use this today, GCC
> and Clang have implemented it as an extension.
>
> On Sat, Nov 12, 2016 at 4:35 PM, <dobr...@gmail.com <javascript:>> wrote:
>
>> My proposal / idea is about possible literal operator definitions.
>>
>> Given a literal operator for integers, e.g.
>> Weight w1 = 15_kg;
>>
>> You can write a literal operator for this in ways:
>>
>> constexpr Weight operator""_kg(unsigned long long q) {
>> return Weight{q};
>> }
>>
>> Weight operator""_kg(const char * str) {
>> // ...
>> }
>>
>> template<char... CHARS>
>> constexpr Weight operator""_kg() {
>> // ...
>> }
>>
>> The second one and the third one differs by one important thing: 3rd
>> allows us to process integer literals by individual characters in compile
>> time. If you write
>> 0x7b_kg
>>
>> Then you get '0', 'x', '7', 'b' characters as you expect.
>>
>> But if you want to write a literal operator for a string literal, you
>> have only one option:
>>
>> std::string operator""_x(const char * str, std::size_t len) {
>> // ...
>> }
>>
>> Which is quite illogical. We have the option for integer literals to
>> parse them as either template<char...> or const char*, but we are denied
>> to be able to parse strings at compile time...
>>
>> I propose there should be an option like this for string literals as well.
>>
>> template<char... CHARS, std::size_t LEN>
>> std::string operator""x() {
>> // ...
>> }
>>
>> or maybe
>>
>> template<char... CHARS>
>> std::string operator""x(std::size_t len) {
>> // ...
>> }
>>
>> Obviously, the final goal is to have something like this, without having
>> to specify the characters individually, initialized with a beautiful string
>> literal and a helper literal operator.
>>
>> template<char... CHARS>
>> struct constexpr_str
>> {
>> static constexpr char const value[] = {CHARS..., '\0'};
>> };
>>
>> What do you think?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40isocpp.org.
------=_Part_1798_345194765.1478988319143
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks, this is what I'm looking for, didn't know =
this existed. :)<div><br></div><div>Do you think this is going to get into =
standard someday? I hate using nonstandard extensions, but soon-to-be-stand=
ard solutions are acceptable for me.<br><br>On Saturday, November 12, 2016 =
at 11:00:48 PM UTC+1, Chris DeVisser 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">Your best bet here would be to support=C2=A0<=
a href=3D"https://github.com/ldionne/wg21/blob/master/generated/P0424R1.pdf=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fldionne%2Fwg21%2Fblob%=
2Fmaster%2Fgenerated%2FP0424R1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
EWjiKPrC1X1MBz_eys_rMejH0BhQ';return true;" onclick=3D"this.href=3D'=
;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fldionne%2Fwg21%=
2Fblob%2Fmaster%2Fgenerated%2FP0424R1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEWjiKPrC1X1MBz_eys_rMejH0BhQ';return true;">P0424</a>, where Lou=
is Dionne has argued for this. If you want to use this today, GCC and Clang=
have implemented it as an extension.</div><div><br><div class=3D"gmail_quo=
te">On Sat, Nov 12, 2016 at 4:35 PM, <span dir=3D"ltr"><<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"9K8obaQpCAAJ" rel=3D"no=
follow" onmousedown=3D"this.href=3D'javascript:';return true;" oncl=
ick=3D"this.href=3D'javascript:';return true;">dobr...@gmail.com</a=
>></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=
>My proposal / idea is about possible literal operator definitions.</div><d=
iv><br></div><div>Given a literal operator for integers, e.g.=C2=A0<br></di=
v><div><font face=3D"courier new, monospace">Weight w1 =3D 15_kg;</font></d=
iv><div><br></div><div>You can write a literal operator for this in ways:</=
div><div><br></div><div><font face=3D"courier new, monospace">constexpr Wei=
ght operator""_kg(unsigned long long q) {</font></div><div><font =
face=3D"courier new, monospace">=C2=A0 =C2=A0 return Weight{q};</font></div=
><div><font face=3D"courier new, monospace">}</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><div><span style=3D"font-=
family:"courier new",monospace">Weight operator""_kg(co=
nst char * str) {</span><br></div><div><font face=3D"courier new, monospace=
">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier new, monospac=
e">}</font></div></div><div><br></div><div><font face=3D"courier new, monos=
pace">template<char... CHARS></font></div><div><font face=3D"courier =
new, monospace">constexpr Weight operator""_kg() {</font></div><d=
iv><font face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><=
div><font face=3D"courier new, monospace">}</font></div><div><br></div><div=
>The second one and the third one differs by one important thing: 3rd allow=
s us to process integer literals by individual characters in compile time. =
If you write</div><div><font face=3D"courier new, monospace">0x7b_kg</font>=
</div><div><br></div><div>Then you get <font face=3D"courier new, monospace=
">'0', 'x', '7', 'b'</font> characters as y=
ou expect.</div><div><br></div><div>But if you want to write a literal oper=
ator for a string literal, you have only one option:</div><div><br></div><d=
iv><div><span style=3D"font-family:"courier new",monospace">std::=
string operator""_x(const char * str, std::size_t len) {</span><b=
r></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</fo=
nt></div><div><font face=3D"courier new, monospace">}</font></div></div><di=
v><br></div><div>Which is quite illogical. We have the option for integer l=
iterals to parse them as either <font face=3D"courier new, monospace">templ=
ate<char...></font> or <font face=3D"courier new, monospace">const ch=
ar*</font>, but we are denied to be able to parse strings at compile time..=
..=C2=A0</div><div><br></div><div>I propose there should be an option like t=
his for string literals as well.</div><div><br></div><div><div><font face=
=3D"courier new, monospace">template<char... CHARS, std::size_t LEN><=
/font></div><div><font face=3D"courier new, monospace">std::string operator=
""x() {</font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier new, monospace"=
>}</font></div></div><div><br></div><div>or maybe</div><div><br></div><div>=
<div><font face=3D"courier new, monospace">template<char... CHARS></f=
ont></div><div><font face=3D"courier new, monospace">std::string operator&q=
uot;"x</font><span style=3D"font-family:"courier new",monosp=
ace">(</span><span style=3D"font-family:"courier new",monospace">=
std::size_t len</span><span style=3D"font-family:"courier new",mo=
nospace">) {</span></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 // ...</font></div><div><font face=3D"courier new, monospace">}</fon=
t></div></div><div><br></div><div>Obviously, the final goal is to have some=
thing like this, without having to specify the characters individually, ini=
tialized with a beautiful string literal and a helper literal operator.</di=
v><div><br></div><div><div><font face=3D"courier new, monospace">template&l=
t;char... CHARS></font></div><div><font face=3D"courier new, monospace">=
struct constexpr_str</font></div><div><font face=3D"courier new, monospace"=
>{</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 sta=
tic constexpr char const value[] =3D {CHARS..., '\0'};</font></div>=
<div><font face=3D"courier new, monospace">};</font></div></div><div><br></=
div><div>What do you think?</div></div><span><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
9K8obaQpCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"9K8obaQpCAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/34f510eb-9b14-4e5f-9485-761f71476eaf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/34f510eb-9b14-4e5f-<wbr>9485-=
761f71476eaf%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/1f1dca69-760e-49e3-8346-942c67abcf46%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46=
%40isocpp.org</a>.<br />
------=_Part_1798_345194765.1478988319143--
------=_Part_1797_903859774.1478988319143--
.
Author: Chris DeVisser <chris.n.devisser@gmail.com>
Date: Sat, 12 Nov 2016 17:09:21 -0500
Raw View
--001a1141caec07f97c054121dd03
Content-Type: text/plain; charset=UTF-8
I think it's a reasonable addition, but I have not heard anything about the
paper beyond the proposal, so it's hard to say how it will do. It certainly
won't be in C++17 if that's what you were hoping for, but I'd say it has a
shot at C++20.
On Sat, Nov 12, 2016 at 5:05 PM, <dobragab@gmail.com> wrote:
> Thanks, this is what I'm looking for, didn't know this existed. :)
>
> Do you think this is going to get into standard someday? I hate using
> nonstandard extensions, but soon-to-be-standard solutions are acceptable
> for me.
>
> On Saturday, November 12, 2016 at 11:00:48 PM UTC+1, Chris DeVisser wrote:
>>
>> Your best bet here would be to support P0424
>> <https://github.com/ldionne/wg21/blob/master/generated/P0424R1.pdf>,
>> where Louis Dionne has argued for this. If you want to use this today, GCC
>> and Clang have implemented it as an extension.
>>
>> On Sat, Nov 12, 2016 at 4:35 PM, <dobr...@gmail.com> wrote:
>>
>>> My proposal / idea is about possible literal operator definitions.
>>>
>>> Given a literal operator for integers, e.g.
>>> Weight w1 = 15_kg;
>>>
>>> You can write a literal operator for this in ways:
>>>
>>> constexpr Weight operator""_kg(unsigned long long q) {
>>> return Weight{q};
>>> }
>>>
>>> Weight operator""_kg(const char * str) {
>>> // ...
>>> }
>>>
>>> template<char... CHARS>
>>> constexpr Weight operator""_kg() {
>>> // ...
>>> }
>>>
>>> The second one and the third one differs by one important thing: 3rd
>>> allows us to process integer literals by individual characters in compile
>>> time. If you write
>>> 0x7b_kg
>>>
>>> Then you get '0', 'x', '7', 'b' characters as you expect.
>>>
>>> But if you want to write a literal operator for a string literal, you
>>> have only one option:
>>>
>>> std::string operator""_x(const char * str, std::size_t len) {
>>> // ...
>>> }
>>>
>>> Which is quite illogical. We have the option for integer literals to
>>> parse them as either template<char...> or const char*, but we are
>>> denied to be able to parse strings at compile time...
>>>
>>> I propose there should be an option like this for string literals as
>>> well.
>>>
>>> template<char... CHARS, std::size_t LEN>
>>> std::string operator""x() {
>>> // ...
>>> }
>>>
>>> or maybe
>>>
>>> template<char... CHARS>
>>> std::string operator""x(std::size_t len) {
>>> // ...
>>> }
>>>
>>> Obviously, the final goal is to have something like this, without having
>>> to specify the characters individually, initialized with a beautiful string
>>> literal and a helper literal operator.
>>>
>>> template<char... CHARS>
>>> struct constexpr_str
>>> {
>>> static constexpr char const value[] = {CHARS..., '\0'};
>>> };
>>>
>>> What do you think?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-
>>> 761f71476eaf%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-
> 8346-942c67abcf46%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM6NJy4mxWsDOPubxJ%2BO1gJMdFKmnO2Sro_SpEsPPUFnvN_B6w%40mail.gmail.com.
--001a1141caec07f97c054121dd03
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think it's a reasonable addition, but I have not hea=
rd anything about the paper beyond the proposal, so it's hard to say ho=
w it will do. It certainly won't be in C++17 if that's what you wer=
e hoping for, but I'd say it has a shot at C++20.</div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Sat, Nov 12, 2016 at 5:05 PM, =
<span dir=3D"ltr"><<a href=3D"mailto:dobragab@gmail.com" target=3D"_bla=
nk">dobragab@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">Thanks, this is what I'm looking for, didn't k=
now this existed. :)<div><br></div><div>Do you think this is going to get i=
nto standard someday? I hate using nonstandard extensions, but soon-to-be-s=
tandard solutions are acceptable for me.<span class=3D""><br><br>On Saturda=
y, November 12, 2016 at 11:00:48 PM UTC+1, Chris DeVisser wrote:</span><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr">Your =
best bet here would be to support=C2=A0<a href=3D"https://github.com/ldionn=
e/wg21/blob/master/generated/P0424R1.pdf" rel=3D"nofollow" target=3D"_blank=
">P0424</a>, where Louis Dionne has argued for this. If you want to use thi=
s today, GCC and Clang have implemented it as an extension.</div></span><di=
v><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Sat, Nov 12, 201=
6 at 4:35 PM, <span dir=3D"ltr"><<a rel=3D"nofollow">dobr...@gmail.com<=
/a>></span> wrote:<br></div></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><d=
iv class=3D"h5"><div dir=3D"ltr"><div>My proposal / idea is about possible =
literal operator definitions.</div><div><br></div><div>Given a literal oper=
ator for integers, e.g.=C2=A0<br></div><div><font face=3D"courier new, mono=
space">Weight w1 =3D 15_kg;</font></div><div><br></div><div>You can write a=
literal operator for this in ways:</div><div><br></div><div><font face=3D"=
courier new, monospace">constexpr Weight operator""_kg(unsigned l=
ong long q) {</font></div><div><font face=3D"courier new, monospace">=C2=A0=
=C2=A0 return Weight{q};</font></div><div><font face=3D"courier new, monos=
pace">}</font></div><div><font face=3D"courier new, monospace"><br></font><=
/div><div><div><span style=3D"font-family:"courier new",monospace=
">Weight operator""_kg(const char * str) {</span><br></div><div><=
font face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div>=
<font face=3D"courier new, monospace">}</font></div></div><div><br></div><d=
iv><font face=3D"courier new, monospace">template<char... CHARS></fon=
t></div><div><font face=3D"courier new, monospace">constexpr Weight operato=
r""_kg() {</font></div><div><font face=3D"courier new, monospace"=
>=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier new, monospace=
">}</font></div><div><br></div><div>The second one and the third one differ=
s by one important thing: 3rd allows us to process integer literals by indi=
vidual characters in compile time. If you write</div><div><font face=3D"cou=
rier new, monospace">0x7b_kg</font></div><div><br></div><div>Then you get <=
font face=3D"courier new, monospace">'0', 'x', '7',=
'b'</font> characters as you expect.</div><div><br></div><div>But =
if you want to write a literal operator for a string literal, you have only=
one option:</div><div><br></div><div><div><span style=3D"font-family:"=
;courier new",monospace">std::string operator""_x(const char=
* str, std::size_t len) {</span><br></div><div><font face=3D"courier new, =
monospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier new,=
monospace">}</font></div></div><div><br></div><div>Which is quite illogica=
l. We have the option for integer literals to parse them as either <font fa=
ce=3D"courier new, monospace">template<char...></font> or <font face=
=3D"courier new, monospace">const char*</font>, but we are denied to be abl=
e to parse strings at compile time...=C2=A0</div><div><br></div><div>I prop=
ose there should be an option like this for string literals as well.</div><=
div><br></div><div><div><font face=3D"courier new, monospace">template<c=
har... CHARS, std::size_t LEN></font></div><div><font face=3D"courier ne=
w, monospace">std::string operator""x() {</font></div><div><font =
face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font=
face=3D"courier new, monospace">}</font></div></div><div><br></div><div>or=
maybe</div><div><br></div><div><div><font face=3D"courier new, monospace">=
template<char... CHARS></font></div><div><font face=3D"courier new, m=
onospace">std::string operator""x</font><span style=3D"font-famil=
y:"courier new",monospace">(</span><span style=3D"font-family:&qu=
ot;courier new",monospace">std::size_t len</span><span style=3D"font-f=
amily:"courier new",monospace">) {</span></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=
=3D"courier new, monospace">}</font></div></div><div><br></div><div>Obvious=
ly, the final goal is to have something like this, without having to specif=
y the characters individually, initialized with a beautiful string literal =
and a helper literal operator.</div><div><br></div><div><div><font face=3D"=
courier new, monospace">template<char... CHARS></font></div><div><fon=
t face=3D"courier new, monospace">struct constexpr_str</font></div><div><fo=
nt face=3D"courier new, monospace">{</font></div><div><font face=3D"courier=
new, monospace">=C2=A0 =C2=A0 static constexpr char const value[] =3D {CHA=
RS..., '\0'};</font></div><div><font face=3D"courier new, monospace=
">};</font></div></div><div><br></div><div>What do you think?</div></div></=
div></div><span><font color=3D"#888888"><div><div class=3D"h5">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/34f510eb-9b14-4e5f-9485-<wbr>761f71476eaf%40isocpp.org</a>.<br=
>
</span></font></span></blockquote></div><br></div>
</blockquote></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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@<wbr>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/1f1dca69-760e-49e3-8346-942c67abcf46%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1f1d=
ca69-760e-49e3-<wbr>8346-942c67abcf46%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAM6NJy4mxWsDOPubxJ%2BO1gJMdFKmnO2Sro=
_SpEsPPUFnvN_B6w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM6NJy4mxWsDOP=
ubxJ%2BO1gJMdFKmnO2Sro_SpEsPPUFnvN_B6w%40mail.gmail.com</a>.<br />
--001a1141caec07f97c054121dd03--
.
Author: dobragab@gmail.com
Date: Sat, 12 Nov 2016 15:12:19 -0800 (PST)
Raw View
------=_Part_918_2013169798.1478992339729
Content-Type: multipart/alternative;
boundary="----=_Part_919_903537341.1478992339729"
------=_Part_919_903537341.1478992339729
Content-Type: text/plain; charset=UTF-8
I knew new features of C++17 have been fixed, so I was not hoping for that.
It would be awesome if we had this, thank you for your answers.
How can I use this in GCC / Clang?
On Saturday, November 12, 2016 at 11:09:43 PM UTC+1, Chris DeVisser wrote:
>
> I think it's a reasonable addition, but I have not heard anything about
> the paper beyond the proposal, so it's hard to say how it will do. It
> certainly won't be in C++17 if that's what you were hoping for, but I'd say
> it has a shot at C++20.
>
> On Sat, Nov 12, 2016 at 5:05 PM, <dobr...@gmail.com <javascript:>> wrote:
>
>> Thanks, this is what I'm looking for, didn't know this existed. :)
>>
>> Do you think this is going to get into standard someday? I hate using
>> nonstandard extensions, but soon-to-be-standard solutions are acceptable
>> for me.
>>
>> On Saturday, November 12, 2016 at 11:00:48 PM UTC+1, Chris DeVisser wrote:
>>>
>>> Your best bet here would be to support P0424
>>> <https://github.com/ldionne/wg21/blob/master/generated/P0424R1.pdf>,
>>> where Louis Dionne has argued for this. If you want to use this today, GCC
>>> and Clang have implemented it as an extension.
>>>
>>> On Sat, Nov 12, 2016 at 4:35 PM, <dobr...@gmail.com> wrote:
>>>
>>>> My proposal / idea is about possible literal operator definitions.
>>>>
>>>> Given a literal operator for integers, e.g.
>>>> Weight w1 = 15_kg;
>>>>
>>>> You can write a literal operator for this in ways:
>>>>
>>>> constexpr Weight operator""_kg(unsigned long long q) {
>>>> return Weight{q};
>>>> }
>>>>
>>>> Weight operator""_kg(const char * str) {
>>>> // ...
>>>> }
>>>>
>>>> template<char... CHARS>
>>>> constexpr Weight operator""_kg() {
>>>> // ...
>>>> }
>>>>
>>>> The second one and the third one differs by one important thing: 3rd
>>>> allows us to process integer literals by individual characters in compile
>>>> time. If you write
>>>> 0x7b_kg
>>>>
>>>> Then you get '0', 'x', '7', 'b' characters as you expect.
>>>>
>>>> But if you want to write a literal operator for a string literal, you
>>>> have only one option:
>>>>
>>>> std::string operator""_x(const char * str, std::size_t len) {
>>>> // ...
>>>> }
>>>>
>>>> Which is quite illogical. We have the option for integer literals to
>>>> parse them as either template<char...> or const char*, but we are
>>>> denied to be able to parse strings at compile time...
>>>>
>>>> I propose there should be an option like this for string literals as
>>>> well.
>>>>
>>>> template<char... CHARS, std::size_t LEN>
>>>> std::string operator""x() {
>>>> // ...
>>>> }
>>>>
>>>> or maybe
>>>>
>>>> template<char... CHARS>
>>>> std::string operator""x(std::size_t len) {
>>>> // ...
>>>> }
>>>>
>>>> Obviously, the final goal is to have something like this, without
>>>> having to specify the characters individually, initialized with a beautiful
>>>> string literal and a helper literal operator.
>>>>
>>>> template<char... CHARS>
>>>> struct constexpr_str
>>>> {
>>>> static constexpr char const value[] = {CHARS..., '\0'};
>>>> };
>>>>
>>>> What do you think?
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/170a234f-dfc0-43ad-9909-306ce3ab4eeb%40isocpp.org.
------=_Part_919_903537341.1478992339729
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I knew new features of C++17 have been fixed, so I was not=
hoping for that. It would be awesome if we had this, thank you for your an=
swers.<div><br></div><div>How can I use this in GCC / Clang?<br><div><br>On=
Saturday, November 12, 2016 at 11:09:43 PM UTC+1, Chris DeVisser wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I think it's=
a reasonable addition, but I have not heard anything about the paper beyon=
d the proposal, so it's hard to say how it will do. It certainly won=
9;t be in C++17 if that's what you were hoping for, but I'd say it =
has a shot at C++20.</div><div><br><div class=3D"gmail_quote">On Sat, Nov 1=
2, 2016 at 5:05 PM, <span dir=3D"ltr"><<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"Y5WA4yAqCAAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">dobr...@gmail.com</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Thanks, this is wha=
t I'm looking for, didn't know this existed. :)<div><br></div><div>=
Do you think this is going to get into standard someday? I hate using nonst=
andard extensions, but soon-to-be-standard solutions are acceptable for me.=
<span><br><br>On Saturday, November 12, 2016 at 11:00:48 PM UTC+1, Chris De=
Visser wrote:</span><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div dir=
=3D"ltr">Your best bet here would be to support=C2=A0<a href=3D"https://git=
hub.com/ldionne/wg21/blob/master/generated/P0424R1.pdf" rel=3D"nofollow" ta=
rget=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?=
q\x3dhttps%3A%2F%2Fgithub.com%2Fldionne%2Fwg21%2Fblob%2Fmaster%2Fgenerated%=
2FP0424R1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEWjiKPrC1X1MBz_eys_rM=
ejH0BhQ';return true;" onclick=3D"this.href=3D'https://www.google.c=
om/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fldionne%2Fwg21%2Fblob%2Fmaster%2Fgen=
erated%2FP0424R1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEWjiKPrC1X1MBz=
_eys_rMejH0BhQ';return true;">P0424</a>, where Louis Dionne has argued =
for this. If you want to use this today, GCC and Clang have implemented it =
as an extension.</div></span><div><br><div class=3D"gmail_quote"><div><div>=
On Sat, Nov 12, 2016 at 4:35 PM, <span dir=3D"ltr"><<a rel=3D"nofollow"=
>dobr...@gmail.com</a>></span> wrote:<br></div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><div><div dir=3D"ltr"><div>My proposal / idea is about p=
ossible literal operator definitions.</div><div><br></div><div>Given a lite=
ral operator for integers, e.g.=C2=A0<br></div><div><font face=3D"courier n=
ew, monospace">Weight w1 =3D 15_kg;</font></div><div><br></div><div>You can=
write a literal operator for this in ways:</div><div><br></div><div><font =
face=3D"courier new, monospace">constexpr Weight operator""_kg(un=
signed long long q) {</font></div><div><font face=3D"courier new, monospace=
">=C2=A0 =C2=A0 return Weight{q};</font></div><div><font face=3D"courier ne=
w, monospace">}</font></div><div><font face=3D"courier new, monospace"><br>=
</font></div><div><div><span style=3D"font-family:"courier new",m=
onospace">Weight operator""_kg(const char * str) {</span><br></di=
v><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></d=
iv><div><font face=3D"courier new, monospace">}</font></div></div><div><br>=
</div><div><font face=3D"courier new, monospace">template<char... CHARS&=
gt;</font></div><div><font face=3D"courier new, monospace">constexpr Weight=
operator""_kg() {</font></div><div><font face=3D"courier new, mo=
nospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier new, m=
onospace">}</font></div><div><br></div><div>The second one and the third on=
e differs by one important thing: 3rd allows us to process integer literals=
by individual characters in compile time. If you write</div><div><font fac=
e=3D"courier new, monospace">0x7b_kg</font></div><div><br></div><div>Then y=
ou get <font face=3D"courier new, monospace">'0', 'x', '=
;7', 'b'</font> characters as you expect.</div><div><br></div><=
div>But if you want to write a literal operator for a string literal, you h=
ave only one option:</div><div><br></div><div><div><span style=3D"font-fami=
ly:"courier new",monospace">std::string operator""_x(co=
nst char * str, std::size_t len) {</span><br></div><div><font face=3D"couri=
er new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"cour=
ier new, monospace">}</font></div></div><div><br></div><div>Which is quite =
illogical. We have the option for integer literals to parse them as either =
<font face=3D"courier new, monospace">template<char...></font> or <fo=
nt face=3D"courier new, monospace">const char*</font>, but we are denied to=
be able to parse strings at compile time...=C2=A0</div><div><br></div><div=
>I propose there should be an option like this for string literals as well.=
</div><div><br></div><div><div><font face=3D"courier new, monospace">templa=
te<char... CHARS, std::size_t LEN></font></div><div><font face=3D"cou=
rier new, monospace">std::string operator""x() {</font></div><div=
><font face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><di=
v><font face=3D"courier new, monospace">}</font></div></div><div><br></div>=
<div>or maybe</div><div><br></div><div><div><font face=3D"courier new, mono=
space">template<char... CHARS></font></div><div><font face=3D"courier=
new, monospace">std::string operator""x</font><span style=3D"fon=
t-family:"courier new",monospace">(</span><span style=3D"font-fam=
ily:"courier new",monospace">std::size_t len</span><span style=3D=
"font-family:"courier new",monospace">) {</span></div><div><font =
face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font=
face=3D"courier new, monospace">}</font></div></div><div><br></div><div>Ob=
viously, the final goal is to have something like this, without having to s=
pecify the characters individually, initialized with a beautiful string lit=
eral and a helper literal operator.</div><div><br></div><div><div><font fac=
e=3D"courier new, monospace">template<char... CHARS></font></div><div=
><font face=3D"courier new, monospace">struct constexpr_str</font></div><di=
v><font face=3D"courier new, monospace">{</font></div><div><font face=3D"co=
urier new, monospace">=C2=A0 =C2=A0 static constexpr char const value[] =3D=
{CHARS..., '\0'};</font></div><div><font face=3D"courier new, mono=
space">};</font></div></div><div><br></div><div>What do you think?</div></d=
iv></div></div><span><font color=3D"#888888"><div><div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/34f510eb-9b14-4e5f-<wbr>9485-=
761f71476eaf%40isocpp.org</a><wbr>.<br>
</span></font></span></blockquote></div><br></div>
</blockquote></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Y5WA4yAqCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Y5WA4yAqCAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1f1dca69-760e-49e3-<wbr>8346-=
942c67abcf46%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/170a234f-dfc0-43ad-9909-306ce3ab4eeb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/170a234f-dfc0-43ad-9909-306ce3ab4eeb=
%40isocpp.org</a>.<br />
------=_Part_919_903537341.1478992339729--
------=_Part_918_2013169798.1478992339729--
.
Author: Louis Dionne <ldionne.2@gmail.com>
Date: Sat, 12 Nov 2016 18:10:26 -0800 (PST)
Raw View
------=_Part_721_112398864.1479003026832
Content-Type: multipart/alternative;
boundary="----=_Part_722_1843464730.1479003026833"
------=_Part_722_1843464730.1479003026833
Content-Type: text/plain; charset=UTF-8
I presented that paper in front of the Evolution Working Group last
Tuesday. Compiler implementers in the room said that
they wanted to see a different way of having compile-time strings in the
language, for compile-time performance reasons.
Same old story as when this idea was presented before, in other words.
We're currently looking into alternatives such as
arrays as non-type template arguments, but we're hitting some issues.
Louis
On Saturday, 12 November 2016 15:12:20 UTC-8, dobragab wrote:
>
> I knew new features of C++17 have been fixed, so I was not hoping for
> that. It would be awesome if we had this, thank you for your answers.
>
> How can I use this in GCC / Clang?
>
> On Saturday, November 12, 2016 at 11:09:43 PM UTC+1, Chris DeVisser wrote:
>>
>> I think it's a reasonable addition, but I have not heard anything about
>> the paper beyond the proposal, so it's hard to say how it will do. It
>> certainly won't be in C++17 if that's what you were hoping for, but I'd say
>> it has a shot at C++20.
>>
>> On Sat, Nov 12, 2016 at 5:05 PM, <dobr...@gmail.com> wrote:
>>
>>> Thanks, this is what I'm looking for, didn't know this existed. :)
>>>
>>> Do you think this is going to get into standard someday? I hate using
>>> nonstandard extensions, but soon-to-be-standard solutions are acceptable
>>> for me.
>>>
>>> On Saturday, November 12, 2016 at 11:00:48 PM UTC+1, Chris DeVisser
>>> wrote:
>>>>
>>>> Your best bet here would be to support P0424
>>>> <https://github.com/ldionne/wg21/blob/master/generated/P0424R1.pdf>,
>>>> where Louis Dionne has argued for this. If you want to use this today, GCC
>>>> and Clang have implemented it as an extension.
>>>>
>>>> On Sat, Nov 12, 2016 at 4:35 PM, <dobr...@gmail.com> wrote:
>>>>
>>>>> My proposal / idea is about possible literal operator definitions.
>>>>>
>>>>> Given a literal operator for integers, e.g.
>>>>> Weight w1 = 15_kg;
>>>>>
>>>>> You can write a literal operator for this in ways:
>>>>>
>>>>> constexpr Weight operator""_kg(unsigned long long q) {
>>>>> return Weight{q};
>>>>> }
>>>>>
>>>>> Weight operator""_kg(const char * str) {
>>>>> // ...
>>>>> }
>>>>>
>>>>> template<char... CHARS>
>>>>> constexpr Weight operator""_kg() {
>>>>> // ...
>>>>> }
>>>>>
>>>>> The second one and the third one differs by one important thing: 3rd
>>>>> allows us to process integer literals by individual characters in compile
>>>>> time. If you write
>>>>> 0x7b_kg
>>>>>
>>>>> Then you get '0', 'x', '7', 'b' characters as you expect.
>>>>>
>>>>> But if you want to write a literal operator for a string literal, you
>>>>> have only one option:
>>>>>
>>>>> std::string operator""_x(const char * str, std::size_t len) {
>>>>> // ...
>>>>> }
>>>>>
>>>>> Which is quite illogical. We have the option for integer literals to
>>>>> parse them as either template<char...> or const char*, but we are
>>>>> denied to be able to parse strings at compile time...
>>>>>
>>>>> I propose there should be an option like this for string literals as
>>>>> well.
>>>>>
>>>>> template<char... CHARS, std::size_t LEN>
>>>>> std::string operator""x() {
>>>>> // ...
>>>>> }
>>>>>
>>>>> or maybe
>>>>>
>>>>> template<char... CHARS>
>>>>> std::string operator""x(std::size_t len) {
>>>>> // ...
>>>>> }
>>>>>
>>>>> Obviously, the final goal is to have something like this, without
>>>>> having to specify the characters individually, initialized with a beautiful
>>>>> string literal and a helper literal operator.
>>>>>
>>>>> template<char... CHARS>
>>>>> struct constexpr_str
>>>>> {
>>>>> static constexpr char const value[] = {CHARS..., '\0'};
>>>>> };
>>>>>
>>>>> What do you think?
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to std-proposal...@isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org
>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/170d2f3b-5249-4c4d-908b-0a259e1b0c51%40isocpp.org.
------=_Part_722_1843464730.1479003026833
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I presented that paper in front of the Evolution Work=
ing Group last Tuesday. Compiler implementers in the room said that</div><d=
iv>they wanted to see a different way of having compile-time strings in the=
language, for compile-time performance reasons.</div><div>Same old story a=
s when this idea was presented before, in other words. We're currently =
looking into alternatives such as</div><div>arrays as non-type template arg=
uments, but we're hitting some issues.</div><div><br></div><div>Louis</=
div><br>On Saturday, 12 November 2016 15:12:20 UTC-8, dobragab wrote:<bloc=
kquote 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">I knew new feature=
s of C++17 have been fixed, so I was not hoping for that. It would be aweso=
me if we had this, thank you for your answers.<div><br></div><div>How can I=
use this in GCC / Clang?<br><div><br>On Saturday, November 12, 2016 at 11:=
09:43 PM UTC+1, Chris DeVisser wrote:<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">I think it's a reasonable addition, but I have not h=
eard anything about the paper beyond the proposal, so it's hard to say =
how it will do. It certainly won't be in C++17 if that's what you w=
ere hoping for, but I'd say it has a shot at C++20.</div><div><br><div =
class=3D"gmail_quote">On Sat, Nov 12, 2016 at 5:05 PM, <span dir=3D"ltr">&=
lt;<a rel=3D"nofollow">dobr...@gmail.com</a>></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">Thanks, this is what I'm looking=
for, didn't know this existed. :)<div><br></div><div>Do you think this=
is going to get into standard someday? I hate using nonstandard extensions=
, but soon-to-be-standard solutions are acceptable for me.<span><br><br>On =
Saturday, November 12, 2016 at 11:00:48 PM UTC+1, Chris DeVisser wrote:</sp=
an><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span><div dir=3D"ltr">Your best=
bet here would be to support=C2=A0<a href=3D"https://github.com/ldionne/wg=
21/blob/master/generated/P0424R1.pdf" rel=3D"nofollow" target=3D"_blank" on=
mousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2=
Fgithub.com%2Fldionne%2Fwg21%2Fblob%2Fmaster%2Fgenerated%2FP0424R1.pdf\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEWjiKPrC1X1MBz_eys_rMejH0BhQ';retur=
n true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%=
3A%2F%2Fgithub.com%2Fldionne%2Fwg21%2Fblob%2Fmaster%2Fgenerated%2FP0424R1.p=
df\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEWjiKPrC1X1MBz_eys_rMejH0BhQ'=
;;return true;">P0424</a>, where Louis Dionne has argued for this. If you w=
ant to use this today, GCC and Clang have implemented it as an extension.</=
div></span><div><br><div class=3D"gmail_quote"><div><div>On Sat, Nov 12, 20=
16 at 4:35 PM, <span dir=3D"ltr"><<a rel=3D"nofollow">dobr...@gmail.com=
</a>></span> wrote:<br></div></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><=
div><div dir=3D"ltr"><div>My proposal / idea is about possible literal oper=
ator definitions.</div><div><br></div><div>Given a literal operator for int=
egers, e.g.=C2=A0<br></div><div><font face=3D"courier new, monospace">Weigh=
t w1 =3D 15_kg;</font></div><div><br></div><div>You can write a literal ope=
rator for this in ways:</div><div><br></div><div><font face=3D"courier new,=
monospace">constexpr Weight operator""_kg(unsigned long long q) =
{</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 retu=
rn Weight{q};</font></div><div><font face=3D"courier new, monospace">}</fon=
t></div><div><font face=3D"courier new, monospace"><br></font></div><div><d=
iv><span style=3D"font-family:"courier new",monospace">Weight ope=
rator""_kg(const char * str) {</span><br></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=
=3D"courier new, monospace">}</font></div></div><div><br></div><div><font f=
ace=3D"courier new, monospace">template<char... CHARS></font></div><d=
iv><font face=3D"courier new, monospace">constexpr Weight operator"&qu=
ot;_kg() {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 // ...</font></div><div><font face=3D"courier new, monospace">}</fon=
t></div><div><br></div><div>The second one and the third one differs by one=
important thing: 3rd allows us to process integer literals by individual c=
haracters in compile time. If you write</div><div><font face=3D"courier new=
, monospace">0x7b_kg</font></div><div><br></div><div>Then you get <font fac=
e=3D"courier new, monospace">'0', 'x', '7', 'b&=
#39;</font> characters as you expect.</div><div><br></div><div>But if you w=
ant to write a literal operator for a string literal, you have only one opt=
ion:</div><div><br></div><div><div><span style=3D"font-family:"courier=
new",monospace">std::string operator""_x(const char * str, =
std::size_t len) {</span><br></div><div><font face=3D"courier new, monospac=
e">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier new, monospa=
ce">}</font></div></div><div><br></div><div>Which is quite illogical. We ha=
ve the option for integer literals to parse them as either <font face=3D"co=
urier new, monospace">template<char...></font> or <font face=3D"couri=
er new, monospace">const char*</font>, but we are denied to be able to pars=
e strings at compile time...=C2=A0</div><div><br></div><div>I propose there=
should be an option like this for string literals as well.</div><div><br><=
/div><div><div><font face=3D"courier new, monospace">template<char... CH=
ARS, std::size_t LEN></font></div><div><font face=3D"courier new, monosp=
ace">std::string operator""x() {</font></div><div><font face=3D"c=
ourier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"=
courier new, monospace">}</font></div></div><div><br></div><div>or maybe</d=
iv><div><br></div><div><div><font face=3D"courier new, monospace">template&=
lt;char... CHARS></font></div><div><font face=3D"courier new, monospace"=
>std::string operator""x</font><span style=3D"font-family:"c=
ourier new",monospace">(</span><span style=3D"font-family:"courie=
r new",monospace">std::size_t len</span><span style=3D"font-family:&qu=
ot;courier new",monospace">) {</span></div><div><font face=3D"courier =
new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier=
new, monospace">}</font></div></div><div><br></div><div>Obviously, the fin=
al goal is to have something like this, without having to specify the chara=
cters individually, initialized with a beautiful string literal and a helpe=
r literal operator.</div><div><br></div><div><div><font face=3D"courier new=
, monospace">template<char... CHARS></font></div><div><font face=3D"c=
ourier new, monospace">struct constexpr_str</font></div><div><font face=3D"=
courier new, monospace">{</font></div><div><font face=3D"courier new, monos=
pace">=C2=A0 =C2=A0 static constexpr char const value[] =3D {CHARS..., '=
;\0'};</font></div><div><font face=3D"courier new, monospace">};</font>=
</div></div><div><br></div><div>What do you think?</div></div></div></div><=
span><font color=3D"#888888"><div><div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/34f510eb-9b14-4e5f-<wbr>9485-=
761f71476eaf%40isocpp.org</a><wbr>.<br>
</span></font></span></blockquote></div><br></div>
</blockquote></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</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/1f1dca69-760e-49e3-8346-942c67abcf46%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1f1dca69-760e-49e3-<wbr>8346-=
942c67abcf46%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/170d2f3b-5249-4c4d-908b-0a259e1b0c51%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/170d2f3b-5249-4c4d-908b-0a259e1b0c51=
%40isocpp.org</a>.<br />
------=_Part_722_1843464730.1479003026833--
------=_Part_721_112398864.1479003026832--
.
Author: Chris DeVisser <chris.n.devisser@gmail.com>
Date: Sat, 12 Nov 2016 21:21:42 -0500
Raw View
--001a114532448b9811054125636a
Content-Type: text/plain; charset=UTF-8
Thanks for sharing, Louis. It's a shame to see this feature missing, but
it's good to see work on compile-time strings.
On Sat, Nov 12, 2016 at 9:10 PM, Louis Dionne <ldionne.2@gmail.com> wrote:
> I presented that paper in front of the Evolution Working Group last
> Tuesday. Compiler implementers in the room said that
> they wanted to see a different way of having compile-time strings in the
> language, for compile-time performance reasons.
> Same old story as when this idea was presented before, in other words.
> We're currently looking into alternatives such as
> arrays as non-type template arguments, but we're hitting some issues.
>
> Louis
>
> On Saturday, 12 November 2016 15:12:20 UTC-8, dobragab wrote:
>>
>> I knew new features of C++17 have been fixed, so I was not hoping for
>> that. It would be awesome if we had this, thank you for your answers.
>>
>> How can I use this in GCC / Clang?
>>
>> On Saturday, November 12, 2016 at 11:09:43 PM UTC+1, Chris DeVisser wrote:
>>>
>>> I think it's a reasonable addition, but I have not heard anything about
>>> the paper beyond the proposal, so it's hard to say how it will do. It
>>> certainly won't be in C++17 if that's what you were hoping for, but I'd say
>>> it has a shot at C++20.
>>>
>>> On Sat, Nov 12, 2016 at 5:05 PM, <dobr...@gmail.com> wrote:
>>>
>>>> Thanks, this is what I'm looking for, didn't know this existed. :)
>>>>
>>>> Do you think this is going to get into standard someday? I hate using
>>>> nonstandard extensions, but soon-to-be-standard solutions are acceptable
>>>> for me.
>>>>
>>>> On Saturday, November 12, 2016 at 11:00:48 PM UTC+1, Chris DeVisser
>>>> wrote:
>>>>>
>>>>> Your best bet here would be to support P0424
>>>>> <https://github.com/ldionne/wg21/blob/master/generated/P0424R1.pdf>,
>>>>> where Louis Dionne has argued for this. If you want to use this today, GCC
>>>>> and Clang have implemented it as an extension.
>>>>>
>>>>> On Sat, Nov 12, 2016 at 4:35 PM, <dobr...@gmail.com> wrote:
>>>>>
>>>>>> My proposal / idea is about possible literal operator definitions.
>>>>>>
>>>>>> Given a literal operator for integers, e.g.
>>>>>> Weight w1 = 15_kg;
>>>>>>
>>>>>> You can write a literal operator for this in ways:
>>>>>>
>>>>>> constexpr Weight operator""_kg(unsigned long long q) {
>>>>>> return Weight{q};
>>>>>> }
>>>>>>
>>>>>> Weight operator""_kg(const char * str) {
>>>>>> // ...
>>>>>> }
>>>>>>
>>>>>> template<char... CHARS>
>>>>>> constexpr Weight operator""_kg() {
>>>>>> // ...
>>>>>> }
>>>>>>
>>>>>> The second one and the third one differs by one important thing: 3rd
>>>>>> allows us to process integer literals by individual characters in compile
>>>>>> time. If you write
>>>>>> 0x7b_kg
>>>>>>
>>>>>> Then you get '0', 'x', '7', 'b' characters as you expect.
>>>>>>
>>>>>> But if you want to write a literal operator for a string literal, you
>>>>>> have only one option:
>>>>>>
>>>>>> std::string operator""_x(const char * str, std::size_t len) {
>>>>>> // ...
>>>>>> }
>>>>>>
>>>>>> Which is quite illogical. We have the option for integer literals to
>>>>>> parse them as either template<char...> or const char*, but we are
>>>>>> denied to be able to parse strings at compile time...
>>>>>>
>>>>>> I propose there should be an option like this for string literals as
>>>>>> well.
>>>>>>
>>>>>> template<char... CHARS, std::size_t LEN>
>>>>>> std::string operator""x() {
>>>>>> // ...
>>>>>> }
>>>>>>
>>>>>> or maybe
>>>>>>
>>>>>> template<char... CHARS>
>>>>>> std::string operator""x(std::size_t len) {
>>>>>> // ...
>>>>>> }
>>>>>>
>>>>>> Obviously, the final goal is to have something like this, without
>>>>>> having to specify the characters individually, initialized with a beautiful
>>>>>> string literal and a helper literal operator.
>>>>>>
>>>>>> template<char... CHARS>
>>>>>> struct constexpr_str
>>>>>> {
>>>>>> static constexpr char const value[] = {CHARS..., '\0'};
>>>>>> };
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to std-proposal...@isocpp.org.
>>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals
>>>>>> /34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org
>>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit https://groups.google.com/a/is
>>>> ocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-
>>>> 942c67abcf46%40isocpp.org
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40isocpp.org?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/170d2f3b-5249-4c4d-
> 908b-0a259e1b0c51%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/170d2f3b-5249-4c4d-908b-0a259e1b0c51%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM6NJy4RrOQPH2Fh44r4Sr9N4yxy5yTc0uJNKL%3DuBTJmfFDxvw%40mail.gmail.com.
--001a114532448b9811054125636a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for sharing, Louis. It's a shame to see this fe=
ature missing, but it's good to see work on compile-time strings.</div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Nov 12, 2=
016 at 9:10 PM, Louis Dionne <span dir=3D"ltr"><<a href=3D"mailto:ldionn=
e.2@gmail.com" target=3D"_blank">ldionne.2@gmail.com</a>></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>I presented that pa=
per in front of the Evolution Working Group last Tuesday. Compiler implemen=
ters in the room said that</div><div>they wanted to see a different way of =
having compile-time strings in the language, for compile-time performance r=
easons.</div><div>Same old story as when this idea was presented before, in=
other words. We're currently looking into alternatives such as</div><d=
iv>arrays as non-type template arguments, but we're hitting some issues=
..</div><div><br></div><div>Louis</div><div><div class=3D"h5"><br>On Saturda=
y, 12 November 2016 15:12:20 UTC-8, dobragab wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">I knew new features of C++17 have been fi=
xed, so I was not hoping for that. It would be awesome if we had this, than=
k you for your answers.<div><br></div><div>How can I use this in GCC / Clan=
g?<br><div><br>On Saturday, November 12, 2016 at 11:09:43 PM UTC+1, Chris D=
eVisser wrote:<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">I th=
ink it's a reasonable addition, but I have not heard anything about the=
paper beyond the proposal, so it's hard to say how it will do. It cert=
ainly won't be in C++17 if that's what you were hoping for, but I&#=
39;d say it has a shot at C++20.</div><div><br><div class=3D"gmail_quote">O=
n Sat, Nov 12, 2016 at 5:05 PM, <span dir=3D"ltr"><<a rel=3D"nofollow">=
dobr...@gmail.com</a>></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">Thanks, this is what I'm looking for, didn't know t=
his existed. :)<div><br></div><div>Do you think this is going to get into s=
tandard someday? I hate using nonstandard extensions, but soon-to-be-standa=
rd solutions are acceptable for me.<span><br><br>On Saturday, November 12, =
2016 at 11:00:48 PM UTC+1, Chris DeVisser wrote:</span><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><span><div dir=3D"ltr">Your best bet here would be to s=
upport=C2=A0<a href=3D"https://github.com/ldionne/wg21/blob/master/generate=
d/P0424R1.pdf" rel=3D"nofollow" target=3D"_blank">P0424</a>, where Louis Di=
onne has argued for this. If you want to use this today, GCC and Clang have=
implemented it as an extension.</div></span><div><br><div class=3D"gmail_q=
uote"><div><div>On Sat, Nov 12, 2016 at 4:35 PM, <span dir=3D"ltr"><<a =
rel=3D"nofollow">dobr...@gmail.com</a>></span> wrote:<br></div></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr"><div>My proposal / i=
dea is about possible literal operator definitions.</div><div><br></div><di=
v>Given a literal operator for integers, e.g.=C2=A0<br></div><div><font fac=
e=3D"courier new, monospace">Weight w1 =3D 15_kg;</font></div><div><br></di=
v><div>You can write a literal operator for this in ways:</div><div><br></d=
iv><div><font face=3D"courier new, monospace">constexpr Weight operator&quo=
t;"_kg(unsigned long long q) {</font></div><div><font face=3D"courier =
new, monospace">=C2=A0 =C2=A0 return Weight{q};</font></div><div><font face=
=3D"courier new, monospace">}</font></div><div><font face=3D"courier new, m=
onospace"><br></font></div><div><div><span style=3D"font-family:"couri=
er new",monospace">Weight operator""_kg(const char * str) {<=
/span><br></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 //=
...</font></div><div><font face=3D"courier new, monospace">}</font></div><=
/div><div><br></div><div><font face=3D"courier new, monospace">template<=
char... CHARS></font></div><div><font face=3D"courier new, monospace">co=
nstexpr Weight operator""_kg() {</font></div><div><font face=3D"c=
ourier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"=
courier new, monospace">}</font></div><div><br></div><div>The second one an=
d the third one differs by one important thing: 3rd allows us to process in=
teger literals by individual characters in compile time. If you write</div>=
<div><font face=3D"courier new, monospace">0x7b_kg</font></div><div><br></d=
iv><div>Then you get <font face=3D"courier new, monospace">'0', =
9;x', '7', 'b'</font> characters as you expect.</div><d=
iv><br></div><div>But if you want to write a literal operator for a string =
literal, you have only one option:</div><div><br></div><div><div><span styl=
e=3D"font-family:"courier new",monospace">std::string operator&qu=
ot;"_x(const char * str, std::size_t len) {</span><br></div><div><font=
face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><fon=
t face=3D"courier new, monospace">}</font></div></div><div><br></div><div>W=
hich is quite illogical. We have the option for integer literals to parse t=
hem as either <font face=3D"courier new, monospace">template<char...>=
</font> or <font face=3D"courier new, monospace">const char*</font>, but we=
are denied to be able to parse strings at compile time...=C2=A0</div><div>=
<br></div><div>I propose there should be an option like this for string lit=
erals as well.</div><div><br></div><div><div><font face=3D"courier new, mon=
ospace">template<char... CHARS, std::size_t LEN></font></div><div><fo=
nt face=3D"courier new, monospace">std::string operator""x() {</f=
ont></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</=
font></div><div><font face=3D"courier new, monospace">}</font></div></div><=
div><br></div><div>or maybe</div><div><br></div><div><div><font face=3D"cou=
rier new, monospace">template<char... CHARS></font></div><div><font f=
ace=3D"courier new, monospace">std::string operator""x</font><spa=
n style=3D"font-family:"courier new",monospace">(</span><span sty=
le=3D"font-family:"courier new",monospace">std::size_t len</span>=
<span style=3D"font-family:"courier new",monospace">) {</span></d=
iv><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></=
div><div><font face=3D"courier new, monospace">}</font></div></div><div><br=
></div><div>Obviously, the final goal is to have something like this, witho=
ut having to specify the characters individually, initialized with a beauti=
ful string literal and a helper literal operator.</div><div><br></div><div>=
<div><font face=3D"courier new, monospace">template<char... CHARS></f=
ont></div><div><font face=3D"courier new, monospace">struct constexpr_str</=
font></div><div><font face=3D"courier new, monospace">{</font></div><div><f=
ont face=3D"courier new, monospace">=C2=A0 =C2=A0 static constexpr char con=
st value[] =3D {CHARS..., '\0'};</font></div><div><font face=3D"cou=
rier new, monospace">};</font></div></div><div><br></div><div>What do you t=
hink?</div></div></div></div><span><font color=3D"#888888"><div><div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/34f510eb-9b14-4e5f-9485-<wbr>761f71476eaf%40isocpp.org</a>.<br=
>
</span></font></span></blockquote></div><br></div>
</blockquote></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</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/1f1dca69-760e-49e3-8346-942c67abcf46%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/1f1dca69-760e-49e3-8346-<wbr>942c67abcf46%40isocpp.org</a>.<br=
>
</blockquote></div><br></div>
</blockquote></div></div></div></blockquote></div></div></div><div><div cla=
ss=3D"h5">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/170d2f3b-5249-4c4d-908b-0a259e1b0c51%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/170d=
2f3b-5249-4c4d-<wbr>908b-0a259e1b0c51%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAM6NJy4RrOQPH2Fh44r4Sr9N4yxy5yTc0uJN=
KL%3DuBTJmfFDxvw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM6NJy4RrOQPH2=
Fh44r4Sr9N4yxy5yTc0uJNKL%3DuBTJmfFDxvw%40mail.gmail.com</a>.<br />
--001a114532448b9811054125636a--
.
Author: "D. B." <db0451@gmail.com>
Date: Sun, 13 Nov 2016 10:06:10 +0000
Raw View
--001a1145b1be63185005412bdf5b
Content-Type: text/plain; charset=UTF-8
Regarding earlier discussion - is the feature set of C++17 totally fixed
now, or is it still subject to late national body comments?
--
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/CACGiwhHtgG-B7Wz3xFBxxAU_PHrGWCW0pbDWZYaf5sKK8bh7Wg%40mail.gmail.com.
--001a1145b1be63185005412bdf5b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Regarding earlier discussion - is the feature set of C++17=
totally fixed now, or is it still subject to late national body comments?<=
br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CACGiwhHtgG-B7Wz3xFBxxAU_PHrGWCW0pbDW=
ZYaf5sKK8bh7Wg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHtgG-B7Wz3=
xFBxxAU_PHrGWCW0pbDWZYaf5sKK8bh7Wg%40mail.gmail.com</a>.<br />
--001a1145b1be63185005412bdf5b--
.
Author: Louis Dionne <ldionne.2@gmail.com>
Date: Sun, 13 Nov 2016 10:05:41 -0800
Raw View
> On Nov 13, 2016, at 02:06, D. B. <db0451@gmail.com> wrote:
>=20
> Regarding earlier discussion - is the feature set of C++17 totally fixed =
now, or is it still subject to late national body comments?
My understanding is that the feature set is fixed now (and has been since O=
ulu at least).
We went through most of the NB comments in Issaquah, but those are not real=
ly new =E2=80=9Cfeatures=E2=80=9D,
they=E2=80=99re more like bug fixes AFAIU.
Louis
--=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/F4D60EFD-B767-4AC7-9234-6BBB16901932%40gmail.com=
..
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 13 Nov 2016 17:03:37 -0800 (PST)
Raw View
------=_Part_2287_1364537822.1479085417538
Content-Type: multipart/alternative;
boundary="----=_Part_2288_1027383180.1479085417538"
------=_Part_2288_1027383180.1479085417538
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, November 13, 2016 at 1:05:41 PM UTC-5, Louis Dionne wrote:
>
>
> > On Nov 13, 2016, at 02:06, D. B. <db0...@gmail.com <javascript:>>=20
> wrote:=20
> >=20
> > Regarding earlier discussion - is the feature set of C++17 totally fixe=
d=20
> now, or is it still subject to late national body comments?=20
>
> My understanding is that the feature set is fixed now (and has been since=
=20
> Oulu at least).=20
> We went through most of the NB comments in Issaquah, but those are not=20
> really new =E2=80=9Cfeatures=E2=80=9D,=20
> they=E2=80=99re more like bug fixes AFAIU.=20
>
To be fair, some of those NB comments were genuine feature requests, like=
=20
"add concepts/operator-dot/etc to the standard". I know Herb Sutter at=20
least thought that operator-dot *might* be able to get in via an NB comment=
..
--=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/aab343a1-92ca-4f0b-83cd-b306b31477e1%40isocpp.or=
g.
------=_Part_2288_1027383180.1479085417538
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, November 13, 2016 at 1:05:41 PM UTC-5, =
Louis Dionne wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> On Nov 13, 2016, at 02:06, D. B. <<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"Koj-dyNTAAAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">db0...@gmail.com</a>> wrote:
<br>>=20
<br>> Regarding earlier discussion - is the feature set of C++17 totally=
fixed now, or is it still subject to late national body comments?
<br>
<br>My understanding is that the feature set is fixed now (and has been sin=
ce Oulu at least).
<br>We went through most of the NB comments in Issaquah, but those are not =
really new =E2=80=9Cfeatures=E2=80=9D,
<br>they=E2=80=99re more like bug fixes AFAIU.
<br></blockquote><div><br>To be fair, some of those NB comments were genuin=
e feature requests, like "add concepts/operator-dot/etc to the standar=
d". I know Herb Sutter at least thought that operator-dot <i>might</i>=
be able to get in via an NB comment.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/aab343a1-92ca-4f0b-83cd-b306b31477e1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aab343a1-92ca-4f0b-83cd-b306b31477e1=
%40isocpp.org</a>.<br />
------=_Part_2288_1027383180.1479085417538--
------=_Part_2287_1364537822.1479085417538--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 13 Nov 2016 19:05:26 -0600
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Non of the feature requests were excepted. At least not anythin=
g major. </div> =
<d=
iv style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate P=
ro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; =
background-color: rgb(255, 255, 255);"><br style=3D"display:initial"></div>=
=
=
<div style=3D"font-size: initi=
al; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(3=
1, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Se=
nt from my BlackBerry portable Babbage Device=
</div> =
=
<table width=3D"100%" style=3D"background=
-color:white;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"fo=
nt-size: initial; text-align: initial; background-color: rgb(255, 255, 255)=
;"> <div style=3D"border-style: solid none none; =
border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0=
in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;=
"> <div><b>From: </b>Nicol Bolas</div><div><b>Sent: </b>Sunday, November 1=
3, 2016 7:03 PM</div><div><b>To: </b>ISO C++ Standard - Future Proposals</d=
iv><div><b>Reply To: </b>std-proposals@isocpp.org</div><div><b>Subject: </b=
>Re: [std-proposals] Template literal operator for string literals</div></d=
iv></td></tr></tbody></table><div style=3D"border-style: solid none none; b=
order-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: init=
ial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br>=
<div id=3D"_originalContent" style=3D""><div dir=3D"ltr"><br><br>On Sunday,=
November 13, 2016 at 1:05:41 PM UTC-5, Louis Dionne wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">
<br>> On Nov 13, 2016, at 02:06, D. B. <<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"Koj-dyNTAAAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">db0...@gmail.com</a>> wrote:
<br>>=20
<br>> Regarding earlier discussion - is the feature set of C++17 totally=
fixed now, or is it still subject to late national body comments?
<br>
<br>My understanding is that the feature set is fixed now (and has been sin=
ce Oulu at least).
<br>We went through most of the NB comments in Issaquah, but those are not =
really new =E2=80=9Cfeatures=E2=80=9D,
<br>they=E2=80=99re more like bug fixes AFAIU.
<br></blockquote><div><br>To be fair, some of those NB comments were genuin=
e feature requests, like "add concepts/operator-dot/etc to the standard". I=
know Herb Sutter at least thought that operator-dot <i>might</i> be able t=
o get in via an NB comment.<br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" 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/aab343a1-92ca-4f0b-83cd-b306b31477e1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/aab343a1-92ca-4f0b-83cd-b306b314=
77e1%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/20161114010526.4911185.39660.20133%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20161114010526.4911185.39660.20133%40gm=
ail.com</a>.<br />
.