220 8720 article Path: news.gmane.org!not-for-mail From: jgottman6@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: "Raw" preprocessor macro arguments Date: Sun, 19 Jan 2014 17:06:18 -0800 (PST) Lines: 420 Approved: news@gmane.org Message-ID: References: <47db64d6-64fb-4243-bded-e36fc8be30b2@isocpp.org> <0948fc8a-2191-4ab0-97df-cf354a470828@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_550_15354894.1390179978103" X-Trace: ger.gmane.org 1390179974 8560 80.91.229.3 (20 Jan 2014 01:06:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jan 2014 01:06:14 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD7LHGWIQEPRBCXN6GLAKGQELERNV6I@isocpp.org Mon Jan 20 02:06:21 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f72.google.com ([209.85.220.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W53Jk-0005nX-I7 for gclcip-std-proposals@m.gmane.org; Mon, 20 Jan 2014 02:06:21 +0100 Original-Received: by mail-pa0-f72.google.com with SMTP id rd3sf16237883pab.7 for ; Sun, 19 Jan 2014 17:06:19 -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=tmBdVmdrVe5CTBREq5/SSf0laGBvz8QA3C2xsrTUP/o=; b=GETeMomadzcVqutVTf6I1KcaFvNv3qoak6aCqnEHyVrfVOuo/XCQ8mjobg/fgzHYwp oIze10yfhy+oCtZW+cB14eS/pixnkToOOqnJvNA1/p5IirwGY8cUWN51SFnhKuVFs+Ip FvcJHybH6eDPZTEhUIoCBizesjqWbk8xCYqy4bNOtnozBxtwRgMBFdjD/CLARoQjUdMI ReLZBR/GJkjFgecDe122BfdlmqGKuFWteau7dNgzEdQfRg597ryVqfgJT0q+1JtQhnQX D/TrM5E4+iOH8AabUkcHRrIO/jsI9sYQRKmMTsoS6s6Mj0spmnaq7D2AIr8K6BMhyejD lfJw== 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=tmBdVmdrVe5CTBREq5/SSf0laGBvz8QA3C2xsrTUP/o=; b=eVYYm5biwFUFyhf1kYg7Pjt6HpgXvC55bSwxjjg94fCpOHILKVkX98KV9JeQ9A35GC vY5U5yjHNE6WwsGIU0BY6v3EAClsssBheInlEF3xnbSvxCcAqtsUSQ5g61lJgQSkoyjH 9+ftAlEB+aG58kGbxdQ0B+E/FzuN8SI6R/Ct3TRoV5JkveNHsshi/I13tP9BfPPqtl9j KXEm0+E1gXJwlwMpcwFvj/JG99IEuIagAJrCWZ7Y1l5dg+hm7XCgzy4xF8DFUD9LM3// GOEiT/eXZE+PP1C+wGfq7d31evnGnI23xOMBpi6CT9o9ykoi8vdFf8JwQGiD4XRq/JRH JU0g== X-Gm-Message-State: ALoCoQkypElHb9jr9mU6EBB6iK7xs290/fskxCU0m7qt0EtDn8IPWO4MyCpYph5npZDdmMRVhckO X-Received: by 10.66.66.35 with SMTP id c3mr5557092pat.12.1390179979155; Sun, 19 Jan 2014 17:06:19 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.127.110 with SMTP id nf14ls286718qeb.44.gmail; Sun, 19 Jan 2014 17:06:18 -0800 (PST) X-Received: by 10.140.38.9 with SMTP id s9mr390qgs.33.1390179978515; Sun, 19 Jan 2014 17:06:18 -0800 (PST) In-Reply-To: <0948fc8a-2191-4ab0-97df-cf354a470828@isocpp.org> X-Original-Sender: jgottman6@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:8720 Archived-At: ------=_Part_550_15354894.1390179978103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think this is still slightly wrong. Won't it eat the comma, so that=20 RAW(std::pair) becomes std::pair //no comma! Joe Gottman On Sunday, January 19, 2014 5:15:46 PM UTC-5, Andrew Tomazos wrote: > > 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=20 >> place on the arguments. So the above will nest out the comma like you w= ant. >> >> The preprocessor respects parenthesis for nesting arguments. >> >> From 16.2: >> >> The sequence of preprocessing tokens bounded by the outside-most matchin= g=20 >> parentheses forms the list of >> arguments for the function-like macro. The individual arguments within= =20 >> the 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=20 >> been 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 preprocessin= g=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= =20 >>> in a lot of C/C++ programs. Using macros is the sometimes only way to a= void=20 >>> verbose code repetition, to simulate static reflection or to generate c= ode=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= =20 >>> is 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,= =20 >>> 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=20 >>> specific to this case, and may not always be applicable. Additionally, = it=20 >>> requires 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_550_15354894.1390179978103 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this is still slightly wrong.  Won't it eat t= he comma, so that
RAW(= std= ::pair<int, int>)
becomes
std::pair<int <= /span>int<= span style=3D"color: #660;" class=3D"styled-by-prettify">> //no comma!
Joe Gottman

