220 8710 <0948fc8a-2191-4ab0-97df-cf354a470828@isocpp.org> article Path: news.gmane.org!not-for-mail From: Andrew Tomazos Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: "Raw" preprocessor macro arguments Date: Sun, 19 Jan 2014 14:15:46 -0800 (PST) Lines: 379 Approved: news@gmane.org Message-ID: <0948fc8a-2191-4ab0-97df-cf354a470828@isocpp.org> References: <47db64d6-64fb-4243-bded-e36fc8be30b2@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_552_24779971.1390169746827" X-Trace: ger.gmane.org 1390169743 8317 80.91.229.3 (19 Jan 2014 22:15:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 22:15:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD5KHQXXWYPRBE456GLAKGQE322FGBA@isocpp.org Sun Jan 19 23:15:51 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W50ej-0005QM-4W for gclcip-std-proposals@m.gmane.org; Sun, 19 Jan 2014 23:15:49 +0100 Original-Received: by mail-pa0-f70.google.com with SMTP id kq14sf15987760pab.9 for ; Sun, 19 Jan 2014 14:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=MZi1hq2Ih9Hru/iJeYO/9cuSwpxKZd+Npdd1XtE8iH4=; b=cCKGukbbSPOA/q21Gr4IgBXyTqOJSdxf1culewjqWiFyKmqo5Duf1EsBDqfswRU8Cc im+IQbIh+MgeR/5LI/uVgklc9Lei84cVpB21xXJJcRVvvLlzGr7DYbwbPIKI/yLgAK83 pckYVQmzm5pLXDZhN6cDV1NAooz7HksLjKLkaHEIBvX/YqxJBDGgaSMflcsp5wgHfw3f j2hLLBdMsStqzZIqm5Y45WHFYmYhY31X0LhZ1HeGLSaiVvGnM1PXRAd0hq58yeGC1khZ ui2gXT677sNBtV2J2KgsP5i4QGruq8wwMPraMDW1wWZ06k6U4j0l6n0HRi8GMxPSGw3E N6Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=MZi1hq2Ih9Hru/iJeYO/9cuSwpxKZd+Npdd1XtE8iH4=; b=gbNMrfSDykch6ui451MU6FPuU0vtNuP7lJVaivNr4iETB45FHufIQ+FzSQMC1UQbbo u2IPW7NtWnSfVnIwHctQDei58Msn12zOgpezcwg+qE+asfTmMUOJUsgiKzkNepM1MaqD VyCvCk3C3ZJO/F3FLQLsyVczhj3FTmko+pCv5VPh9uTNlTlwFFH3Kkw8sjqzu7a2vR2t dLu2B2TmAJ0rF774eAO1iVpkRmXHoRT8eB9MwaZaln29N+APzpzv3WE3sNMQ1Thex8YO H6xwXWP+16FCdnnpFy+9eOjF7mH8GQ3MUH2cEavXV8f9HL90S3ag9PPPRWufx9nqeNDN vP8g== X-Gm-Message-State: ALoCoQkDNiLCXR+x1F0ehzG3bLY/14r+A5vaxw1uAeTZXKfkG4VDX+WsOLH97chXjjVgkrZZBlCs X-Received: by 10.68.133.164 with SMTP id pd4mr5451478pbb.1.1390169747978; Sun, 19 Jan 2014 14:15:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.96.52 with SMTP id j49ls874434qge.7.gmail; Sun, 19 Jan 2014 14:15:47 -0800 (PST) X-Received: by 10.140.48.8 with SMTP id n8mr655qga.36.1390169747357; Sun, 19 Jan 2014 14:15:47 -0800 (PST) In-Reply-To: <47db64d6-64fb-4243-bded-e36fc8be30b2@isocpp.org> X-Original-Sender: andrewtomazos@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8710 Archived-At: ------=_Part_552_24779971.1390169746827 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually sorry, I am slightly wrong about that solution. The argument to= =20 RAW will be parsed in turn as two arguments and not one. It should be: #define RAW(...) __VA_ARGS__ This will work I think. On Sunday, January 19, 2014 10:11:35 PM UTC+1, Andrew Tomazos wrote: > > #define RAW(x) x > > GENERATE_FUNC(RAW(std::pair), getPair1), return std::make_pair(= 1 > , 1)); > > The arguments to a macro are identified before macro expansion takes plac= e=20 > on the arguments. So the above will nest out the comma like you want. > > The preprocessor respects parenthesis for nesting arguments. > > From 16.2: > > The sequence of preprocessing tokens bounded by the outside-most matching= =20 > parentheses forms the list of > arguments for the function-like macro. The individual arguments within th= e=20 > list are separated by comma > preprocessing tokens, *but comma preprocessing tokens between matching=20 > inner parentheses do not separate* > *arguments*. > > *After the arguments for the invocation of a function-like macro have bee= n=20 > identi=EF=AC=81ed, argument substitution* > *takes place.* A parameter in the replacement list, unless preceded by a= =20 > # or ## preprocessing token or > followed by a ## preprocessing token (see below), is replaced by the=20 > corresponding argument after all macros > contained therein have been expanded. Before being substituted, each=20 > argument=E2=80=99s preprocessing tokens are > completely macro replaced as if they formed the rest of the preprocessing= =20 > =EF=AC=81le; no other preprocessing tokens > are available. > > On Sunday, January 19, 2014 6:28:43 PM UTC+1, Vittorio Romeo wrote: >> >> *Preprocessor macros*, even if potentially *unsafe*, still have place in= =20 >> a lot of C/C++ programs. Using macros is the sometimes only way to avoid= =20 >> verbose code repetition, to simulate static reflection or to generate co= de=20 >> that would be impossible to generate only using templates. >> An issue with macros is that passing arguments is sometimes really=20 >> counter-intuitive and dangerous.=20 >> >> Example: >> #define GENERATE_FUNC(mType, mName, mBody) mType mName(){ mBody } >> >> >> // Ok, generates valid code >> GENERATE_FUNC(void, printHi, printf("hi");) >> >> >> // Ok, generates valid code >> GENERATE_FUNC(void, printNumber, printf("%d", 5);) >> >> >> // The comma in "" is read as an additional argument - macro= =20 >> expansion fails >> GENERATE_FUNC(std::pair, getPair1, return std::make_pair(1, 1 >> );) >> >> >> // The comma in "" is read correctly, but the generated code i= s=20 >> invalid, as=20 >> // the round parenthesis persist in the return type (look below for the= =20 >> expansion) >> GENERATE_FUNC((std::pair), getPair2, return std::make_pair(1, = 1 >> );) >> /* >> (std::pair) getPair2() { return std::make_pair(1, 1); } >> */ >> >> There are possible solutions to this issue: >> 1. Create a typedef for `std::pair` - this solution is specifi= c=20 >> to this case, and may not always be applicable. Additionally, it require= s=20 >> the coder to define a new typedef, >> 2. Create multiple macros (for example, GENERATE_FUNC_START and=20 >> GENERATE_FUNC_END), and let the user write the code in-between - this=20 >> solution is ugly and error prone. Also, it scales poorly, as k "body"=20 >> arguments would require k+1 macro definitions. >> >> These solutions, however, can be defined *hacks. *The issue is that=20 >> there is no way to pass a "raw" argument to the preprocessor.=20 >> >> Here's what I propose: >> *Similarly to C++11 raw strings, have a new syntax that allows the user= =20 >> to pass "raw arguments" to preprocessor macros.* >> >> Example: >> GENERATE_FUNC(__R(std::pair), __R(getPairRaw), __R(return std:= : >> make_pair(1, 1)) >> >> Specification: >> < __R > <(> <...> <)> =20 >> >> Prefix/suffix example: >> GENERATE_FUNC(__R***(ReturnType(int*))***, __R(getIntPtr), __R(return & >> someInt;)) >> >> Unit test before example: >> UNIT_TEST_START() >> EXPECT(some predicate); >> ...=20 >> UNIT_TEST_END() >> >> Unit test after example: >> UNIT_TEST(__R( >> EXPECT(some predicate); >> ...=20 >> )) >> >> This "raw syntax" would also fix the "comma problem", that forced users= =20 >> to define a "COMMA" macro for years: >> __R(,) >> >> *What do you think?* >> > --=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_552_24779971.1390169746827 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Actually sorry, I am slightly wrong about that solution. &= nbsp;The argument to RAW will be parsed in turn as two arguments and not on= e.  It should be:

    #define RAW(...) __= VA_ARGS__

