220 8724 <17ff52ed-e7fd-49d0-931a-524945cf5212@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 18:49:25 -0800 (PST) Lines: 419 Approved: news@gmane.org Message-ID: <17ff52ed-e7fd-49d0-931a-524945cf5212@isocpp.org> 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_1863_8535418.1390186165826" X-Trace: ger.gmane.org 1390186162 493 80.91.229.3 (20 Jan 2014 02:49:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jan 2014 02:49:22 +0000 (UTC) Cc: jgottman6@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD5KHQXXWYPRBNU56KLAKGQE5CN5N4I@isocpp.org Mon Jan 20 03:49:28 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f72.google.com ([209.85.216.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W54vX-0005pZ-VW for gclcip-std-proposals@m.gmane.org; Mon, 20 Jan 2014 03:49:28 +0100 Original-Received: by mail-qa0-f72.google.com with SMTP id f11sf10453609qae.3 for ; Sun, 19 Jan 2014 18:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=ZaGi343gfuNxUZUwnNKTF5yPCqAuhoGxbJPoEDfyOm4=; b=M/Vb7PXhm8UQ69C83lE+br2FqjEttT0KadFvwTIWekt3aO2pWzbm23RsfCS6yI2H67 ZsMC/V90E8x9Y34gEPBVs3n8TXs0pk0rSBhfVpgfESrwpYMrEyi3sxnV082zLvbscNSn xYp6Nbvh3p4P4B+GMkdmO2DHJN1XX05yh1LpHKxsfnppdzi+9xYY6byTJJvlMY5rdhBR AG48JcBPWc2CGLEdLwAbwvj0f//9V6jINujfv+OsETxIk9/JXLCjQIv/by5bsLmG21nS BRwmzfG7JXKNMky7qkgdQELRjkHe1P+MeoV7K2+1BDGkec9pahtPihrN9ZL6cI0aIw/a khtg== 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:cc: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=ZaGi343gfuNxUZUwnNKTF5yPCqAuhoGxbJPoEDfyOm4=; b=YncHkAwmzdy6/3LGMbwkMWjpFYfMLa5PToAwqpC76fmq4u2Dhr48YzyMMpMoehwyV9 AZIeJoHSUyBFh5837gGa24JwYpsZeIXu37A2KyKFOnLktVgSEfwxKfwQT9G6IJmpKe0+ JoQIzB18LqOzibGOeiw7rHgx9jxlf3iuC6CUZMPq6dIGEyKMmOBW7RKno1rCLVBa5T/t z1uMPauZ6b8kquehP5H8CkBl5nW3413AdcrFcSfaqgeUdVZd2cC15by/EFjltIm54ANK JzvVGGyrzuAZFEvQQn4YLk0tvPA0qkT3BzBKDZAm2vkc8nhdTG69QvCzjgAWQYRnwOl+ zUEA== X-Gm-Message-State: ALoCoQncPLtbrHdZJ/nLs7/IO8fS3VQqBr65x2G36e4R+mfWN8+JzVjXa9dxa4P704B2Q2b5u+Pj X-Received: by 10.58.46.204 with SMTP id x12mr5838303vem.19.1390186166931; Sun, 19 Jan 2014 18:49:26 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.94.51 with SMTP id cz19ls476947qeb.57.gmail; Sun, 19 Jan 2014 18:49:26 -0800 (PST) X-Received: by 10.140.26.243 with SMTP id 106mr143qgv.31.1390186166227; Sun, 19 Jan 2014 18:49:26 -0800 (PST) In-Reply-To: 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:8724 Archived-At: ------=_Part_1863_8535418.1390186165826 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No it won't, __VA_ARGS__ leaves the commas in. -Andrew. On Monday, January 20, 2014 2:06:18 AM UTC+1, jgot...@gmail.com wrote: > > 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 t= o=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_pai= r >>> (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 = want. >>> >>> The preprocessor respects parenthesis for nesting arguments. >>> >>> From 16.2: >>> >>> The sequence of preprocessing tokens bounded by the outside-most=20 >>> matching 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= =20 >>> a # 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=20 >>> preprocessing =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 = avoid=20 >>>> verbose code repetition, to simulate static reflection or to generate = code=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 th= e=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 use= r=20 >>>> to pass "raw arguments" to preprocessor macros.* >>>> >>>> Example: >>>> GENERATE_FUNC(__R(std::pair), __R(getPairRaw), __R(return st= d >>>> ::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 user= s=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_1863_8535418.1390186165826 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No it won't, __VA_ARGS__ leaves the commas in.
  -= Andrew.

