220 8703 <47db64d6-64fb-4243-bded-e36fc8be30b2@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 13:11:35 -0800 (PST) Lines: 362 Approved: news@gmane.org Message-ID: <47db64d6-64fb-4243-bded-e36fc8be30b2@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_411_15966508.1390165895400" X-Trace: ger.gmane.org 1390165890 1110 80.91.229.3 (19 Jan 2014 21:11:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 21:11:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD5KHQXXWYPRBB776CLAKGQEGZT3LAY@isocpp.org Sun Jan 19 22:11:38 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f197.google.com ([209.85.213.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4zeb-0003Fw-B1 for gclcip-std-proposals@m.gmane.org; Sun, 19 Jan 2014 22:11:37 +0100 Original-Received: by mail-ig0-f197.google.com with SMTP id j1sf11183383iga.0 for ; Sun, 19 Jan 2014 13:11:36 -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=ifL/0WCq9BPkBwWqAaZdaQIL0TyWsO6pCWnNfshAe6c=; b=mMlS5ffF1QsdzEezvyCmog5lMQu2Y2xZ5AgTZ32F+OywWiNFDJA0Bma36Vxcz5l2PQ Oy7wjwva65wHR8Agu/FM15bZfKXCB9m1qj+RSfhhyE9wVot3zZmVd9Ddo5IPfqtsZBjs Zvcix9X8uPxzPAImi+FPInhF7Rozy7hIZhRP+E4zBHJp1oDWU/Lin91/L7z9lStoo7Gg ohA8p2ijQUyJ+kRr1xMSFLGNZWqDFznhEceWjKAcUAJS39rQiOmPiyAoyPDL+r2RRTb2 K69bWe7Y+zhOMcjhkbdRQ353I5eGnw8SPHORuUGMG6LEAhPhtP7GIBFs/c0ZDDxzofPB yK3w== 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=ifL/0WCq9BPkBwWqAaZdaQIL0TyWsO6pCWnNfshAe6c=; b=DvbTL0P/iueyg1U7LCOPr+ZmDkR4RDOIcwQSHRWPyi6gSTd24MAIAoutG0Ng+YAnMm 2r4P9ZyK4/KVaMf2QKSQdgfCzRg4FVJUQPKBgatHAs81rIZ/tGsEH+KWgbXVrtEods94 Nf39iWOs6MwZNzyE6fO2OPfLP9I9W7kpeEXWdeTbu68TAdRijmaxoGvMqyvYXSi9Ls6Z C1lqqR2B9I0BzynSgzcbDwfMRJbhxVWBQQZ/i+38rPJxazb4l3Njmlt2bKX2FE4n9RqF dWf42x1PiblIroaMv64KoXAnwX5mOQWzInyY0JIbp53UhZyxHa2BxJRjRI/nO5pa9mfN tX0A== X-Gm-Message-State: ALoCoQlhL/H+lIIcE5QGlMyDFCo/rhO4zWi0xidjb+EeULqhe6qK431cjqUqhGAh6bBnz+6xvf+u X-Received: by 10.42.98.81 with SMTP id r17mr4470359icn.8.1390165896300; Sun, 19 Jan 2014 13:11:36 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.92.240 with SMTP id b103ls226618qge.57.gmail; Sun, 19 Jan 2014 13:11:35 -0800 (PST) X-Received: by 10.140.42.87 with SMTP id b81mr371qga.41.1390165895765; Sun, 19 Jan 2014 13:11:35 -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:8703 Archived-At: ------=_Part_411_15966508.1390165895400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable #define RAW(x) x GENERATE_FUNC(RAW(std::pair), getPair1), return std::make_pair(1,= =20 1)); The arguments to a macro are identified before macro expansion takes place= =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 the= =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 been= =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 cod= e=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 is= =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 specific= =20 > to this case, and may not always be applicable. Additionally, it requires= =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 there= =20 > 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 t= o=20 > 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 t= o=20 > 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_411_15966508.1390165895400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
#define RAW(x) x

(RAW(std::pair<int, int>), getPair1), return std::make_pair(1, 1));
<= /div>

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

The preprocessor respect= s parenthesis for nesting arguments.

From 16.2:

The sequence of preprocessing tokens bounded by the outsid= e-most matching parentheses forms the list of
arguments for the f= unction-like macro. The individual arguments within the list are separated = by comma
preprocessing tokens, but comma preprocessing tokens = between matching inner parentheses do not separate
argumen= ts.

After the arguments for the invoca= tion of a function-like macro have been identi=EF=AC=81ed, argument substit= ution
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 arg= ument after all macros
contained therein have been expanded. Befo= re being substituted, each argument=E2=80=99s preprocessing tokens are
completely macro replaced as if they formed the rest of the preproces= sing =EF=AC=81le; no other preprocessing tokens
are available.

On Sunday, January 19, 2014 6:28:43 PM UTC+1, Vitto= rio 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 o= r to generate code that would be impossible to generate only using template= s.
An issue with macros is that passing arguments is sometimes really c= ounter-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_411_15966508.1390165895400-- .