This will work I think.

On Sunday= , January 19, 2014 10:11:35 PM UTC+1, Andrew Tomazos wrote:
#define RAW(x) x

GENERATE_FUNC(RAW(std::pair<int= , int>), getPair1), return&= nbsp;std::make_pair(1, 1));

The arguments to a macro= are identified before macro expansion takes place on the arguments.  = So the above will nest out the comma like you want.

The preprocessor respects parenthesis for nesting arguments.
From 16.2:

The sequence of preprocessing to= kens bounded by the outside-most matching parentheses forms the list of
arguments for the function-like macro. The individual arguments with= in the list are separated by comma
preprocessing tokens, but c= omma preprocessing tokens between matching inner parentheses do not separat= e
arguments.

After th= e arguments for the invocation of a function-like macro have been identi=EF= =AC=81ed, argument substitution
takes place. A paramet= er in the replacement list, unless preceded by a # or ## preprocessing toke= n or
followed by a ## preprocessing token (see below), is replace= d by the corresponding argument after all macros
contained therei= n have been expanded. Before being substituted, each argument=E2=80=99s pre= processing tokens are
completely macro replaced as if they formed= the rest of the preprocessing =EF=AC=81le; no other preprocessing tokens
are available.

On Sunday, January 19, 20= 14 6:28:43 PM UTC+1, Vittorio Romeo wrote:
Preprocessor macros, even if potentiall= y unsafe, still have place in a lot of C/C++ programs. Using ma= cros is the sometimes only way to avoid verbose code repetition, to simulat= e static reflection or to generate code that would be impossible to generat= e only using templates.
An issue with macros is that passing arguments = is sometimes really counter-intuitive and dangerous. 