On Monday, January 20, 2014 2:06:18 AM UTC+1, jgot...@gmail.= com wrote:
I t= hink this is still slightly wrong.  Won't it eat the comma, so that
RAW(std::pair<int, int>)
becomes
std::pair<int int= > //= no comma!
Joe Gottman

On Sunday, January 19, 2014 5:15:46 PM UTC-5, Andrew T= omazos wrote:
Actua= lly sorry, I am slightly wrong about that solution.  The argument to R= AW 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

GENERA= TE_FUNC(RAW(std::pair<<= span style=3D"font-family:monospace;background-color:rgb(250,250,250);color= :rgb(0,0,136)">int, = ;int>), getPair1), return std::make_pair(1, 1));

The arguments to a macro are identified before macr= o 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 tokens bounded by the outside= -most matching parentheses forms the list of
arguments for the fu= nction-like macro. The individual arguments within the list are separated b= y comma
preprocessing tokens, but comma preprocessing tokens b= etween matching inner parentheses do not separate
argument= s.

After the arguments for the invocat= ion of a function-like macro have been identi=EF=AC=81ed, argument substitu= tion
takes place. A parameter in the replacement list,= unless preceded by a # or ## preprocessing token or
followed by = a ## preprocessing token (see below), is replaced by the corresponding argu= ment after all macros
contained therein have been expanded. Befor= e being substituted, each argument=E2=80=99s preprocessing tokens are
=
completely macro replaced as if they formed the rest of the preprocess= ing =EF=AC=81le; no other preprocessing tokens
are available.

On Sunday, January 19, 2014 6:28:43 PM UTC+1, Vittor= io 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 g= enerate code that would be impossible to generate only using templates.An issue with macros is that passing arguments is sometimes really counter= -intuitive and dangerous. 

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


// Ok, generates valid code
GENERAT= E_FUNC(= void, p= rintHi,= printf("hi");)


// Ok, generates valid code<= /span>
GENERATE_FUNC(void, printNumber, printf("%d", 5);)


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


// The comma in "<int, int>" is read correctly, but the generated co= de is invalid, as
// the round parenthesis persist in the return type (look b= elow for the expansion)
GENERATE_FUNC<= /span>((std::pair<int, int>),= getPair2, return std::make_pair(1,= 1);)
/*
    (std::pair<int, int>) getPa= ir2() { return std::make_pair(1, 1); }
*/
=
There are possible solutions to this issue:
1. Cr= eate a typedef for `std::pair<int, int>` - this solution is specific = to this case, and may not always be applicable. Additionally, it requires t= he coder to define a new typedef,
2. Create multiple macros (for exampl= e, GENERATE_FUNC_START and GENERATE_FUNC_END), and let the user write the c= ode in-between - this solution is ugly and error prone. Also, it scales poo= rly, as k "body" arguments would require k+1 macro definitions.
<= br>
These solutions, however, can be defined hacks. The is= sue is that there is no way to pass a "raw" argument to the preprocessor.&n= bsp;

Here's what I propose:
Similarly= 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::<= span style=3D"color:#000">pair<= int, int<= span style=3D"color:#660">>), __R(getPairRaw<= /span>), __R(return std::make_pair(= 1, 1))

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

Prefix/suffix example:
GENERATE_FUNC(__R***(ReturnType(int*))***, __R(getIntPtr<= span style=3D"color:#660">), __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);
    &n= bsp;...=
))
<= br>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_1863_8535418.1390186165826-- .