Topic: escaped commas in macros
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 9 Oct 2015 01:20:20 -0300
Raw View
There are situations in which the cpp wrongly takes commas separating
template arguments as macro arguments delimiters.
For example:
template <class X, class Y> struct S;
#define Macro(arg) S arg;
The extra ( ) workaround used in C cannot be used here:
Macro((<int, int>));
This is important for X-macros for example.
I propose to enhance the cpp to be able to ignore escaped commas (with
\), so this can be done:
Macro(<int\, int>);
We already implemented this extension in gcc (patch to be sent on
Monday) which is working.
What we did is: comma escaping occurs at the top level, but not inside ( ).
For example
SomeMacro(f(a\,b))
does no escape the comma and thus has current behavior.
Feedback?
Thanks,
Daniel.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Thu, 8 Oct 2015 21:40:25 -0700 (PDT)
Raw View
------=_Part_310_260757739.1444365625672
Content-Type: multipart/alternative;
boundary="----=_Part_311_2123801839.1444365625673"
------=_Part_311_2123801839.1444365625673
Content-Type: text/plain; charset=UTF-8
On Friday, October 9, 2015 at 12:20:22 AM UTC-4, dgutson wrote:
>
> There are situations in which the cpp wrongly takes commas separating
> template arguments as macro arguments delimiters.
>
This issue was discussed at the beginning of last year. One of the big
sticking points mentioned in that thread is that the preprocessor behavior
is inherited from C, and so would have to be changed there first.
https://groups.google.com/a/isocpp.org/forum/?fromgroups&pli=1#!topic/std-proposals/_ayMs1oDeMs
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_311_2123801839.1444365625673
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 9, 2015 at 12:20:22 AM UTC-4, dgutson w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">There are situations in w=
hich the cpp wrongly takes commas separating
<br>template arguments as macro arguments delimiters.
<br></blockquote><div><br></div><div>This issue was discussed at the beginn=
ing of last year. =C2=A0One of the big sticking points mentioned in that th=
read is that the preprocessor behavior is inherited from C, and so would ha=
ve to be changed there first.</div><div><br></div><div>https://groups.googl=
e.com/a/isocpp.org/forum/?fromgroups&pli=3D1#!topic/std-proposals/_ayMs=
1oDeMs=C2=A0<br></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_311_2123801839.1444365625673--
------=_Part_310_260757739.1444365625672--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 9 Oct 2015 01:41:45 -0300
Raw View
--001a11409d46d23f160521a4981f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 9/10/2015 1:40, "Greg Marr" <gregmmarr@gmail.com> escribi=C3=B3:
>
> On Friday, October 9, 2015 at 12:20:22 AM UTC-4, dgutson wrote:
>>
>> There are situations in which the cpp wrongly takes commas separating
>> template arguments as macro arguments delimiters.
>
>
> This issue was discussed at the beginning of last year. One of the big
sticking points mentioned in that thread is that the preprocessor behavior
is inherited from C, and so would have to be changed there first.
>
>
https://groups.google.com/a/isocpp.org/forum/?fromgroups&pli=3D1#!topic/std=
-proposals/_ayMs1oDeMs
But the issue only arises in C++, and the preprocessor is already different=
..
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11409d46d23f160521a4981f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 9/10/2015 1:40, "Greg Marr" <<a href=3D"mailto:gregmmarr@gm=
ail.com">gregmmarr@gmail.com</a>> escribi=C3=B3:<br>
><br>
> On Friday, October 9, 2015 at 12:20:22 AM UTC-4, dgutson wrote:<br>
>><br>
>> There are situations in which the cpp wrongly takes commas separat=
ing <br>
>> template arguments as macro arguments delimiters. <br>
><br>
><br>
> This issue was discussed at the beginning of last year.=C2=A0 One of t=
he big sticking points mentioned in that thread is that the preprocessor be=
havior is inherited from C, and so would have to be changed there first.<br=
>
><br>
> <a href=3D"https://groups.google.com/a/isocpp.org/forum/?fromgroups&am=
p;pli=3D1#!topic/std-proposals/_ayMs1oDeMs">https://groups.google.com/a/iso=
cpp.org/forum/?fromgroups&pli=3D1#!topic/std-proposals/_ayMs1oDeMs</a>=
=C2=A0</p>
<p dir=3D"ltr">But the issue only arises in C++, and the preprocessor is al=
ready different.<br></p>
<p dir=3D"ltr">><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11409d46d23f160521a4981f--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 9 Oct 2015 14:21:56 +0800
Raw View
--Apple-Mail=_47ACD949-0E54-4334-B255-658152F84C3E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9309, at 12:20 PM, dgutson . <danielgutson@gmail=
..com> wrote:
>=20
> There are situations in which the cpp wrongly takes commas separating
> template arguments as macro arguments delimiters.
> For example:
>=20
> template <class X, class Y> struct S;
> #define Macro(arg) S arg;
>=20
> The extra ( ) workaround used in C cannot be used here:
> Macro((<int, int>));
Solution A:
#define EXPAND( ARG ) ARG
#define Macro( ARG ) S EXPAND ARG
Macro((<int, int>))
Solution B:
#define Macro( ... ) S __VA_ARGS__
Macro(<int, int>)
Solution C:
#define COMMA ,
Macro(<int COMMA int>)
> This is important for X-macros for example.
What is an X-macro?
> I propose to enhance the cpp to be able to ignore escaped commas (with
> \), so this can be done:
> Macro(<int\, int>);
>=20
> We already implemented this extension in gcc (patch to be sent on
> Monday) which is working.
> What we did is: comma escaping occurs at the top level, but not inside ( =
).
> For example
> SomeMacro(f(a\,b))
> does no escape the comma and thus has current behavior.
I think I still prefer solutions A and B.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_47ACD949-0E54-4334-B255-658152F84C3E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9309, at 12:20 PM, dgutson . <<a href=3D"mailto:danielgutson@gmai=
l.com" class=3D"">danielgutson@gmail.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D"">There are situations in which the=
cpp wrongly takes commas separating<br class=3D"">template arguments as ma=
cro arguments delimiters.<br class=3D"">For example:<br class=3D""><br clas=
s=3D"">template <class X, class Y> struct S;<br class=3D"">#define Ma=
cro(arg) S arg;<br class=3D""><br class=3D"">The extra ( ) workaround used =
in C cannot be used here:<br class=3D""> Macro((<int, =
int>));<br class=3D""></div></blockquote><div><br class=3D""></div><div>=
Solution A:</div><div><br class=3D""></div><div><font face=3D"Courier" clas=
s=3D"">#define EXPAND( ARG ) ARG</font></div><div><font face=3D"Courier" cl=
ass=3D"">#define Macro( ARG ) S EXPAND ARG</font></div><div><font face=3D"C=
ourier" class=3D""><br class=3D""></font></div><div><font face=3D"Courier" =
class=3D"">Macro((<int, int>))</font></div><div><br class=3D""></div>=
<div>Solution B:</div><div><br class=3D""></div><div><div><span style=3D"fo=
nt-family: Courier;" class=3D"">#define Macro( ... ) S __VA_ARGS__</span></=
div><div><font face=3D"Courier" class=3D""><br class=3D""></font></div><div=
><font face=3D"Courier" class=3D"">Macro(<int, int>)</font></div><div=
class=3D""><br class=3D""></div><div class=3D"">Solution C:</div><div clas=
s=3D""><br class=3D""></div><div class=3D""><font face=3D"Courier" class=3D=
"">#define COMMA ,</font></div><div class=3D""><font face=3D"Courier" class=
=3D"">Macro(<int COMMA int>)</font></div><div class=3D""><br class=3D=
""></div></div><blockquote type=3D"cite" class=3D""><div class=3D"">This is=
important for X-macros for example.<br class=3D""></div></blockquote><div>=
<br class=3D""></div><div>What is an X-macro?</div><br class=3D""><blockquo=
te type=3D"cite" class=3D""><div class=3D"">I propose to enhance the cpp to=
be able to ignore escaped commas (with<br class=3D"">\), so this can be do=
ne:<br class=3D""> Macro(<int\, int>);<br class=3D"=
"><br class=3D"">We already implemented this extension in gcc (patch to be =
sent on<br class=3D"">Monday) which is working.<br class=3D"">What we did i=
s: comma escaping occurs at the top level, but not inside ( ).<br class=3D"=
">For example<br class=3D""> SomeMacro(f(a\,b))<br class=
=3D"">does no escape the comma and thus has current behavior.<br class=3D""=
></div></blockquote><div><br class=3D""></div><div>I think I still prefer s=
olutions A and B.</div></div><br class=3D""></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_47ACD949-0E54-4334-B255-658152F84C3E--
.
Author: Lingxi Li <lilingxi.cs@gmail.com>
Date: Fri, 9 Oct 2015 02:20:33 -0700 (PDT)
Raw View
------=_Part_2494_1043869503.1444382434114
Content-Type: multipart/alternative;
boundary="----=_Part_2495_46743487.1444382434114"
------=_Part_2495_46743487.1444382434114
Content-Type: text/plain; charset=UTF-8
On Friday, October 9, 2015 at 2:22:02 PM UTC+8, David Krauss wrote:
>
>
> I think I still prefer solutions A and B.
>
> How about defining a general grouping macro like
#define ARG(...) __VA_ARGS__
So, the usage would be
Macro(ARG(<int, int>))
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2495_46743487.1444382434114
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, October 9, 2015 at 2:22:02 PM UTC+8, Da=
vid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D=
"word-wrap:break-word"><div><div><br></div><div>I think I still prefer solu=
tions A and B.</div></div><br></div></blockquote><div>How about defining a =
general grouping macro like<br><br><div class=3D"prettyprint" style=3D"bord=
er: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: =
rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #800;" class=3D"styled-by-prettify">#define</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> ARG</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(...)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> __VA_ARGS__</span></div></=
code></div><br>So, the usage would be<br><br><div class=3D"prettyprint" sty=
le=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgrou=
nd-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #606;" class=3D"styled-by-prettify">Mac=
ro</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">ARG</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(<</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">>))</span></div></code></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2495_46743487.1444382434114--
------=_Part_2494_1043869503.1444382434114--
.
Author: Roman Perepelitsa <roman.perepelitsa@gmail.com>
Date: Fri, 9 Oct 2015 11:28:42 +0200
Raw View
--047d7b3a888e37cd460521a89c59
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Oct 9, 2015 at 8:21 AM, David Krauss <potswa@gmail.com> wrote:
>
> On 2015=E2=80=9310=E2=80=9309, at 12:20 PM, dgutson . <danielgutson@gmail=
..com> wrote:
>
> There are situations in which the cpp wrongly takes commas separating
> template arguments as macro arguments delimiters.
> For example:
>
> template <class X, class Y> struct S;
> #define Macro(arg) S arg;
>
> The extra ( ) workaround used in C cannot be used here:
> Macro((<int, int>));
>
>
> Solution A:
>
> #define EXPAND( ARG ) ARG
> #define Macro( ARG ) S EXPAND ARG
>
> Macro((<int, int>))
>
> Solution B:
>
> #define Macro( ... ) S __VA_ARGS__
>
> Macro(<int, int>)
>
> Solution C:
>
> #define COMMA ,
> Macro(<int COMMA int>)
>
Solution D:
// If x is (expr), expands to expr.
// Otherwise expands to x.
#define UNPARENTHESIZE_IF_PARENTHESIZED(x) /* complicated */
#define MACRO(type) UNPARENTHESIZE_IF_PARENTHESIZED(type)
MACRO(int) =3D> int
MACRO((int)) =3D> int
MACRO((pair<int, int>)) =3D> pair<int, int>
The implementation of UNPARENTHESIZE_IF_PARENTHESIZED is non-trivial. I
believe it also requires a compiler extension (the last one in
https://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html#Variadic-Macros).
It's possible to writing macros that behave well in the presence of
arguments with commas. It's just hard.
Roman Perepelitsa.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7b3a888e37cd460521a89c59
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Oct 9, 2015 at 8:21 AM, David Krauss <span dir=3D"ltr"><<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><spa=
n class=3D""><blockquote type=3D"cite"><div>On 2015=E2=80=9310=E2=80=9309, =
at 12:20 PM, dgutson . <<a href=3D"mailto:danielgutson@gmail.com" target=
=3D"_blank">danielgutson@gmail.com</a>> wrote:</div><br><div>There are s=
ituations in which the cpp wrongly takes commas separating<br>template argu=
ments as macro arguments delimiters.<br>For example:<br><br>template <cl=
ass X, class Y> struct S;<br>#define Macro(arg) S arg;<br><br>The extra =
( ) workaround used in C cannot be used here:<br> =C2=A0=C2=A0=C2=A0Macro((=
<int, int>));<br></div></blockquote><div><br></div></span><div>Soluti=
on A:</div><div><br></div><div><font face=3D"Courier">#define EXPAND( ARG )=
ARG</font></div><div><font face=3D"Courier">#define Macro( ARG ) S EXPAND =
ARG</font></div><div><font face=3D"Courier"><br></font></div><div><font fac=
e=3D"Courier">Macro((<int, int>))</font></div><div><br></div><div>Sol=
ution B:</div><div><br></div><div><div><span style=3D"font-family:Courier">=
#define Macro( ... ) S __VA_ARGS__</span></div><div><font face=3D"Courier">=
<br></font></div><div><font face=3D"Courier">Macro(<int, int>)</font>=
</div><div><br></div><div>Solution C:</div><div><br></div><div><font face=
=3D"Courier">#define COMMA ,</font></div><div><font face=3D"Courier">Macro(=
<int COMMA int>)</font></div></div></div></div></blockquote><div><br>=
</div><div>Solution D:</div><div><br></div><div><font face=3D"monospace, mo=
nospace">=C2=A0 // If x is (expr), expands to expr.</font></div><div><font =
face=3D"monospace, monospace">=C2=A0 // Otherwise expands to x.</font></div=
><div><font face=3D"monospace, monospace">=C2=A0 #define UNPARENTHESIZE_IF_=
PARENTHESIZED(x) /* complicated */</font></div><div><br></div><div><font fa=
ce=3D"monospace, monospace">=C2=A0 #define MACRO(type)=C2=A0UNPARENTHESIZE_=
IF_PARENTHESIZED(type)</font></div><div><font face=3D"monospace, monospace"=
><br></font></div><div><font face=3D"monospace, monospace">=C2=A0 MACRO(int=
) =3D> int</font></div><div><font face=3D"monospace, monospace">=C2=A0 M=
ACRO((int)) =3D> int</font></div><div><font face=3D"monospace, monospace=
">=C2=A0 MACRO((pair<int, int>)) =3D> pair<int, int></font><=
/div><div><br></div><div>The implementation of UNPARENTHESIZE_IF_PARENTHESI=
ZED is non-trivial. I believe it also requires a compiler extension (the la=
st one in=C2=A0<a href=3D"https://gcc.gnu.org/onlinedocs/gcc/Variadic-Macro=
s.html#Variadic-Macros">https://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.=
html#Variadic-Macros</a>).<br></div><div><br></div><div>It's possible t=
o writing macros that behave well in the presence of arguments with commas.=
It's just hard.</div><div><br></div><div>Roman Perepelitsa.</div></div=
></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b3a888e37cd460521a89c59--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 9 Oct 2015 19:59:58 +0800
Raw View
--Apple-Mail=_A01B896D-CF9A-4013-99C6-58E4AA882D8A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9309, at 5:20 PM, Lingxi Li <lilingxi.cs@gmail.c=
om> wrote:
>=20
> How about defining a general grouping macro like
>=20
> #define ARG(...) __VA_ARGS__
>=20
> So, the usage would be
>=20
> Macro(ARG(<int, int>))
This macro is what I meant to say for solution A. The approach is very simi=
lar, call it A=E2=80=99. Any macro expecting a template argument list might=
take a parenthesized argument as a courtesy. For surprising cases you can =
DIY.
> On 2015=E2=80=9310=E2=80=9309, at 5:28 PM, Roman Perepelitsa <roman.perep=
elitsa@gmail.com> wrote:
>=20
> The implementation of UNPARENTHESIZE_IF_PARENTHESIZED is non-trivial.
Please, do share.
> I believe it also requires a compiler extension (the last one in https://=
gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html#Variadic-Macros <https://gc=
c.gnu.org/onlinedocs/gcc/Variadic-Macros.html#Variadic-Macros>).
I=E2=80=99ve proposed this for standardization in N4220 <http://wg21.link/N=
4220>. Unfortunately, it=E2=80=99s not been reviewed.
> It's possible to writing macros that behave well in the presence of argum=
ents with commas. It's just hard.
It=E2=80=99s hard to optionally strip parens automatically. It=E2=80=99s ea=
sy to expect one level of parens and strip them. It=E2=80=99s also easy to =
use __VA_ARGS__, albeit ugly.
Bah, my cursed brain went and solved the riddle. I don=E2=80=99t see any ne=
ed for an extension.
#define UNPAREN(...) UNPAREN __VA_ARGS__
#define DONE_UNPAREN
#define CAT_LIT(A, ...) A ## __VA_ARGS__
#define CAT(A, ...) CAT_LIT( A, __VA_ARGS__ )
#define UNPARENTHESIZE_IF_PARENTHESIZED(...) CAT( DONE_, UNPAREN __VA_ARGS_=
_ )
http://coliru.stacked-crooked.com/a/3578969a94bb175a <http://coliru.stacked=
-crooked.com/a/3578969a94bb175a>
I=E2=80=99d almost call this trivial. CAT/CAT_LIT is a common utility neede=
d for any preprocessor metaprogramming.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_A01B896D-CF9A-4013-99C6-58E4AA882D8A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9309, at 5:20 PM, Lingxi Li <<a href=3D"mailto:lilingxi.cs@gmail.=
com" class=3D"">lilingxi.cs@gmail.com</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">How abou=
t defining a general grouping macro like<br class=3D""><div class=3D""><br =
class=3D""><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 1=
87, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><co=
de class=3D"prettyprint"><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">#define</span> ARG<span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(...)</span> __VA_ARGS__</code></div><br class=3D"">So, the usage =
would be<br class=3D""><br class=3D""><div class=3D"prettyprint" style=3D"b=
order: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-colo=
r: rgb(250, 250, 250);"><code class=3D"prettyprint"><span style=3D"color: #=
606;" class=3D"styled-by-prettify">Macro</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">(</span>ARG<span style=3D"color: #660;" class=
=3D"styled-by-prettify">(<</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span> <span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
;))</span></code></div></div></div></div></blockquote><div><br class=3D""><=
/div><div>This macro is what I meant to say for solution A. The approach is=
very similar, call it A=E2=80=99. Any macro expecting a template argument =
list might take a parenthesized argument as a courtesy. For surprising case=
s you can DIY.</div><div><br class=3D""></div><div><br class=3D""></div><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9309, at 5:28 PM, Roman Perepelitsa <<a href=3D"mailto:roman.pere=
pelitsa@gmail.com" class=3D"">roman.perepelitsa@gmail.com</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">=
The implementation of UNPARENTHESIZE_IF_PARENTHESIZED is non-trivial. </div=
></div></blockquote><div><br class=3D""></div><div>Please, do share.</div><=
br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div cla=
ss=3D"">I believe it also requires a compiler extension (the last one in&nb=
sp;<a href=3D"https://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html#Varia=
dic-Macros" class=3D"">https://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.h=
tml#Variadic-Macros</a>).<br class=3D""></div><div class=3D""></div></div><=
/blockquote><div><br class=3D""></div><div>I=E2=80=99ve proposed this for s=
tandardization in <a href=3D"http://wg21.link/N4220" class=3D"">N4220<=
/a>. Unfortunately, it=E2=80=99s not been reviewed.</div><br class=3D""><bl=
ockquote type=3D"cite" class=3D""><div class=3D""><div class=3D"">It's poss=
ible to writing macros that behave well in the presence of arguments with c=
ommas. It's just hard.</div></div></blockquote><br class=3D""></div><div>It=
=E2=80=99s hard to <i class=3D"">optionally</i> strip parens automatic=
ally. It=E2=80=99s easy to expect one level of parens and strip them. It=E2=
=80=99s also easy to use <font face=3D"Courier" class=3D"">__VA_ARGS__</fon=
t>, albeit ugly.</div><div><br class=3D""></div><div>Bah, my cursed brain w=
ent and solved the riddle. I don=E2=80=99t see any need for an extension.</=
div><div><br class=3D""></div><div><font face=3D"Courier" class=3D"">#defin=
e UNPAREN(...) UNPAREN __VA_ARGS__<br class=3D"">#define DONE_UNPAREN<br cl=
ass=3D""><br class=3D"">#define CAT_LIT(A, ...) A ## __VA_ARGS__<br class=
=3D"">#define CAT(A, ...) CAT_LIT( A, __VA_ARGS__ )<br class=3D"">#define U=
NPARENTHESIZE_IF_PARENTHESIZED(...) CAT( DONE_, UNPAREN __VA_ARGS__ &n=
bsp;)<br class=3D""></font><br class=3D""></div><div><a href=3D"http://coli=
ru.stacked-crooked.com/a/3578969a94bb175a" class=3D"">http://coliru.stacked=
-crooked.com/a/3578969a94bb175a</a></div><div><br class=3D""></div><div>I=
=E2=80=99d almost call this trivial. <font face=3D"Courier" class=3D"">CAT<=
/font>/<font face=3D"Courier" class=3D"">CAT_LIT</font> is a common utility=
needed for any preprocessor metaprogramming.</div><div><br class=3D""></di=
v></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_A01B896D-CF9A-4013-99C6-58E4AA882D8A--
.
Author: Lingxi Li <lilingxi.cs@gmail.com>
Date: Fri, 9 Oct 2015 05:55:30 -0700 (PDT)
Raw View
------=_Part_2837_891881491.1444395330958
Content-Type: multipart/alternative;
boundary="----=_Part_2838_1119189517.1444395330959"
------=_Part_2838_1119189517.1444395330959
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, October 9, 2015 at 8:00:16 PM UTC+8, David Krauss wrote:
>
>
> On 2015=E2=80=9310=E2=80=9309, at 5:20 PM, Lingxi Li <lilin...@gmail.com =
<javascript:>>=20
> wrote:
>
> How about defining a general grouping macro like
>
> #define ARG(...) __VA_ARGS__
>
> So, the usage would be
>
> Macro(ARG(<int, int>))
>
>
> This macro is what I meant to say for solution A. The approach is very=20
> similar, call it A=E2=80=99. Any macro expecting a template argument list=
might=20
> take a parenthesized argument as a courtesy. For surprising cases you can=
=20
> DIY.
>
>
> On 2015=E2=80=9310=E2=80=9309, at 5:28 PM, Roman Perepelitsa <roman.pe...=
@gmail.com=20
> <javascript:>> wrote:
>
> The implementation of UNPARENTHESIZE_IF_PARENTHESIZED is non-trivial.=20
>
>
> Please, do share.
>
> I believe it also requires a compiler extension (the last one in=20
> https://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html#Variadic-Macros).
>
>
> I=E2=80=99ve proposed this for standardization in N4220 <http://wg21.link=
/N4220>.=20
> Unfortunately, it=E2=80=99s not been reviewed.
>
> It's possible to writing macros that behave well in the presence of=20
> arguments with commas. It's just hard.
>
>
> It=E2=80=99s hard to *optionally* strip parens automatically. It=E2=80=99=
s easy to expect=20
> one level of parens and strip them. It=E2=80=99s also easy to use __VA_AR=
GS__,=20
> albeit ugly.
>
> Bah, my cursed brain went and solved the riddle. I don=E2=80=99t see any =
need for=20
> an extension.
>
> #define UNPAREN(...) UNPAREN __VA_ARGS__
> #define DONE_UNPAREN
>
> #define CAT_LIT(A, ...) A ## __VA_ARGS__
> #define CAT(A, ...) CAT_LIT( A, __VA_ARGS__ )
> #define UNPARENTHESIZE_IF_PARENTHESIZED(...) CAT( DONE_, UNPAREN=20
> __VA_ARGS__ )
>
> http://coliru.stacked-crooked.com/a/3578969a94bb175a
>
> I=E2=80=99d almost call this trivial. CAT/CAT_LIT is a common utility nee=
ded for=20
> any preprocessor metaprogramming.
>
>
I fail to see the point in implementing this UNPARENTHESIZE_IF_PARENTHESIZE=
D thing.=20
The original goal is to pass argument containing commas as a single=20
argument. So, suppose there is a function macro that takes three arguments
#define TERNARY(a, b, c) ...
So how could UNPARENTHESIZE_IF_PARENTHESIZED help with this goal?
TERNARY(UNPARENTHESIZE_IF_PARENTHESIZED(...),=20
UNPARENTHESIZE_IF_PARENTHESIZED(...), UNPARENTHESIZE_IF_PARENTHESIZED(...))
Like this? If so, I don't think it is any better than my ARG macro, except=
=20
that it is much more complex. Or you mean to implement the trick for every=
=20
function macro that wants this functionality? I don't think there would be=
=20
many people thinking that it's worth the effort.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2838_1119189517.1444395330959
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Friday, October 9, 2015 at 8:00:16 PM UTC+8, David Krauss wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-=
word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9310=E2=80=9309=
, at 5:20 PM, Lingxi Li <<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"pW8a6rcHDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">lilin...@gmail.com</a>> wrote:</div><br><div><div=
dir=3D"ltr">How about defining a general grouping macro like<br><div><br><=
div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgro=
und-color:rgb(250,250,250)"><code><span style=3D"color:#800">#define</span>=
ARG<span style=3D"color:#660">(...)</span> __VA_ARGS__</code></div><br>So,=
the usage would be<br><br><div style=3D"border:1px solid rgb(187,187,187);=
word-wrap:break-word;background-color:rgb(250,250,250)"><code><span style=
=3D"color:#606">Macro</span><span style=3D"color:#660">(</span>ARG<span sty=
le=3D"color:#660">(<</span><span style=3D"color:#008">int</span><span st=
yle=3D"color:#660">,</span> <span style=3D"color:#008">int</span><span styl=
e=3D"color:#660">>))</span></code></div></div></div></div></blockquote><=
div><br></div><div>This macro is what I meant to say for solution A. The ap=
proach is very similar, call it A=E2=80=99. Any macro expecting a template =
argument list might take a parenthesized argument as a courtesy. For surpri=
sing cases you can DIY.</div><div><br></div><div><br></div><div><blockquote=
type=3D"cite"><div>On 2015=E2=80=9310=E2=80=9309, at 5:28 PM, Roman Perepe=
litsa <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"pW8a6rcHDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">roman.pe...@gmail.com</a>> wrote:</div><br><div><div>The implemen=
tation of UNPARENTHESIZE_IF_<wbr>PARENTHESIZED is non-trivial. </div></div>=
</blockquote><div><br></div><div>Please, do share.</div><br><blockquote typ=
e=3D"cite"><div><div>I believe it also requires a compiler extension (the l=
ast one in=C2=A0<a href=3D"https://gcc.gnu.org/onlinedocs/gcc/Variadic-Macr=
os.html#Variadic-Macros" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgcc.gnu.org%2=
Fonlinedocs%2Fgcc%2FVariadic-Macros.html%23Variadic-Macros\46sa\75D\46sntz\=
0751\46usg\75AFQjCNFVAEmqVIylzU6LMC7AZrtn732xoQ';return true;" onclick=
=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgcc.gnu.o=
rg%2Fonlinedocs%2Fgcc%2FVariadic-Macros.html%23Variadic-Macros\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNFVAEmqVIylzU6LMC7AZrtn732xoQ';return true;">http=
s://gcc.gnu.org/<wbr>onlinedocs/gcc/Variadic-<wbr>Macros.html#Variadic-Macr=
os</a>).<br></div><div></div></div></blockquote><div><br></div><div>I=E2=80=
=99ve proposed this for standardization in=C2=A0<a href=3D"http://wg21.link=
/N4220" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fwg21.link%2FN4220\46sa\75D\46snt=
z\0751\46usg\75AFQjCNF00RGD-MKwvxPJ3TADDVLBhakQtQ';return true;" onclic=
k=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwg21.link%=
2FN4220\46sa\75D\46sntz\0751\46usg\75AFQjCNF00RGD-MKwvxPJ3TADDVLBhakQtQ'=
;;return true;">N4220</a>. Unfortunately, it=E2=80=99s not been reviewed.</=
div><br><blockquote type=3D"cite"><div><div>It's possible to writing ma=
cros that behave well in the presence of arguments with commas. It's ju=
st hard.</div></div></blockquote><br></div><div>It=E2=80=99s hard to <i>opt=
ionally</i>=C2=A0strip parens automatically. It=E2=80=99s easy to expect on=
e level of parens and strip them. It=E2=80=99s also easy to use <font face=
=3D"Courier">__VA_ARGS__</font>, albeit ugly.</div><div><br></div><div>Bah,=
my cursed brain went and solved the riddle. I don=E2=80=99t see any need f=
or an extension.</div><div><br></div><div><font face=3D"Courier">#define UN=
PAREN(...) UNPAREN __VA_ARGS__<br>#define DONE_UNPAREN<br><br>#define CAT_L=
IT(A, ...) A ## __VA_ARGS__<br>#define CAT(A, ...) CAT_LIT( A, __VA_ARGS__ =
)<br>#define UNPARENTHESIZE_IF_<wbr>PARENTHESIZED(...) CAT( DONE_, UNPAREN =
__VA_ARGS__=C2=A0=C2=A0)<br></font><br></div><div><a href=3D"http://coliru.=
stacked-crooked.com/a/3578969a94bb175a" target=3D"_blank" rel=3D"nofollow" =
onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2F=
coliru.stacked-crooked.com%2Fa%2F3578969a94bb175a\46sa\75D\46sntz\0751\46us=
g\75AFQjCNHVD0b-tFtmwpv2t8wNFvAi3fUrRw';return true;" onclick=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fcoliru.stacked-crooke=
d.com%2Fa%2F3578969a94bb175a\46sa\75D\46sntz\0751\46usg\75AFQjCNHVD0b-tFtmw=
pv2t8wNFvAi3fUrRw';return true;">http://coliru.stacked-crooked.<wbr>com=
/a/3578969a94bb175a</a></div><div><br></div><div>I=E2=80=99d almost call th=
is trivial. <font face=3D"Courier">CAT</font>/<font face=3D"Courier">CAT_LI=
T</font> is a common utility needed for any preprocessor metaprogramming.</=
div><div><br></div></div></div></blockquote><div><br></div><div>I fail to s=
ee the point in implementing this=C2=A0<span style=3D"font-family: Courier;=
">UNPARENTHESIZE_IF_</span><wbr style=3D"font-family: Courier;"><span style=
=3D"font-family: Courier;">PARENTHESIZED</span>=C2=A0thing. The original go=
al is to pass argument containing commas as a single argument. So, suppose =
there is a function macro that takes three arguments<br><br><div class=3D"p=
rettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break=
-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">#define</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> TERNARY</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">...</span></div></code></div><br>So how could <span style=3D"fo=
nt-family: Courier;">UNPARENT</span><font face=3D"courier new, monospace">H=
ESIZE</font><span style=3D"font-family: Courier;">_IF_</span><wbr style=3D"=
font-family: Courier;"><span style=3D"font-family: Courier;">PARENTHESIZED<=
/span>=C2=A0help with this goal?<br><br><div class=3D"prettyprint" style=3D=
"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-co=
lor: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #000;" class=3D"styled-by-prettify">TERNARY<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">UNPARENTHESIZE_IF_PA=
RENTHESIZED</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(...),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> UN=
PARENTHESIZE_IF_PARENTHESIZED</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(...),</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> UNPARENTHESIZE_IF_PARENTHESIZED</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(...))</span></div></code></div><br>Li=
ke this? If so, I don't think it is any better than my <font face=3D"co=
urier new, monospace">ARG</font> macro, except that it is much more complex=
.. Or you mean to implement the trick for every function macro that wants th=
is functionality? I don't think there would be many people thinking tha=
t it's worth the effort.</div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2838_1119189517.1444395330959--
------=_Part_2837_891881491.1444395330958--
.
Author: Roman Perepelitsa <roman.perepelitsa@gmail.com>
Date: Fri, 9 Oct 2015 15:50:32 +0200
Raw View
--001a114128ac9897ae0521ac4447
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Oct 9, 2015 at 1:59 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2015=E2=80=9310=E2=80=9309, at 5:20 PM, Lingxi Li <lilingxi.cs@gmail.c=
om> wrote:
>
> How about defining a general grouping macro like
>
> #define ARG(...) __VA_ARGS__
>
> So, the usage would be
>
> Macro(ARG(<int, int>))
>
>
> This macro is what I meant to say for solution A. The approach is very
> similar, call it A=E2=80=99. Any macro expecting a template argument list=
might
> take a parenthesized argument as a courtesy. For surprising cases you can
> DIY.
>
>
> On 2015=E2=80=9310=E2=80=9309, at 5:28 PM, Roman Perepelitsa <roman.perep=
elitsa@gmail.com>
> wrote:
>
> The implementation of UNPARENTHESIZE_IF_PARENTHESIZED is non-trivial.
>
>
> Please, do share.
>
// Requires Boost.Preprocessor.
#include "boost/boost/preprocessor.hpp"
// Expands to 1 if called without args. Otherwise expands to 0.
// I believe this can't be implemented in pure C or C++ without
extensions.
#define IS_EMPTY(...) IS_EMPTY_I(__VA_ARGS__)
#define IS_EMPTY_I(...) \
BOOST_PP_EQUAL(1, BOOST_PP_VARIADIC_SIZE(_, ##__VA_ARGS__))
// Expands to 1 if the input is parenthesized. Otherwise expands to 0.
#define IS_PARENTHESIZED(...) IS_EMPTY(BOOST_PP_EAT __VA_ARGS__)
// If the input is parenthesized, removes the parentheses. Otherwise
expands to
// the input unchanged.
#define UNPARENTHESIZE_IF_PARENTHESIZED(...) \
BOOST_PP_IF(IS_PARENTHESIZED(__VA_ARGS__), BOOST_PP_REM, \
BOOST_PP_EMPTY()) \
__VA_ARGS__
Note that I'm not an expert in preprocessor. I came up with this macro when
I needed it, and it works fine for my use cases. It might have flaws that I
don't see, and there might be a simpler implementation.
> I believe it also requires a compiler extension (the last one in
> https://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html#Variadic-Macros).
>
>
> I=E2=80=99ve proposed this for standardization in N4220 <http://wg21.link=
/N4220>.
> Unfortunately, it=E2=80=99s not been reviewed.
>
> It's possible to writing macros that behave well in the presence of
> arguments with commas. It's just hard.
>
>
> It=E2=80=99s hard to *optionally* strip parens automatically. It=E2=80=99=
s easy to expect
> one level of parens and strip them. It=E2=80=99s also easy to use __VA_AR=
GS__,
> albeit ugly.
>
> Bah, my cursed brain went and solved the riddle. I don=E2=80=99t see any =
need for
> an extension.
>
> #define UNPAREN(...) UNPAREN __VA_ARGS__
> #define DONE_UNPAREN
>
> #define CAT_LIT(A, ...) A ## __VA_ARGS__
> #define CAT(A, ...) CAT_LIT( A, __VA_ARGS__ )
> #define UNPARENTHESIZE_IF_PARENTHESIZED(...) CAT( DONE_, UNPAREN
> __VA_ARGS__ )
>
> http://coliru.stacked-crooked.com/a/3578969a94bb175a
>
> I=E2=80=99d almost call this trivial. CAT/CAT_LIT is a common utility nee=
ded for
> any preprocessor metaprogramming.
>
This implementation removes *leading*
parentheses: UNPARENTHESIZE_IF_PARENTHESIZED((int)42) expands to `int 42`,
while we need `(int)42`.
On Fri, Oct 9, 2015 at 2:55 PM, Lingxi Li <lilingxi.cs@gmail.com> wrote:
>
>
> I fail to see the point in implementing this UNPARENTHESIZE_IF_
> PARENTHESIZED thing. The original goal is to pass argument containing
> commas as a single argument. So, suppose there is a function macro that
> takes three arguments
>
> #define TERNARY(a, b, c) ...
>
> So how could UNPARENTHESIZE_IF_PARENTHESIZED help with this goal?
>
> TERNARY(UNPARENTHESIZE_IF_PARENTHESIZED(...),
> UNPARENTHESIZE_IF_PARENTHESIZED(...), UNPARENTHESIZE_IF_PARENTHESIZED
> (...))
>
> Like this? If so, I don't think it is any better than my ARG macro,
> except that it is much more complex. Or you mean to implement the trick f=
or
> every function macro that wants this functionality? I don't think there
> would be many people thinking that it's worth the effort.
>
UNPARENTHESIZE_IF_PARENTHESIZED (or UIP for short) should be used inside
the implementation of TERNARY. Here's an example of a macro that accepts a
C++ type as one of the arguments. In order to supports types with commas,
such as pair<int, int>, it passes the type argument through UIP.
// Instead of writing `int x;` you can write `VAR(int, x)`.
#define VAR(type, name) UIP(type) name;
VAR(int, x) =3D> int x;
VAR((pair<int, int>), x) =3D> pair<int, int> x;
Roman Perepelitsa.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a114128ac9897ae0521ac4447
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Oct 9, 2015 at 1:59 PM, David Krauss <span dir=3D"ltr"><<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><spa=
n class=3D""><blockquote type=3D"cite"><div>On 2015=E2=80=9310=E2=80=9309, =
at 5:20 PM, Lingxi Li <<a href=3D"mailto:lilingxi.cs@gmail.com" target=
=3D"_blank">lilingxi.cs@gmail.com</a>> wrote:</div><br><div><div dir=3D"=
ltr">How about defining a general grouping macro like<br><div><br><div styl=
e=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-colo=
r:rgb(250,250,250)"><code><span style=3D"color:rgb(136,0,0)">#define</span>=
ARG<span style=3D"color:rgb(102,102,0)">(...)</span> __VA_ARGS__</code></d=
iv><br>So, the usage would be<br><br><div style=3D"border:1px solid rgb(187=
,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><sp=
an style=3D"color:rgb(102,0,102)">Macro</span><span style=3D"color:rgb(102,=
102,0)">(</span>ARG<span style=3D"color:rgb(102,102,0)">(<</span><span s=
tyle=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(102,102,0)">=
,</span> <span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:=
rgb(102,102,0)">>))</span></code></div></div></div></div></blockquote><d=
iv><br></div></span><div>This macro is what I meant to say for solution A. =
The approach is very similar, call it A=E2=80=99. Any macro expecting a tem=
plate argument list might take a parenthesized argument as a courtesy. For =
surprising cases you can DIY.</div><div><br></div><div><br></div><div><span=
class=3D""><blockquote type=3D"cite"><div>On 2015=E2=80=9310=E2=80=9309, a=
t 5:28 PM, Roman Perepelitsa <<a href=3D"mailto:roman.perepelitsa@gmail.=
com" target=3D"_blank">roman.perepelitsa@gmail.com</a>> wrote:</div><br>=
<div><div>The implementation of UNPARENTHESIZE_IF_PARENTHESIZED is non-triv=
ial. </div></div></blockquote><div><br></div></span><div>Please, do share.<=
/div></div></div></div></blockquote><div><br></div><div><font face=3D"monos=
pace, monospace">=C2=A0 // Requires Boost.Preprocessor.</font></div><div><f=
ont face=3D"monospace, monospace">=C2=A0 #include "boost/boost/preproc=
essor.hpp"</font></div><div><font face=3D"monospace, monospace"><br></=
font></div><div><div><font face=3D"monospace, monospace">=C2=A0 // Expands =
to 1 if called without args. Otherwise expands to 0.</font></div><div><font=
face=3D"monospace, monospace">=C2=A0 // I believe this can't be implem=
ented in pure C or C++ without extensions.</font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 #define IS_EMPTY(...) IS_EMPTY_I(__VA_ARGS__)</=
font></div><div><font face=3D"monospace, monospace">=C2=A0 #define IS_EMPTY=
_I(...) \</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 BOOST_PP_EQUAL(1, BOOST_PP_VARIADIC_SIZE(_, ##__VA_ARGS__))</font></div=
><div><font face=3D"monospace, monospace"><br></font></div><div><font face=
=3D"monospace, monospace">=C2=A0 // Expands to 1 if the input is parenthesi=
zed. Otherwise expands to 0.</font></div><div><font face=3D"monospace, mono=
space">=C2=A0 #define IS_PARENTHESIZED(...) IS_EMPTY(BOOST_PP_EAT __VA_ARGS=
__)</font></div><div><font face=3D"monospace, monospace"><br></font></div><=
div><font face=3D"monospace, monospace">=C2=A0 // If the input is parenthes=
ized, removes the parentheses. Otherwise expands to</font></div><div><font =
face=3D"monospace, monospace">=C2=A0 // the input unchanged.</font></div><d=
iv><font face=3D"monospace, monospace">=C2=A0 #define UNPARENTHESIZE_IF_PAR=
ENTHESIZED(...) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \</font></=
div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 BOOST_PP_IF(IS_P=
ARENTHESIZED(__VA_ARGS__), BOOST_PP_REM, \</font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 BOOST_PP_EMPTY()) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 __VA_ARGS__</font></div></div><div>=
<br></div><div>Note that I'm not an expert in preprocessor. I came up w=
ith this macro when I needed it, and it works fine for my use cases. It mig=
ht have flaws that I don't see, and there might be a simpler implementa=
tion.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><div><=
span class=3D""><blockquote type=3D"cite"><div><div>I believe it also requi=
res a compiler extension (the last one in=C2=A0<a href=3D"https://gcc.gnu.o=
rg/onlinedocs/gcc/Variadic-Macros.html#Variadic-Macros" target=3D"_blank">h=
ttps://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html#Variadic-Macros</a>)=
..<br></div><div></div></div></blockquote><div><br></div></span><div>I=E2=80=
=99ve proposed this for standardization in=C2=A0<a href=3D"http://wg21.link=
/N4220" target=3D"_blank">N4220</a>. Unfortunately, it=E2=80=99s not been r=
eviewed.</div><span class=3D""><br><blockquote type=3D"cite"><div><div>It&#=
39;s possible to writing macros that behave well in the presence of argumen=
ts with commas. It's just hard.</div></div></blockquote><br></span></di=
v><div>It=E2=80=99s hard to <i>optionally</i>=C2=A0strip parens automatical=
ly. It=E2=80=99s easy to expect one level of parens and strip them. It=E2=
=80=99s also easy to use <font face=3D"Courier">__VA_ARGS__</font>, albeit =
ugly.</div><div><br></div><div>Bah, my cursed brain went and solved the rid=
dle. I don=E2=80=99t see any need for an extension.</div><div><br></div><di=
v><font face=3D"Courier">#define UNPAREN(...) UNPAREN __VA_ARGS__<br>#defin=
e DONE_UNPAREN<br><br>#define CAT_LIT(A, ...) A ## __VA_ARGS__<br>#define C=
AT(A, ...) CAT_LIT( A, __VA_ARGS__ )<br>#define UNPARENTHESIZE_IF_PARENTHES=
IZED(...) CAT( DONE_, UNPAREN __VA_ARGS__=C2=A0=C2=A0)<br></font><br></div>=
<div><a href=3D"http://coliru.stacked-crooked.com/a/3578969a94bb175a" targe=
t=3D"_blank">http://coliru.stacked-crooked.com/a/3578969a94bb175a</a></div>=
<div><br></div><div>I=E2=80=99d almost call this trivial. <font face=3D"Cou=
rier">CAT</font>/<font face=3D"Courier">CAT_LIT</font> is a common utility =
needed for any preprocessor metaprogramming.</div></div></div></blockquote>=
<div><br></div><div>This implementation removes <i>leading</i> parentheses:=
=C2=A0UNPARENTHESIZE_IF_PARENTHESIZED((int)42) expands to `int 42`, while w=
e need `(int)42`.</div><div><br></div><div><div class=3D"gmail_quote">On Fr=
i, Oct 9, 2015 at 2:55 PM, Lingxi Li=C2=A0<span dir=3D"ltr"><<a href=3D"=
mailto:lilingxi.cs@gmail.com" target=3D"_blank">lilingxi.cs@gmail.com</a>&g=
t;</span>=C2=A0wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div><br></div><div>I fail to see the=
point in implementing this=C2=A0<span style=3D"font-family:Courier">UNPARE=
NTHESIZE_IF_</span><span style=3D"font-family:Courier">PARENTHESIZED</span>=
=C2=A0thing. The original goal is to pass argument containing commas as a s=
ingle argument. So, suppose there is a function macro that takes three argu=
ments<br><br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:brea=
k-word;background-color:rgb(250,250,250)"><code><span style=3D"color:rgb(13=
6,0,0)">#define</span><span style=3D"color:rgb(0,0,0)">=C2=A0TERNARY</span>=
<span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0=
)">a</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"colo=
r:rgb(0,0,0)">=C2=A0b</span><span style=3D"color:rgb(102,102,0)">,</span><s=
pan style=3D"color:rgb(0,0,0)">=C2=A0c</span><span style=3D"color:rgb(102,1=
02,0)">)</span><span style=3D"color:rgb(0,0,0)">=C2=A0</span><span style=3D=
"color:rgb(102,102,0)">...</span></code></div><br>So how could=C2=A0<span s=
tyle=3D"font-family:Courier">UNPARENT</span><font face=3D"courier new, mono=
space">HESIZE</font><span style=3D"font-family:Courier">_IF_</span><span st=
yle=3D"font-family:Courier">PARENTHESIZED</span>=C2=A0help with this goal?<=
br><br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word=
;background-color:rgb(250,250,250)"><code><span style=3D"color:rgb(0,0,0)">=
TERNARY</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"c=
olor:rgb(0,0,0)">UNPARENTHESIZE_IF_PARENTHESIZED</span><span style=3D"color=
:rgb(102,102,0)">(...),</span><span style=3D"color:rgb(0,0,0)">=C2=A0UNPARE=
NTHESIZE_IF_PARENTHESIZED</span><span style=3D"color:rgb(102,102,0)">(...),=
</span><span style=3D"color:rgb(0,0,0)">=C2=A0UNPARENTHESIZE_IF_PARENTHESIZ=
ED</span><span style=3D"color:rgb(102,102,0)">(...))</span></code></div><br=
>Like this? If so, I don't think it is any better than my=C2=A0<font fa=
ce=3D"courier new, monospace">ARG</font>=C2=A0macro, except that it is much=
more complex. Or you mean to implement the trick for every function macro =
that wants this functionality? I don't think there would be many people=
thinking that it's worth the effort.</div></blockquote><div><br></div>=
<div>UNPARENTHESIZE_IF_PARENTHESIZED (or UIP for short) should be used insi=
de the implementation of TERNARY. Here's an example of a macro that acc=
epts a C++ type as one of the arguments. In order to supports types with co=
mmas, such as pair<int, int>, it passes the type argument through UIP=
..</div><div><br></div><div><font face=3D"monospace, monospace">=C2=A0 // In=
stead of writing `int x;` you can write `VAR(int, x)`.</font></div><div><fo=
nt face=3D"monospace, monospace">=C2=A0 #define VAR(type, name) UIP(type) n=
ame;</font></div><div><font face=3D"monospace, monospace"><br></font></div>=
<div><font face=3D"monospace, monospace">=C2=A0 VAR(int, x) =3D> int x;<=
/font></div><div><font face=3D"monospace, monospace">=C2=A0 VAR((pair<in=
t, int>), x) =3D> pair<int, int> x;</font></div><div><br></div>=
<div>Roman Perepelitsa.</div></div></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a114128ac9897ae0521ac4447--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 10 Oct 2015 00:19:29 +0800
Raw View
--Apple-Mail=_48540BD2-CD39-4FE0-B5C7-107DAB9CA109
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9309, at 9:50 PM, Roman Perepelitsa <roman.perep=
elitsa@gmail.com> wrote:
>=20
> // Requires Boost.Preprocessor.
> #include "boost/boost/preprocessor.hpp"
>=20
> // Expands to 1 if called without args. Otherwise expands to 0.
> // I believe this can't be implemented in pure C or C++ without extensi=
ons.
> #define IS_EMPTY(...) IS_EMPTY_I(__VA_ARGS__)
> #define IS_EMPTY_I(...) \
> BOOST_PP_EQUAL(1, BOOST_PP_VARIADIC_SIZE(_, ##__VA_ARGS__))
>=20
> // Expands to 1 if the input is parenthesized. Otherwise expands to 0.
> #define IS_PARENTHESIZED(...) IS_EMPTY(BOOST_PP_EAT __VA_ARGS__)
>=20
> // If the input is parenthesized, removes the parentheses. Otherwise ex=
pands to
> // the input unchanged.
> #define UNPARENTHESIZE_IF_PARENTHESIZED(...) \
> BOOST_PP_IF(IS_PARENTHESIZED(__VA_ARGS__), BOOST_PP_REM, \
> BOOST_PP_EMPTY()) \
> __VA_ARGS__
>=20
> Note that I'm not an expert in preprocessor. I came up with this macro wh=
en I needed it, and it works fine for my use cases. It might have flaws tha=
t I don't see, and there might be a simpler implementation.
>=20
> http://coliru.stacked-crooked.com/a/3578969a94bb175a <http://coliru.stack=
ed-crooked.com/a/3578969a94bb175a>
>=20
> This implementation removes leading parentheses: UNPARENTHESIZE_IF_PARENT=
HESIZED((int)42) expands to `int 42`, while we need `(int)42`.
Yes, this shortcoming renders it fairly useless for expressions. It=E2=80=
=99s only suitable for typenames and things that can=E2=80=99t start with =
=E2=80=9C(=E2=80=9D.
Unfortunately, your implementation doesn=E2=80=99t work on GCC. The newest,=
most-conforming version of the ,##__VA_ARGS__ extension erases the comma o=
nly when the final comma was absent from the macro argument list. For a mac=
ro parameter list (...), there is no comma to go missing, and the extension=
is never applied. This is what=E2=80=99s proposed in N4220.
I=E2=80=99m not aware of any way to determine that an argument is not empty=
.. A macro can accept only empty arguments and error-out otherwise, but that=
=E2=80=99s no better than always requiring user-supplied parens.
Anyhoo=E2=80=A6 when your macro does work, it=E2=80=99s better than solutio=
n A, and I still like solution A better than the proposal.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_48540BD2-CD39-4FE0-B5C7-107DAB9CA109
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9309, at 9:50 PM, Roman Perepelitsa <<a href=3D"mailto:roman.pere=
pelitsa@gmail.com" class=3D"">roman.perepelitsa@gmail.com</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr"=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-height:=
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform=
: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-=
stroke-width: 0px;" class=3D""><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div class=3D""><font face=3D"monospace, monospace" class=3D"">&n=
bsp; // Requires Boost.Preprocessor.</font></div><div class=3D""><font face=
=3D"monospace, monospace" class=3D""> #include "boost/boost/preproces=
sor.hpp"</font></div><div class=3D""><font face=3D"monospace, monospace" cl=
ass=3D""><br class=3D""></font></div><div class=3D""><div class=3D""><font =
face=3D"monospace, monospace" class=3D""> // Expands to 1 if called w=
ithout args. Otherwise expands to 0.</font></div><div class=3D""><font face=
=3D"monospace, monospace" class=3D""> // I believe this can't be impl=
emented in pure C or C++ without extensions.</font></div><div class=3D""><f=
ont face=3D"monospace, monospace" class=3D""> #define IS_EMPTY(...) I=
S_EMPTY_I(__VA_ARGS__)</font></div><div class=3D""><font face=3D"monospace,=
monospace" class=3D""> #define IS_EMPTY_I(...) \</font></div><div cl=
ass=3D""><font face=3D"monospace, monospace" class=3D""> BOOST=
_PP_EQUAL(1, BOOST_PP_VARIADIC_SIZE(_, ##__VA_ARGS__))</font></div><div cla=
ss=3D""><font face=3D"monospace, monospace" class=3D""><br class=3D""></fon=
t></div><div class=3D""><font face=3D"monospace, monospace" class=3D"">&nbs=
p; // Expands to 1 if the input is parenthesized. Otherwise expands to 0.</=
font></div><div class=3D""><font face=3D"monospace, monospace" class=3D"">&=
nbsp; #define IS_PARENTHESIZED(...) IS_EMPTY(BOOST_PP_EAT __VA_ARGS__)</fon=
t></div><div class=3D""><font face=3D"monospace, monospace" class=3D""><br =
class=3D""></font></div><div class=3D""><font face=3D"monospace, monospace"=
class=3D""> // If the input is parenthesized, removes the parenthese=
s. Otherwise expands to</font></div><div class=3D""><font face=3D"monospace=
, monospace" class=3D""> // the input unchanged.</font></div><div cla=
ss=3D""><font face=3D"monospace, monospace" class=3D""> #define UNPAR=
ENTHESIZE_IF_PARENTHESIZED(...) &=
nbsp; \</font></div><div class=3D""><font face=3D"monospace, monospace" cla=
ss=3D""> BOOST_PP_IF(IS_PARENTHESIZED(__VA_ARGS__), BOOST_PP_R=
EM, \</font></div><div class=3D""><font face=3D"monospace, monospace" class=
=3D""> BOOST_PP_EMPT=
Y()) =
\</font></div><div class=3D""><font face=3D"mono=
space, monospace" class=3D""> __VA_ARGS__</font></div></div><d=
iv class=3D""><br class=3D""></div><div class=3D"">Note that I'm not an exp=
ert in preprocessor. I came up with this macro when I needed it, and it wor=
ks fine for my use cases. It might have flaws that I don't see, and there m=
ight be a simpler implementation.</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color=
: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div st=
yle=3D"word-wrap: break-word;" class=3D""><div class=3D""><div class=3D""><=
br class=3D""></div><div class=3D""><a href=3D"http://coliru.stacked-crooke=
d.com/a/3578969a94bb175a" target=3D"_blank" class=3D"">http://coliru.stacke=
d-crooked.com/a/3578969a94bb175a</a></div><div class=3D""><br class=3D""></=
div></div></div></blockquote><div class=3D"">This implementation removes<sp=
an class=3D"Apple-converted-space"> </span><i class=3D"">leading</i><s=
pan class=3D"Apple-converted-space"> </span>parentheses: UNPARENT=
HESIZE_IF_PARENTHESIZED((int)42) expands to `int 42`, while we need `(int)4=
2`.</div><div class=3D""></div><div class=3D""></div></div></div></div></di=
v></blockquote><div><br class=3D""></div><div>Yes, this shortcoming renders=
it fairly useless for expressions. It=E2=80=99s only suitable for typename=
s and things that can=E2=80=99t start with =E2=80=9C<font face=3D"Courier" =
class=3D"">(</font>=E2=80=9D.</div><div><br class=3D""></div><div>Unfortuna=
tely, your implementation doesn=E2=80=99t work on GCC. The newest, most-con=
forming version of the <font face=3D"Courier" class=3D"">,##__VA_ARGS__</fo=
nt> extension erases the comma only when the final comma was absent from th=
e macro argument list. For a macro parameter list <font face=3D"Courier" cl=
ass=3D"">(...)</font>, there is no comma to go missing, and the extension i=
s never applied. This is what=E2=80=99s proposed in N4220.</div></div><br c=
lass=3D""><div class=3D"">I=E2=80=99m not aware of any way to determine tha=
t an argument is not empty. A macro can accept only empty arguments and err=
or-out otherwise, but that=E2=80=99s no better than always requiring user-s=
upplied parens.</div><div class=3D""><br class=3D""></div><div class=3D"">A=
nyhoo=E2=80=A6 when your macro does work, it=E2=80=99s better than solution=
A, and I still like solution A better than the proposal.</div><div class=
=3D""><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_48540BD2-CD39-4FE0-B5C7-107DAB9CA109--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 9 Oct 2015 13:36:39 -0300
Raw View
On Fri, Oct 9, 2015 at 3:21 AM, David Krauss <potswa@gmail.com> wrote:
>
> On 2015=E2=80=9310=E2=80=9309, at 12:20 PM, dgutson . <danielgutson@gmail=
..com> wrote:
>
> There are situations in which the cpp wrongly takes commas separating
> template arguments as macro arguments delimiters.
> For example:
>
> template <class X, class Y> struct S;
> #define Macro(arg) S arg;
>
> The extra ( ) workaround used in C cannot be used here:
> Macro((<int, int>));
>
>
> Solution A:
>
> #define EXPAND( ARG ) ARG
> #define Macro( ARG ) S EXPAND ARG
>
> Macro((<int, int>))
>
> Solution B:
>
> #define Macro( ... ) S __VA_ARGS__
>
> Macro(<int, int>)
Sorry, I didn't mention that one of the drivers/goals of this proposal
is to enable the interaction of existing macros (or an existing
preprocessor library) without having to modify it. Therefore only the
call site can be controlled.
>
> Solution C:
>
> #define COMMA ,
> Macro(<int COMMA int>)
This can work but is not reader-friendly.
>
> This is important for X-macros for example.
>
>
> What is an X-macro?
An old technique:
https://en.wikipedia.org/wiki/X_Macro
>
> I propose to enhance the cpp to be able to ignore escaped commas (with
> \), so this can be done:
> Macro(<int\, int>);
>
> We already implemented this extension in gcc (patch to be sent on
> Monday) which is working.
> What we did is: comma escaping occurs at the top level, but not inside ( =
).
> For example
> SomeMacro(f(a\,b))
> does no escape the comma and thus has current behavior.
>
>
> I think I still prefer solutions A and B.
I prefer the escaped comma :)
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 9 Oct 2015 13:41:23 -0300
Raw View
On Fri, Oct 9, 2015 at 6:20 AM, Lingxi Li <lilingxi.cs@gmail.com> wrote:
>
>
> On Friday, October 9, 2015 at 2:22:02 PM UTC+8, David Krauss wrote:
>>
>>
>> I think I still prefer solutions A and B.
>>
> How about defining a general grouping macro like
>
> #define ARG(...) __VA_ARGS__
>
> So, the usage would be
>
> Macro(ARG(<int, int>))
Elegant, but I still prefer the escaped comma for readability. Consider:
#define mymacro(T, name) T name
template<class X, class Y>
struct S{};
#define ARG(...) __VA_ARGS__
mymacro(ARG(S<int, int>), s);
versus
mymacro(S<int\, int>, s);
(without extra macros such as ARG() or COMMA).
FWIW, it was a 5 lines patch.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 10 Oct 2015 01:01:46 +0800
Raw View
--Apple-Mail=_965EFE1E-B518-4EA9-9423-4A6E4C3CBB6E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9310, at 12:41 AM, dgutson . <danielgutson@gmail=
..com> wrote:
>=20
> FWIW, it was a 5 lines patch.
I wrote a patch to do macro pre-expansion normally on ,##__VA_ARGS__. On GC=
C, it was ~10 lines. On Clang, ~100. Preprocessor implementations are wildl=
y different. (On my personal one, it was 1 line. Just sayin=E2=80=99.)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_965EFE1E-B518-4EA9-9423-4A6E4C3CBB6E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9310, at 12:41 AM, dgutson . <<a href=3D"mailto:danielgutson@gmai=
l.com" class=3D"">danielgutson@gmail.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D""><span style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: no=
ne; display: inline !important;" class=3D"">FWIW, it was a 5 lines patch.</=
span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: norm=
al; font-variant: normal; font-weight: normal; letter-spacing: normal; line=
-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-t=
ransform: none; white-space: normal; widows: auto; word-spacing: 0px; -webk=
it-text-stroke-width: 0px;" class=3D""></div></blockquote></div><br class=
=3D""><div class=3D"">I wrote a patch to do macro pre-expansion normally on=
<font face=3D"Courier" class=3D"">,##__VA_ARGS__</font>. On GCC, it was ~1=
0 lines. On Clang, ~100. Preprocessor implementations are wildly different.=
(On my personal one, it was 1 line. Just sayin=E2=80=99.)</div><div class=
=3D""><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_965EFE1E-B518-4EA9-9423-4A6E4C3CBB6E--
.
Author: Moritz Klammler <moritz.klammler@gmail.com>
Date: Fri, 09 Oct 2015 23:55:56 +0200
Raw View
> I propose to enhance the cpp to be able to ignore escaped commas
> (with \), so this can be done:
>
> Macro(<int\, int>);
>
> We already implemented this extension in gcc (patch to be sent on
> Monday) which is working.
>
> What we did is: comma escaping occurs at the top level, but not inside
> ( ). For example
>
> SomeMacro(f(a\,b))
>
> does no escape the comma and thus has current behavior.
I'm very much in favor of this!
Some people have posted smart ways to work around the problem with
today's features but many of them are non-trivial and complicated to
understand and apply correctly.
The cleanest solution so far, in my opinion, has been proposed by
Lingxi Li.
#define PROTECT( ... ) __VA_ARGS__
MACRO ( PROTECT( < int, int > ) )
David Krauss' solution I find also okay but somewhat less readable.
#define COMMA ,
MACRO ( < int COMMA int > )
Some other solutions I honestly don't fully understand.
The biggest problem I see with this is that the temptation to do silly
things that pollute the scarce macro name-space like
#define A( ... ) __VA_ARGS__
or
#define C ,
is much too high. In a public header file, I wouldn't even want to
`#define` names like `PROTECT` or `COMMA` and using the above solutions
with names like `MY_PROJECT_INTERNAL_COMMA` quickly becomes unwieldy.
While both solutions are elegant by today's standards, I do think that
they require more understanding of the pre-processor's parsing than a
casual user should need to have in order to do a seemingly simple thing
like passing a template instantiation as a macro argument.
The proposed solution of using a backslash escape is easy to understand
and straight-forward to apply. In fact, I imagine that it might be what
many people would intuitively expect and try when they first encounter
the problem.
As far as I can tell, the proposed addition is at no danger of breaking
anything because a backslash outside of string or character literals has
no defined meaning today. It also does not seem to unreasonably waste
empty spots in the already thin grammar space. If, in the future, the
backslash would be given any meaning for the C++ language, the obvious
consequence would be to allow using `\\` in macro arguments to escape
a backslash per se.
C compatibility is very important for the CPP. I cannot see any reason
this addition would endanger it. If the C standards decides to adopt it
in a future revision, good. If not, and for the time being, every valid
CPP construct by the C standard ought to remain to also be one by the
C++ standard.
Should the feature prove useful, further extensions could be to also
allow escaping unbalanced parenthesis or quotation marks. I'm
hesitating to suggest this, however, because I cannot really think of a
valid use-case but only of many horrible abuses of passing these tokens
around as macro arguments.
Implementing the suggested feature in the pre-processor might not be as
trivial as a five line patch for all CPP implementations out there but I
do believe that it should be possible to modify any reasonably designed
CPP easily enough for this feature to be supported.
As it seems to me, this feature could be so useful that if GCC started
supporting it, people would demand it so much that Clang would follow
shortly after. Then we would have a de facto standard. We could
equally well make it a de jure one right away, thereby avoiding
portability headache.
The CPP is not receiving much love in the C++ community; and right so.
However, one reason it is so little loved is because it is so awkward to
use at times. Making it a little less awkward -- as long as it does not
come at the cost of harming the C++ language itself -- would be a Good
Thing in my opinion.
Moritz
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 13 Oct 2015 01:01:47 -0700 (PDT)
Raw View
------=_Part_120_1779691133.1444723307202
Content-Type: multipart/alternative;
boundary="----=_Part_121_759314802.1444723307202"
------=_Part_121_759314802.1444723307202
Content-Type: text/plain; charset=UTF-8
The problem with all of these approaches is that it gets more or less noisy
at the call site.
If the proposal is to change the CPP anyway, why not put the annotation
where it belongs: At the #define of the macro. When you write the define
you know that a certain macro
parameter is the name of a class and the annotation to avoid ending the
actual at commas between <> should be in the define. For instance like this:
#define MY_DECLARATION(typename B, C) B C;
MY_DECLARATION(map<string, int>, name)
now works as expected.
There may be use cases where you want to send the template parameter list
only, but I think those are quite rare by comparison, and then you can
design the macro to take <string, int> as the actual instead of string, int.
What are the remaining use cases where this would not work?
Den fredag 9 oktober 2015 kl. 23:56:02 UTC+2 skrev Moritz Klammler:
>
> > I propose to enhance the cpp to be able to ignore escaped commas
> > (with \), so this can be done:
> >
> > Macro(<int\, int>);
> >
> > We already implemented this extension in gcc (patch to be sent on
> > Monday) which is working.
> >
> > What we did is: comma escaping occurs at the top level, but not inside
> > ( ). For example
> >
> > SomeMacro(f(a\,b))
> >
> > does no escape the comma and thus has current behavior.
>
> I'm very much in favor of this!
>
> Some people have posted smart ways to work around the problem with
> today's features but many of them are non-trivial and complicated to
> understand and apply correctly.
>
> The cleanest solution so far, in my opinion, has been proposed by
> Lingxi Li.
>
> #define PROTECT( ... ) __VA_ARGS__
>
> MACRO ( PROTECT( < int, int > ) )
>
> David Krauss' solution I find also okay but somewhat less readable.
>
> #define COMMA ,
>
> MACRO ( < int COMMA int > )
>
> Some other solutions I honestly don't fully understand.
>
> The biggest problem I see with this is that the temptation to do silly
> things that pollute the scarce macro name-space like
>
> #define A( ... ) __VA_ARGS__
>
> or
>
> #define C ,
>
> is much too high. In a public header file, I wouldn't even want to
> `#define` names like `PROTECT` or `COMMA` and using the above solutions
> with names like `MY_PROJECT_INTERNAL_COMMA` quickly becomes unwieldy.
>
> While both solutions are elegant by today's standards, I do think that
> they require more understanding of the pre-processor's parsing than a
> casual user should need to have in order to do a seemingly simple thing
> like passing a template instantiation as a macro argument.
>
> The proposed solution of using a backslash escape is easy to understand
> and straight-forward to apply. In fact, I imagine that it might be what
> many people would intuitively expect and try when they first encounter
> the problem.
>
> As far as I can tell, the proposed addition is at no danger of breaking
> anything because a backslash outside of string or character literals has
> no defined meaning today. It also does not seem to unreasonably waste
> empty spots in the already thin grammar space. If, in the future, the
> backslash would be given any meaning for the C++ language, the obvious
> consequence would be to allow using `\\` in macro arguments to escape
> a backslash per se.
>
> C compatibility is very important for the CPP. I cannot see any reason
> this addition would endanger it. If the C standards decides to adopt it
> in a future revision, good. If not, and for the time being, every valid
> CPP construct by the C standard ought to remain to also be one by the
> C++ standard.
>
> Should the feature prove useful, further extensions could be to also
> allow escaping unbalanced parenthesis or quotation marks. I'm
> hesitating to suggest this, however, because I cannot really think of a
> valid use-case but only of many horrible abuses of passing these tokens
> around as macro arguments.
>
> Implementing the suggested feature in the pre-processor might not be as
> trivial as a five line patch for all CPP implementations out there but I
> do believe that it should be possible to modify any reasonably designed
> CPP easily enough for this feature to be supported.
>
> As it seems to me, this feature could be so useful that if GCC started
> supporting it, people would demand it so much that Clang would follow
> shortly after. Then we would have a de facto standard. We could
> equally well make it a de jure one right away, thereby avoiding
> portability headache.
>
> The CPP is not receiving much love in the C++ community; and right so.
> However, one reason it is so little loved is because it is so awkward to
> use at times. Making it a little less awkward -- as long as it does not
> come at the cost of harming the C++ language itself -- would be a Good
> Thing in my opinion.
>
>
> Moritz
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_121_759314802.1444723307202
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The problem with all of these approaches is that it g=
ets more or less noisy at the call site.</div><div><br></div>If the proposa=
l is to change the CPP anyway, why not put the annotation where it belongs:=
At the #define of the macro. When you write the define you know that a cer=
tain macro<div>parameter is the name of a class and the annotation to avoid=
ending the actual at commas between <> should be in the define. For =
instance like this:</div><div><br></div><div>#define MY_DECLARATION(typenam=
e B, C) =C2=A0 =C2=A0B C;</div><div><br></div><div>MY_DECLARATION(map<st=
ring, int>, name)</div><div><br></div><div>now works as expected.</div><=
div><br></div><div>There may be use cases where you want to send the templa=
te parameter list only, but I think those are quite rare by comparison, and=
then you can design the macro to take <string, int> as the actual in=
stead of string, int.</div><div><br></div><div>What are the remaining use c=
ases where this would not work?</div><div><br></div><div><br></div><div><br=
><br>Den fredag 9 oktober 2015 kl. 23:56:02 UTC+2 skrev Moritz Klammler:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">> I propose to enhance the cpp=
to be able to ignore escaped commas
<br>> (with \), so this can be done:
<br>>=20
<br>> =C2=A0 =C2=A0 Macro(<int\, int>);
<br>>=20
<br>> We already implemented this extension in gcc (patch to be sent on
<br>> Monday) which is working.
<br>>=20
<br>> What we did is: comma escaping occurs at the top level, but not in=
side
<br>> ( ). =C2=A0For example
<br>>=20
<br>> =C2=A0 =C2=A0 SomeMacro(f(a\,b))
<br>>=20
<br>> does no escape the comma and thus has current behavior.
<br>
<br>I'm very much in favor of this!
<br>
<br>Some people have posted smart ways to work around the problem with
<br>today's features but many of them are non-trivial and complicated t=
o
<br>understand and apply correctly.
<br>
<br>The cleanest solution so far, in my opinion, has been proposed by
<br>Lingxi Li.
<br>
<br>=C2=A0 =C2=A0 #define PROTECT( ... ) __VA_ARGS__
<br>=C2=A0 =C2=A0=20
<br>=C2=A0 =C2=A0 MACRO ( PROTECT( < int, int > ) )
<br>
<br>David Krauss' solution I find also okay but somewhat less readable.
<br>
<br>=C2=A0 =C2=A0 #define COMMA ,
<br>=C2=A0 =C2=A0=20
<br>=C2=A0 =C2=A0 MACRO ( < int COMMA int > )
<br>
<br>Some other solutions I honestly don't fully understand.
<br>
<br>The biggest problem I see with this is that the temptation to do silly
<br>things that pollute the scarce macro name-space like
<br>
<br>=C2=A0 =C2=A0 #define A( ... ) __VA_ARGS__
<br>
<br>or
<br>
<br>=C2=A0 =C2=A0 #define C ,
<br>
<br>is much too high. =C2=A0In a public header file, I wouldn't even wa=
nt to
<br>`#define` names like `PROTECT` or `COMMA` and using the above solutions
<br>with names like `MY_PROJECT_INTERNAL_COMMA` quickly becomes unwieldy.
<br>
<br>While both solutions are elegant by today's standards, I do think t=
hat
<br>they require more understanding of the pre-processor's parsing than=
a
<br>casual user should need to have in order to do a seemingly simple thing
<br>like passing a template instantiation as a macro argument.
<br>
<br>The proposed solution of using a backslash escape is easy to understand
<br>and straight-forward to apply. =C2=A0In fact, I imagine that it might b=
e what
<br>many people would intuitively expect and try when they first encounter
<br>the problem.
<br>
<br>As far as I can tell, the proposed addition is at no danger of breaking
<br>anything because a backslash outside of string or character literals ha=
s
<br>no defined meaning today. =C2=A0It also does not seem to unreasonably w=
aste
<br>empty spots in the already thin grammar space. =C2=A0If, in the future,=
the
<br>backslash would be given any meaning for the C++ language, the obvious
<br>consequence would be to allow using `\\` in macro arguments to escape
<br>a backslash per se.
<br>
<br>C compatibility is very important for the CPP. =C2=A0I cannot see any r=
eason
<br>this addition would endanger it. =C2=A0If the C standards decides to ad=
opt it
<br>in a future revision, good. =C2=A0If not, and for the time being, every=
valid
<br>CPP construct by the C standard ought to remain to also be one by the
<br>C++ standard.
<br>
<br>Should the feature prove useful, further extensions could be to also
<br>allow escaping unbalanced parenthesis or quotation marks. =C2=A0I'm
<br>hesitating to suggest this, however, because I cannot really think of a
<br>valid use-case but only of many horrible abuses of passing these tokens
<br>around as macro arguments.
<br>
<br>Implementing the suggested feature in the pre-processor might not be as
<br>trivial as a five line patch for all CPP implementations out there but =
I
<br>do believe that it should be possible to modify any reasonably designed
<br>CPP easily enough for this feature to be supported.
<br>
<br>As it seems to me, this feature could be so useful that if GCC started
<br>supporting it, people would demand it so much that Clang would follow
<br>shortly after. =C2=A0Then we would have a de facto standard. =C2=A0We c=
ould
<br>equally well make it a de jure one right away, thereby avoiding
<br>portability headache.
<br>
<br>The CPP is not receiving much love in the C++ community; and right so.
<br>However, one reason it is so little loved is because it is so awkward t=
o
<br>use at times. =C2=A0Making it a little less awkward -- as long as it do=
es not
<br>come at the cost of harming the C++ language itself -- would be a Good
<br>Thing in my opinion.
<br>
<br>
<br>Moritz
<br></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_121_759314802.1444723307202--
------=_Part_120_1779691133.1444723307202--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 13 Oct 2015 16:49:10 +0800
Raw View
--Apple-Mail=_B5A527F8-FF17-4D2F-8081-84D22D2E779E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9313, at 4:01 PM, Bengt Gustafsson <bengt.gustaf=
sson@beamways.com> wrote:
>=20
> The problem with all of these approaches is that it gets more or less noi=
sy at the call site.
Yes.
Also, they all don=E2=80=99t encapsulate very well. Commas revert to being =
ordinary once the unpacked parameter is passed as the argument to another m=
acro. Scalability is sacrificed unless you defer unpacking as long as possi=
ble, as in my Solution A. (Not in Lingxi=E2=80=99s caller-side version, tho=
ugh, which unpacks before passing.)
> What are the remaining use cases where this would not work?
You=E2=80=99ve attacked the problem of type-ids, but left out expressions a=
nd braced lists.
The preprocessor recognizes () as parens, but C++ additionally has <>, {}, =
and [], any of which can enclose a comma within an expression. (The square =
brackets express lambda captures.)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_B5A527F8-FF17-4D2F-8081-84D22D2E779E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9313, at 4:01 PM, Bengt Gustafsson <<a href=3D"mailto:bengt.gusta=
fsson@beamways.com" class=3D"">bengt.gustafsson@beamways.com</a>> wrote:=
</div><br class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"l=
tr" class=3D""><div class=3D"">The problem with all of these approaches is =
that it gets more or less noisy at the call site.</div><div class=3D""></di=
v></div></div></blockquote><div><br class=3D""></div><div>Yes.</div><div><b=
r class=3D""></div><div>Also, they all don=E2=80=99t encapsulate very well.=
Commas revert to being ordinary once the unpacked parameter is passed as t=
he argument to another macro. Scalability is sacrificed unless you defer un=
packing as long as possible, as in my Solution A. (Not in Lingxi=E2=80=99s =
caller-side version, though, which unpacks before passing.)</div><br class=
=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr"=
class=3D"">What are the remaining use cases where this would not work?</di=
v></div></blockquote><br class=3D""></div><div>You=E2=80=99ve attacked the =
problem of type-ids, but left out expressions and braced lists.</div><br cl=
ass=3D""><div class=3D"">The preprocessor recognizes <font face=3D"Courier"=
class=3D"">()</font> as parens, but C++ additionally has <font face=3D"Cou=
rier" class=3D""><></font>, <font face=3D"Courier" class=3D"">{}</fon=
t>, and <font face=3D"Courier" class=3D"">[]</font>, any of which can enclo=
se a comma within an expression. (The square brackets express lambda captur=
es.)</div><div class=3D""><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_B5A527F8-FF17-4D2F-8081-84D22D2E779E--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 13 Oct 2015 09:59:36 -0400
Raw View
On 2015-10-13 04:01, Bengt Gustafsson wrote:
> The problem with all of these approaches is that it gets more or less noisy
> at the call site.
>
> If the proposal is to change the CPP anyway, why not put the annotation
> where it belongs: At the #define of the macro. When you write the define
> you know that a certain macro
> parameter is the name of a class and the annotation to avoid ending the
> actual at commas between <> should be in the define. For instance like this:
>
> #define MY_DECLARATION(typename B, C) B C;
>
> MY_DECLARATION(map<string, int>, name)
>
> now works as expected.
Why not:
#deffun MY_DECLARATION(A, B)
....and perform argument splitting as if MY_DECLARATION were a regular
C++ function and not a macro? This would preclude feeding it arguments
with unbalanced tokens, but how often does that happen in practice? (We
still would have #define and the previously mentioned work-arounds in
case of that need.)
Then you could do something like:
MY_FUNCTION(map<int, pair<int, float>>, []{
int x = 0, y[] = { 1, 2, 3, 4 };
// ...
})
....with all sorts of commas in the arguments, but the compiler knows how
to parse it via token balancing.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 13 Oct 2015 11:30:48 -0300
Raw View
On Tue, Oct 13, 2015 at 10:59 AM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
> On 2015-10-13 04:01, Bengt Gustafsson wrote:
>> The problem with all of these approaches is that it gets more or less no=
isy
>> at the call site.
>>
>> If the proposal is to change the CPP anyway, why not put the annotation
>> where it belongs: At the #define of the macro. When you write the define
>> you know that a certain macro
>> parameter is the name of a class and the annotation to avoid ending the
>> actual at commas between <> should be in the define. For instance like t=
his:
>>
>> #define MY_DECLARATION(typename B, C) B C;
>>
>> MY_DECLARATION(map<string, int>, name)
>>
>> now works as expected.
>
> Why not:
>
> #deffun MY_DECLARATION(A, B)
>
> ...and perform argument splitting as if MY_DECLARATION were a regular
> C++ function and not a macro? This would preclude feeding it arguments
> with unbalanced tokens, but how often does that happen in practice? (We
> still would have #define and the previously mentioned work-arounds in
> case of that need.)
>
> Then you could do something like:
>
> MY_FUNCTION(map<int, pair<int, float>>, []{
> int x =3D 0, y[] =3D { 1, 2, 3, 4 };
> // ...
> })
>
> ...with all sorts of commas in the arguments, but the compiler knows how
> to parse it via token balancing.
Guys, thanks for all your feedback.
Please note:
a) that I already explicitly stated that I do want to focus on the
calling side, since the macro may belong to a 3rd party library and/or
a C library
b) that I don't want to teach C++ to the preprocessor (which also
will involve a very large change), so keywords such as 'typename' or
complicated grammar is out of scope of my (arguably trivial) proposal.
c) that token balancing (which can be also categorized as teaching
C++ to the CPP) is not useful, since c.1) it may brake existing code,
and c.2) does not work in the following examples:
#define IF(condition1, condition2) if(lower condition1 && condition2 upp=
er)
IF(<b, c>) return 1;
#define BRACKET(x) x] =3D 1
BRACKET(a[1);
d) I try to keep things simple. I state that my proposal is a
minimal as it can be.
If anybody prefers the "teach C++ to the preprocessor" approach, I
invite you to write your own (separate) proposal so there will be two
solutions to vote for. My proposal stays simple.
At this point, please let me know if there would be a champion to
co-author (or be a reviewer) and present this in a WG21 meeting.
Thanks!
Daniel.
>
> --
> Matthew
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Tue, 13 Oct 2015 08:56:13 -0700 (PDT)
Raw View
------=_Part_73_164067344.1444751773789
Content-Type: multipart/alternative;
boundary="----=_Part_74_1591708190.1444751773796"
------=_Part_74_1591708190.1444751773796
Content-Type: text/plain; charset=UTF-8
On Tuesday, October 13, 2015 at 7:00:07 AM UTC-7, Matthew Woehlke wrote:
>
> Why not:
>
> #deffun MY_DECLARATION(A, B)
>
> ...and perform argument splitting as if MY_DECLARATION were a regular
> C++ function and not a macro? This would preclude feeding it arguments
>
Because the preprocessor is a completely separate translation stage that
happens way before we can disambiguate < between the start of template
parameters and a less-than operator. C++ has a nasty grammar and cannot be
disambiguated without at least a little semantic insight (e.g. name tables
to know if an identifier refers to a type or template, among other things).
Also, preprocessor changes in C++ are pretty iffy. I don't see fundamental
changes or new features to the preprocessor originating in WG21 as a likely
eventuality. Which applies to this whole thread, of course, not just your
suggestion. :)
> --
> Matthew
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_74_1591708190.1444751773796
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 13, 2015 at 7:00:07 AM UTC-7, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Why not:
<br>
<br>=C2=A0 #deffun MY_DECLARATION(A, B)
<br>
<br>...and perform argument splitting as if MY_DECLARATION were a regular
<br>C++ function and not a macro? This would preclude feeding it arguments
<br></blockquote><div><br></div><div>Because the preprocessor is a complete=
ly separate translation stage that happens way before we can disambiguate &=
lt; between the start of template parameters and a less-than operator. C++ =
has a nasty grammar and cannot be disambiguated without at least a little s=
emantic insight (e.g. name tables to know if an identifier refers to a type=
or template, among other things).</div><div><br></div><div>Also, preproces=
sor changes in C++ are pretty iffy. I don't see fundamental changes or =
new features to the preprocessor originating in WG21 as a likely eventualit=
y. Which applies to this whole thread, of course, not just your suggestion.=
:)</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">--=
=20
<br>Matthew
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_74_1591708190.1444751773796--
------=_Part_73_164067344.1444751773789--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 13 Oct 2015 13:01:13 -0300
Raw View
--089e0115ec1028d2120521fe8ec7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 13/10/2015 12:56, "Sean Middleditch" <sean.middleditch@gmail.com>
escribi=C3=B3:
>
> On Tuesday, October 13, 2015 at 7:00:07 AM UTC-7, Matthew Woehlke wrote:
>>
>> Why not:
>>
>> #deffun MY_DECLARATION(A, B)
>>
>> ...and perform argument splitting as if MY_DECLARATION were a regular
>> C++ function and not a macro? This would preclude feeding it arguments
>
>
> Because the preprocessor is a completely separate translation stage that
happens way before we can disambiguate < between the start of template
parameters and a less-than operator. C++ has a nasty grammar and cannot be
disambiguated without at least a little semantic insight (e.g. name tables
to know if an identifier refers to a type or template, among other things).
>
> Also, preprocessor changes in C++ are pretty iffy. I don't see
fundamental changes or new features to the preprocessor originating in WG21
as a likely eventuality. Which applies to this whole thread, of course, not
just your suggestion. :)
Why is this so hard? I can write this as a C proposal as a last resort. But
the C++ preprocessor is already different than the C one, I still don't
understand the 'go to C first' specially considering that this problem does
not affect to C, why would they even care?
So what was the history regarding the // comments? That's the first
historic difference that comes to my mind now.
>
>>
>> --
>> Matthew
>>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e0115ec1028d2120521fe8ec7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 13/10/2015 12:56, "Sean Middleditch" <<a href=3D"mailto:sea=
n.middleditch@gmail.com">sean.middleditch@gmail.com</a>> escribi=C3=B3:<=
br>
><br>
> On Tuesday, October 13, 2015 at 7:00:07 AM UTC-7, Matthew Woehlke wrot=
e:<br>
>><br>
>> Why not: <br>
>><br>
>> =C2=A0 #deffun MY_DECLARATION(A, B) <br>
>><br>
>> ...and perform argument splitting as if MY_DECLARATION were a regu=
lar <br>
>> C++ function and not a macro? This would preclude feeding it argum=
ents <br>
><br>
><br>
> Because the preprocessor is a completely separate translation stage th=
at happens way before we can disambiguate < between the start of templat=
e parameters and a less-than operator. C++ has a nasty grammar and cannot b=
e disambiguated without at least a little semantic insight (e.g. name table=
s to know if an identifier refers to a type or template, among other things=
).<br>
><br>
> Also, preprocessor changes in C++ are pretty iffy. I don't see fun=
damental changes or new features to the preprocessor originating in WG21 as=
a likely eventuality. Which applies to this whole thread, of course, not j=
ust your suggestion. :)</p>
<p dir=3D"ltr">Why is this so hard? I can write this as a C proposal as a l=
ast resort. But the C++ preprocessor is already different than the C one, I=
still don't understand the 'go to C first' specially consideri=
ng that this problem does not affect to C, why would they even care?<br>
So what was the history regarding the // comments? That's the first his=
toric difference that comes to my mind now.</p>
<p dir=3D"ltr">> =C2=A0<br>
>><br>
>> -- <br>
>> Matthew <br>
>><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0115ec1028d2120521fe8ec7--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 14 Oct 2015 00:59:38 +0800
Raw View
--Apple-Mail=_E3C20709-4487-47AB-A2B9-378E48773746
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9314, at 12:01 AM, dgutson . <danielgutson@gmail=
..com> wrote:
>=20
> Why is this so hard? I can write this as a C proposal as a last resort. B=
ut the C++ preprocessor is already different than the C one
It depends what you mean by =E2=80=9Cpreprocessor.=E2=80=9D C++ lexes token=
s differently but macro and directive processing are the same (predefined v=
alues aside). When it comes to other languages, all have lexers and tokens =
but most don=E2=80=99t have =E2=80=9Cpreprocessors.=E2=80=9D So you could s=
ay that C and C++ are different languages with the same preprocessor.
> So what was the history regarding the // comments? That's the first histo=
ric difference that comes to my mind now.
C99 added // comments. But, comments are part of lexing.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_E3C20709-4487-47AB-A2B9-378E48773746
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9314, at 12:01 AM, dgutson . <<a href=3D"mailto:danielgutson@gmai=
l.com" class=3D"">danielgutson@gmail.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D""><span style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: no=
ne; display: inline !important;" class=3D"">Why is this so hard? I can writ=
e this as a C proposal as a last resort. But the C++ preprocessor is alread=
y different than the C one</span></div></blockquote></div><br class=3D""><d=
iv class=3D"">It depends what you mean by =E2=80=9Cpreprocessor.=E2=80=9D C=
++ lexes tokens differently but macro and directive processing are the same=
(predefined values aside). When it comes to other languages, all have lexe=
rs and tokens but most don=E2=80=99t have =E2=80=9Cpreprocessors.=E2=80=9D =
So you could say that C and C++ are different languages with the same prepr=
ocessor.</div><div class=3D""><br class=3D""></div><div class=3D""><blockqu=
ote type=3D"cite" class=3D""><div class=3D"">So what was the history regard=
ing the // comments? That's the first historic difference that comes to my =
mind now.</div></blockquote><br class=3D""></div><div class=3D"">C99 added =
<font face=3D"Courier" class=3D"">//</font> comments. But, comments are par=
t of lexing.</div><div class=3D""><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_E3C20709-4487-47AB-A2B9-378E48773746--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 13 Oct 2015 14:38:11 -0300
Raw View
On Tue, Oct 13, 2015 at 1:59 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2015=E2=80=9310=E2=80=9314, at 12:01 AM, dgutson . <danielgutson@gmail=
..com> wrote:
>
> Why is this so hard? I can write this as a C proposal as a last resort. B=
ut
> the C++ preprocessor is already different than the C one
>
>
> It depends what you mean by =E2=80=9Cpreprocessor.=E2=80=9D C++ lexes tok=
ens differently but
> macro and directive processing are the same (predefined values aside). Wh=
en
> it comes to other languages, all have lexers and tokens but most don=E2=
=80=99t have
> =E2=80=9Cpreprocessors.=E2=80=9D So you could say that C and C++ are diff=
erent languages
> with the same preprocessor.
So, in short: considering that this is not an issue for C, where
should this proposal go?
>
> So what was the history regarding the // comments? That's the first histo=
ric
> difference that comes to my mind now.
>
>
> C99 added // comments. But, comments are part of lexing.
I know about C99, but I'm asking for the history behind the // : how
was that added at that time?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 13 Oct 2015 11:47:32 -0700
Raw View
On Tuesday 13 October 2015 14:38:11 dgutson . wrote:
> > C99 added // comments. But, comments are part of lexing.
>
> I know about C99, but I'm asking for the history behind the // : how
> was that added at that time?
By changing the C preprocessor to accept it too. You may remember that even in
C89 mode, most C compilers accept // comments, unless they've been placed in
strict C89 mode.
So, yes, you can turn some features on and off in the preprocessor.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 13 Oct 2015 12:18:49 -0700 (PDT)
Raw View
------=_Part_6130_2081055880.1444763929188
Content-Type: multipart/alternative;
boundary="----=_Part_6131_374685604.1444763929188"
------=_Part_6131_374685604.1444763929188
Content-Type: text/plain; charset=UTF-8
On Tuesday, October 13, 2015 at 2:47:40 PM UTC-4, Thiago Macieira wrote:
>
> On Tuesday 13 October 2015 14:38:11 dgutson . wrote:
> > > C99 added // comments. But, comments are part of lexing.
> >
> > I know about C99, but I'm asking for the history behind the // : how
> > was that added at that time?
>
> By changing the C preprocessor to accept it too. You may remember that
> even in
> C89 mode, most C compilers accept // comments, unless they've been placed
> in
> strict C89 mode.
>
> So, yes, you can turn some features on and off in the preprocessor.
>
The point he's making is some are arguing that his suggestion isn't
acceptable because it would have to be proposed to the C standards
committee first, then propagate up to C++. And he's showing that the two
preprocessors already can have significant differences between them, so
there is no reason why there can't be one more.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6131_374685604.1444763929188
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 13, 2015 at 2:47:40 PM UTC-4, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday 13 Oc=
tober 2015 14:38:11 dgutson . wrote:
<br>> > C99 added // comments. But, comments are part of lexing.
<br>>=20
<br>> I know about C99, but I'm asking for the history behind the //=
: how
<br>> was that added at that time?
<br>
<br>By changing the C preprocessor to accept it too. You may remember that =
even in=20
<br>C89 mode, most C compilers accept // comments, unless they've been =
placed in=20
<br>strict C89 mode.
<br>
<br>So, yes, you can turn some features on and off in the preprocessor.
<br></blockquote><div><br>The point he's making is some are arguing tha=
t his suggestion isn't acceptable because it would have to be proposed =
to the C standards committee first, then propagate up to C++. And he's =
showing that the two preprocessors already can have significant differences=
between them, so there is no reason why there can't be one more.<br></=
div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6131_374685604.1444763929188--
------=_Part_6130_2081055880.1444763929188--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 13 Oct 2015 16:20:27 -0300
Raw View
--089e011825c0a006d705220156f9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 13/10/2015 15:47, "Thiago Macieira" <thiago@macieira.org> escribi=C3=B3:
>
> On Tuesday 13 October 2015 14:38:11 dgutson . wrote:
> > > C99 added // comments. But, comments are part of lexing.
> >
> > I know about C99, but I'm asking for the history behind the // : how
> > was that added at that time?
>
> By changing the C preprocessor to accept it too. You may remember that
even in
> C89 mode, most C compilers accept // comments, unless they've been placed
in
> strict C89 mode.
Ok, I see, the problem with this is that this is a C++-only thing (wereas
the // was a useful addition for C), so there's no reason the C Committee
could be interested in accepting it, so I foresee a dead end in that way.
Is your advise to still try it anyway?
>
> So, yes, you can turn some features on and off in the preprocessor.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e011825c0a006d705220156f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 13/10/2015 15:47, "Thiago Macieira" <<a href=3D"mailto:thia=
go@macieira.org">thiago@macieira.org</a>> escribi=C3=B3:<br>
><br>
> On Tuesday 13 October 2015 14:38:11 dgutson . wrote:<br>
> > > C99 added // comments. But, comments are part of lexing.<br>
> ><br>
> > I know about C99, but I'm asking for the history behind the /=
/ : how<br>
> > was that added at that time?<br>
><br>
> By changing the C preprocessor to accept it too. You may remember that=
even in<br>
> C89 mode, most C compilers accept // comments, unless they've been=
placed in<br>
> strict C89 mode.</p>
<p dir=3D"ltr">Ok, I see, the problem with this is that this is a C++-only =
thing (wereas the // was a useful addition for C), so there's no reason=
the C Committee could be interested in accepting it, so I foresee a dead e=
nd in that way. Is your advise to still try it anyway?</p>
<p dir=3D"ltr">><br>
> So, yes, you can turn some features on and off in the preprocessor.<br=
>
> --<br>
> Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info">macieir=
a.info</a> - thiago (AT) <a href=3D"http://kde.org">kde.org</a><br>
> =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<=
br>
> =C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
> =C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF=
4 5358<br>
><br>
> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e011825c0a006d705220156f9--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 13 Oct 2015 14:51:39 -0700
Raw View
On Tuesday 13 October 2015 16:20:27 dgutson . wrote:
> Ok, I see, the problem with this is that this is a C++-only thing (wereas
> the // was a useful addition for C), so there's no reason the C Committee
> could be interested in accepting it, so I foresee a dead end in that way.
Right.
> Is your advise to still try it anyway?
It's up to you. I don't think you'll be able to come up with a technically
valid proposal for C++ alone, much less one that the C committee will be
interested in hearing.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 13 Oct 2015 19:51:04 -0300
Raw View
On Tue, Oct 13, 2015 at 6:51 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On Tuesday 13 October 2015 16:20:27 dgutson . wrote:
>> Ok, I see, the problem with this is that this is a C++-only thing (werea=
s
>> the // was a useful addition for C), so there's no reason the C Committe=
e
>> could be interested in accepting it, so I foresee a dead end in that way=
..
>
> Right.
>
>> Is your advise to still try it anyway?
>
> It's up to you. I don't think you'll be able to come up with a technicall=
y
> valid proposal for C++ alone, much less one that the C committee will be
> interested in hearing.
Interested in hearing but uninterested in implementing?
Does anybody know the C committee mailing list?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 13 Oct 2015 21:21:01 -0700
Raw View
On Tuesday 13 October 2015 19:51:04 dgutson . wrote:
> On Tue, Oct 13, 2015 at 6:51 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> > On Tuesday 13 October 2015 16:20:27 dgutson . wrote:
> >> Ok, I see, the problem with this is that this is a C++-only thing (wereas
> >> the // was a useful addition for C), so there's no reason the C Committee
> >> could be interested in accepting it, so I foresee a dead end in that way.
> >
> > Right.
> >
> >> Is your advise to still try it anyway?
> >
> > It's up to you. I don't think you'll be able to come up with a technically
> > valid proposal for C++ alone, much less one that the C committee will be
> > interested in hearing.
>
> Interested in hearing but uninterested in implementing?
>
> Does anybody know the C committee mailing list?
I don't think they do things over email. They appear to only follow the ISO
requirements.
There must be a way to publish papers for their consideration, but I don't
know how.
See http://www.open-std.org/jtc1/sc22/wg14/www/contacts, maybe those folks can
help you.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 14 Oct 2015 01:31:43 -0700 (PDT)
Raw View
------=_Part_30_968536401.1444811503246
Content-Type: multipart/alternative;
boundary="----=_Part_31_330044866.1444811503246"
------=_Part_31_330044866.1444811503246
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I don't think that the C preprocessor compatiblity issue is a real one.=20
This is just a way to avoid having to think about preprocessor improvements=
..
I like the deffun idea but as someone pointed out we would have to=20
sacrifice the possibility of sending an expression containing a < in the=20
"less than" meaning to such a macro. This is of course sad but I see no way=
=20
that we could parse both meanings of < correctly at the time the=20
preprocessor runs as this requires knowledge of what identifiers stand for=
=20
(templates or variables).
This brings us back to my suggestion with "typename" annotation on macro=20
formals, which lacks the ability to handle braced lists and lambda capture=
=20
lists. I think this still covers most interesting sue cases (combined if=20
needed with a __VA_ARGS__ handling to make sure everything in a tail=20
argument gets expanded properly). I very seldom see macros which take TWO=
=20
arguments containing "arbitrary" code, which would be the remaining problem=
..
But maybe this is too much to ask, and if so I still think that the=20
original \ proposal to quote a comma is reasonable even if it requires more=
=20
teaching of how, where and why this escaping has to be done.=20
One sticky point could be combination effect with the #ARG possibility=20
inside the macro body, which makes a call site with a \, combination at=20
least mean something:
#define MACRO(STR,VAL) MyFun(#STR, VAL)
MACRO(\, 3)
Well I don't really know what this expands to today, but probably:
MyFun("\", 3)
which subsequently produces a mismatched " error or
MyFun("\\", 3)
which is potentially useful I guess.
Even if there is some piece of code out there that uses this it must be=20
only a handful of places in total.
I tried this on VS and there is no compiler added escaping (first case). I=
=20
don't know if it is compilant but it at least makes any potentially useful=
=20
cases incompatible with the Microsoft compiler, which talks for this=20
proposal.
Den fredag 9 oktober 2015 kl. 06:20:22 UTC+2 skrev dgutson:
>
> There are situations in which the cpp wrongly takes commas separating=20
> template arguments as macro arguments delimiters.=20
> For example:=20
>
> template <class X, class Y> struct S;=20
> #define Macro(arg) S arg;=20
>
> The extra ( ) workaround used in C cannot be used here:=20
> Macro((<int, int>));=20
>
> This is important for X-macros for example.=20
>
> I propose to enhance the cpp to be able to ignore escaped commas (with=20
> \), so this can be done:=20
> Macro(<int\, int>);=20
>
> We already implemented this extension in gcc (patch to be sent on=20
> Monday) which is working.=20
> What we did is: comma escaping occurs at the top level, but not inside (=
=20
> ).=20
> For example=20
> SomeMacro(f(a\,b))=20
> does no escape the comma and thus has current behavior.=20
>
> Feedback?=20
>
> Thanks,=20
>
> Daniel.=20
>
> --=20
> Who=E2=80=99s got the sweetest disposition?=20
> One guess, that=E2=80=99s who?=20
> Who=E2=80=99d never, ever start an argument?=20
> Who never shows a bit of temperament?=20
> Who's never wrong but always right?=20
> Who'd never dream of starting a fight?=20
> Who get stuck with all the bad luck?=20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_31_330044866.1444811503246
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I don't think that the C preprocessor compatiblit=
y issue is a real one. This is just a way to avoid having to think about pr=
eprocessor improvements.</div><div><br></div>I like the deffun idea but as =
someone pointed out we would have to sacrifice the possibility of sending a=
n expression containing a < in the "less than" meaning to such=
a macro. This is of course sad but I see no way that we could parse both m=
eanings of < correctly at the time the preprocessor runs as this require=
s knowledge of what identifiers stand for (templates or variables).<div><br=
></div><div>This brings us back to my suggestion with "typename" =
annotation on macro formals, which lacks the ability to handle braced lists=
and lambda capture lists. I think this still covers most interesting sue c=
ases (combined if needed with a __VA_ARGS__ handling to make sure everythin=
g in a tail argument gets expanded properly). I very seldom see macros whic=
h take TWO arguments containing "arbitrary" code, which would be =
the remaining problem.</div><div><br></div><div>But maybe this is too much =
to ask, and if so I still think that the original \ proposal to quote a com=
ma is reasonable even if it requires more teaching of how, where and why th=
is escaping has to be done.=C2=A0</div><div><br></div><div>One sticky point=
could be combination effect with the #ARG possibility inside the macro bod=
y, which makes a call site with a \, combination at least mean something:</=
div><div><br></div><div>#define MACRO(STR,VAL) MyFun(#STR, VAL)</div><div><=
br></div><div>MACRO(\, 3)</div><div><br></div><div>Well I don't really =
know what this expands to today, but probably:</div><div><br></div><div>MyF=
un("\", 3)</div><div><br></div><div>which subsequently produces a=
mismatched " error or</div><div><br></div><div>MyFun("\\", =
3)</div><div><br></div><div>which is potentially useful I guess.</div><div>=
<br></div><div>Even if there is some piece of code out there that uses this=
it must be only a handful of places in total.</div><div><br></div><div>I t=
ried this on VS and there is no compiler added escaping (first case). I don=
't know if it is compilant but it at least makes any potentially useful=
cases incompatible with the Microsoft compiler, which talks for this propo=
sal.</div><div><br></div><div><br></div><div><br></div><div><div><br>Den fr=
edag 9 oktober 2015 kl. 06:20:22 UTC+2 skrev dgutson:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">There are situations in which the cpp wrongly takes =
commas separating
<br>template arguments as macro arguments delimiters.
<br>For example:
<br>
<br>template <class X, class Y> struct S;
<br>#define Macro(arg) S arg;
<br>
<br>The extra ( ) workaround used in C cannot be used here:
<br>=C2=A0 =C2=A0 Macro((<int, int>));
<br>
<br>This is important for X-macros for example.
<br>
<br>I propose to enhance the cpp to be able to ignore escaped commas (with
<br>\), so this can be done:
<br>=C2=A0 =C2=A0 Macro(<int\, int>);
<br>
<br>We already implemented this extension in gcc (patch to be sent on
<br>Monday) which is working.
<br>What we did is: comma escaping occurs at the top level, but not inside =
( ).
<br>For example
<br>=C2=A0 =C2=A0 SomeMacro(f(a\,b))
<br>does no escape the comma and thus has current behavior.
<br>
<br>Feedback?
<br>
<br>Thanks,
<br>
<br>=C2=A0 =C2=A0Daniel.
<br>
<br>--=20
<br>Who=E2=80=99s got the sweetest disposition?
<br>One guess, that=E2=80=99s who?
<br>Who=E2=80=99d never, ever start an argument?
<br>Who never shows a bit of temperament?
<br>Who's never wrong but always right?
<br>Who'd never dream of starting a fight?
<br>Who get stuck with all the bad luck?
<br></blockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_31_330044866.1444811503246--
------=_Part_30_968536401.1444811503246--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 14 Oct 2015 11:00:40 -0400
Raw View
On 2015-10-14 04:31, Bengt Gustafsson wrote:
> I like the deffun idea but as someone pointed out we would have to
> sacrifice the possibility of sending an expression containing a < in the
> "less than" meaning to such a macro. This is of course sad but I see no way
> that we could parse both meanings of < correctly at the time the
> preprocessor runs as this requires knowledge of what identifiers stand for
> (templates or variables).
You'd have to put such an expression in ()'s. If it's really an
expression, presumably you could do so.
This also assumes that #deffun wouldn't bite the bullet and defer
expansion until a later stage in processing, i.e. one where the compiler
knows about types and could treat it as something more like an inline
function call.
As others have noted, however, such a proposal being accepted seems
unfortunately unlikely. Code generation (PP and otherwise) is an area I
think could very much be improved, but there is a lot of inertia against
doing so.
Maybe someone feeling sufficiently motivated should just write a new,
stand-alone preprocessor that doesn't restrict itself to the existing
CPP and publish it. Then try to get it integrated into gcc and/or clang.
(Bonus points for making it a BSD library so that the implementation can
be shared.) There's nothing in the standard that says one cannot feed
generated code into the compiler, after all.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 27 Oct 2015 17:32:18 -0300
Raw View
(intentionally top posted)
FWIW, status is:
- patch: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02957.html
- WG14 contacted (David Keaton, the convener)
Daniel.
On Wed, Oct 14, 2015 at 12:00 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
> On 2015-10-14 04:31, Bengt Gustafsson wrote:
>> I like the deffun idea but as someone pointed out we would have to
>> sacrifice the possibility of sending an expression containing a < in the
>> "less than" meaning to such a macro. This is of course sad but I see no =
way
>> that we could parse both meanings of < correctly at the time the
>> preprocessor runs as this requires knowledge of what identifiers stand f=
or
>> (templates or variables).
>
> You'd have to put such an expression in ()'s. If it's really an
> expression, presumably you could do so.
>
> This also assumes that #deffun wouldn't bite the bullet and defer
> expansion until a later stage in processing, i.e. one where the compiler
> knows about types and could treat it as something more like an inline
> function call.
>
> As others have noted, however, such a proposal being accepted seems
> unfortunately unlikely. Code generation (PP and otherwise) is an area I
> think could very much be improved, but there is a lot of inertia against
> doing so.
>
> Maybe someone feeling sufficiently motivated should just write a new,
> stand-alone preprocessor that doesn't restrict itself to the existing
> CPP and publish it. Then try to get it integrated into gcc and/or clang.
> (Bonus points for making it a BSD library so that the implementation can
> be shared.) There's nothing in the standard that says one cannot feed
> generated code into the compiler, after all.
>
> --
> Matthew
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 30 Oct 2015 19:15:19 -0300
Raw View
On Tue, Oct 27, 2015 at 5:32 PM, dgutson . <danielgutson@gmail.com> wrote:
> (intentionally top posted)
>
> FWIW, status is:
> - patch: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02957.html
> - WG14 contacted (David Keaton, the convener)
I'm bringing another situation where this is important: lambda capture list=
..
>
> Daniel.
>
>
> On Wed, Oct 14, 2015 at 12:00 PM, Matthew Woehlke
> <mwoehlke.floss@gmail.com> wrote:
>> On 2015-10-14 04:31, Bengt Gustafsson wrote:
>>> I like the deffun idea but as someone pointed out we would have to
>>> sacrifice the possibility of sending an expression containing a < in th=
e
>>> "less than" meaning to such a macro. This is of course sad but I see no=
way
>>> that we could parse both meanings of < correctly at the time the
>>> preprocessor runs as this requires knowledge of what identifiers stand =
for
>>> (templates or variables).
>>
>> You'd have to put such an expression in ()'s. If it's really an
>> expression, presumably you could do so.
>>
>> This also assumes that #deffun wouldn't bite the bullet and defer
>> expansion until a later stage in processing, i.e. one where the compiler
>> knows about types and could treat it as something more like an inline
>> function call.
>>
>> As others have noted, however, such a proposal being accepted seems
>> unfortunately unlikely. Code generation (PP and otherwise) is an area I
>> think could very much be improved, but there is a lot of inertia against
>> doing so.
>>
>> Maybe someone feeling sufficiently motivated should just write a new,
>> stand-alone preprocessor that doesn't restrict itself to the existing
>> CPP and publish it. Then try to get it integrated into gcc and/or clang.
>> (Bonus points for making it a BSD library so that the implementation can
>> be shared.) There's nothing in the standard that says one cannot feed
>> generated code into the compiler, after all.
>>
>> --
>> Matthew
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-prop=
osals/.
>
>
>
> --
> Who=E2=80=99s got the sweetest disposition?
> One guess, that=E2=80=99s who?
> Who=E2=80=99d never, ever start an argument?
> Who never shows a bit of temperament?
> Who's never wrong but always right?
> Who'd never dream of starting a fight?
> Who get stuck with all the bad luck?
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.