Example:<= /div>
#define GENERATE_FUNC(mType, mName, mBody) mType mName(){ mBody }


// Ok, generates valid code
GENERATE_FUNC(void,<= span style=3D"color:#000"> printHi, printf("hi");)


= // Ok, generates valid code
GENERATE_F= UNC(voi= d, prin= tNumber, printf("%d",= 5);)


// The comma in "<int, int>" is read as an additional argument - m= acro expansion fails
GENERATE_FUNC(std= ::pair<= span style=3D"color:#660"><int<= span style=3D"color:#660">, int>, getPair1, return std::make_pair(= 1, 1);)


// The comma in "<int, int>" is read correct= ly, but the generated code is invalid, as
// the round parenthesis persist in = the return type (look below for the expansion)
GENERATE_FUNC((std::pair<int, int>), getPair2, return std::make_pair(1, 1);)
/*
    (std::p= air<int, int>) getPair2() { return std::make_pair(1, 1); }
*/

There are possible solutions= to this issue:
1. Create a typedef for `std::pair<int, int>` - = this solution is specific to this case, and may not always be applicable. A= dditionally, it requires the coder to define a new typedef,
2. Create m= ultiple macros (for example, GENERATE_FUNC_START and GENERATE_FUNC_END), an= d let the user write the code in-between - this solution is ugly and error = prone. Also, it scales poorly, as k "body" arguments would require k+1 macr= o definitions.

These solutions, however, can be de= fined hacks. The issue is that there is no way to pass a "raw" argum= ent to the preprocessor. 

Here's what I propo= se:
Similarly to C++11 raw strings, have a new syntax that all= ows the user to pass "raw arguments" to preprocessor macros.
=
Example:
<= font color=3D"#000000">GENERATE_FUNC(__R(std::pair<int, int>), __R(getPairRaw), __R(return std::make_pair<= span style=3D"color:#660">(1, 1))

Specification:
< __R > <pref= ix> <(> <...> <)> <suffix>

Prefix/suffix example:
GENERAT= E_FUNC(= __R***(= ReturnType(int*))***, __R(getIntPtr), __R(return &someInt;))

Unit test before= example:
UNIT_TEST_START()
     EXPECT(some predicate);
     ...
UNIT_TEST_END()

= Unit test after example:
= UNIT_TEST(__R(
     = EXPECT(= some predicate);
     ...
))

This "raw syntax" would also fix the "comma= problem", that forced users to define a "COMMA" macro for years:
__R(,)

What do you think?
=

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;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-proposals/<= /a>.
------=_Part_552_24779971.1390169746827-- .