On Sunday, January 19, 2014 5:15:46 PM UTC-5, Andrew T= omazos wrote:
= Actually sorry, I am slightly wrong about that solution.  The argument= to RAW will be parsed in turn as two arguments and not one.  It shoul= d be:

    #define RAW(...) __VA_ARGS__

= This will work I think.

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

G= ENERATE_FUNC(RAW(std::pair<int,=  int>), getPair1),&nbs= p;return std::make_pair(<= /span>1,&nb= sp;1));<= br>

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 res= pects parenthesis for nesting arguments.

From 16.2= :

The sequence of preprocessing tokens bounded by the ou= tside-most matching parentheses forms the list of
arguments for t= he function-like macro. The individual arguments within the list are separa= ted by comma
preprocessing tokens, but comma preprocessing tok= ens between matching inner parentheses do not separate
arg= uments.

After the arguments for the in= vocation of a function-like macro have been identi=EF=AC=81ed, argument sub= stitution
takes place. A parameter in the replacement = list, unless preceded by a # or ## preprocessing token or
followe= d by a ## preprocessing token (see below), is replaced by the corresponding= argument after all macros
contained therein have been expanded. = Before being substituted, each argument=E2=80=99s preprocessing tokens are<= /div>
completely macro replaced as if they formed the rest of the prepr= ocessing =EF=AC=81le; no other preprocessing tokens
are available= ..

On Sunday, January 19, 2014 6:28:43 PM UTC+1, V= ittorio Romeo wrote:
Preprocessor macros, even if potentially unsafe, = still have place in a lot of C/C++ programs. Using macros is the sometimes = only way to avoid verbose code repetition, to simulate static reflection or= to generate code that would be impossible to generate only using templates= ..
An issue with macros is that passing arguments is sometimes really co= unter-intuitive and dangerous. 

Example:
#define GENERATE_FUNC(mType, mName, mBody) mType mName(){ mBody }


// Ok, generates valid code
= GENERATE_FUNC(void, printHi, printf("hi");)


// Ok, generates vali= d code
GENERATE_FUNC(void, printNumber, printf("%d", 5);)


// The comma in = "<int, int>" is read as an additional argument - macro expansion fail= s
GENERATE_FUNC(std::pair<int, int>, getPair1, return std::make_pair(1, 1);= )


// The comma in "<int, int>" is read correctly, but the generat= ed code is invalid, as
// the round parenthesis persist in the return type (lo= ok below for the expansion)
GENERATE_F= UNC((st= d::pair= <int= , int>), getPair2,= return= std::<= /span>make_pair(1, 1<= span style=3D"color:#660">);)
<= span style=3D"color:#800">/*
    (std::pair<int, int>) g= etPair2() { return std::make_pair(1, 1); }
*/
<= div>
There are possible solutions to this issue:
1= .. Create a typedef for `std::pair<int, int>` - this solution is speci= fic to this case, and may not always be applicable. Additionally, it requir= es the coder to define a new typedef,
2. Create multiple macros (for ex= ample, GENERATE_FUNC_START and GENERATE_FUNC_END), and let the user write t= he code in-between - this solution is ugly and error prone. Also, it scales= poorly, as k "body" arguments would require k+1 macro definitions.

These solutions, however, can be defined hacks. Th= e issue is that there is no way to pass a "raw" argument to the preprocesso= r. 

Here's what I propose:
Simil= arly to C++11 raw strings, have a new syntax that allows the user to pass "= raw arguments" to preprocessor macros.

Example= :
GENERATE_FUNC= (__R(std::pair<int,<= /span> int>), __R<= /span>(getPair= Raw), _= _R(retu= rn std:= :make_pair(1,<= /span> 1))
=

Specification:
<= __R > <prefix> <(> <...> <)> <suffix>

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

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

Unit test after example:<= /div>
<= span style=3D"color:#000">UNIT_TEST(__R(<= span style=3D"color:#000">
     EXPECT(some predicate);
  &nbs= p;  ...
))

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

Wh= at 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_550_15354894.1390179978103-- .