220 8689 article Path: news.gmane.org!not-for-mail From: Vittorio Romeo Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: "Raw" preprocessor macro arguments Date: Sun, 19 Jan 2014 09:28:43 -0800 (PST) Lines: 327 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_333_8680371.1390152523746" X-Trace: ger.gmane.org 1390152523 20288 80.91.229.3 (19 Jan 2014 17:28:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 17:28:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCO3NDEYZQHRBTEW6CLAKGQEEHJUAZI@isocpp.org Sun Jan 19 18:28:50 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4wAv-0004bo-Vq for gclcip-std-proposals@m.gmane.org; Sun, 19 Jan 2014 18:28:46 +0100 Original-Received: by mail-ob0-f198.google.com with SMTP id wp4sf6107847obc.1 for ; Sun, 19 Jan 2014 09:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id: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=gXoCW0g4BoTM9vDPveQkKvtxcfLZj/a/l8stn7D9RAE=; b=pTq3xz1hs/s29/tHCmnw2JdUsPc589V7VjPoJ+hrEli7TChK74h2zlcHyP/sFyQ5Sf 5TIqhriMN2nc8IaE6mEzws310/xc0KdsCTPG9hs0uHtpEvDHUerjUEwoZ+f1SsMMOUZl xsecIwNlHwoMrkDhDb0YiWtVK6RgGWLWpLiM72T/hnV0ZheOGarhi3MelI1VUN7v7nB7 IUA+uSzYG3Z3KJej4ePBIY5pLVFJyE2/rEt/Za1YHJEbe+5r6RF2kskzBrImAU2v1Re+ QrgsiSPPpaWIZuZhdZR1USZNYZzz4EOsDm3SKrQJBZXBsxdZoezU/ZF7dL65a8Uw8+gl dAvA== 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: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=gXoCW0g4BoTM9vDPveQkKvtxcfLZj/a/l8stn7D9RAE=; b=mLXeFPfMB8o3sWQUldA1gCbCvHk3n5pGkC70W0pL5G9lsvK3CCF55Z/YVNe3D4yarP lYugymVQmWLEO804ecwKPJRppFmL+gWyef1SCfRnHK7XchdIQ+d86rPBOlwHyjtl2vKP dLOK+IA5WZmk3egZfQS7jZhxvibUoX3gyU1UDfDjiBAjLFyz0G7axVAEYUxfpwap86fX xlhSwxycJSnCeapsUDrt4ax7h1tGjiPhLTVME9E8Vg90ZloS0hpjlQu39PqKPLgjNEyJ 0QIlh1mqLX75jfW06aMOD4g85Qivz6tBqTl5Ga8N/jujX5RpkohTg2eeoaJYbWUjBsQW pxng== X-Gm-Message-State: ALoCoQmIhgfymMgT4rDFfg1q/xciuLEh3y/vTR99wmYKVxZINdBEgVRQxqmx8R11gkMYTNYaUBNk X-Received: by 10.43.4.4 with SMTP id oa4mr4346906icb.2.1390152525020; Sun, 19 Jan 2014 09:28:45 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.39.102 with SMTP id o6ls1628032qek.28.gmail; Sun, 19 Jan 2014 09:28:44 -0800 (PST) X-Received: by 10.140.43.74 with SMTP id d68mr183928qga.8.1390152524329; Sun, 19 Jan 2014 09:28:44 -0800 (PST) X-Original-Sender: vittorio.romeo.vee@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:8689 Archived-At: ------=_Part_333_8680371.1390152523746 Content-Type: text/plain; charset=UTF-8 *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 counter-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 valid code GENERATE_FUNC(void, printNumber, printf("%d", 5);) // The comma in "" is read as an additional argument - macro expansion fails GENERATE_FUNC(std::pair, getPair1, return std::make_pair(1, 1);) // The comma in "" is read correctly, but the generated code is invalid, as // the round parenthesis persist in the return type (look below for the 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 to this case, and may not always be applicable. Additionally, it requires the coder to define a new typedef, 2. Create multiple macros (for example, GENERATE_FUNC_START and GENERATE_FUNC_END), and 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 macro definitions. These solutions, however, can be defined *hacks. *The issue is that there is no way to pass a "raw" argument to the preprocessor. 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::pair), __R(getPairRaw), __R(return std:: make_pair(1, 1)) Specification: < __R > <(> <...> <)> Prefix/suffix example: GENERATE_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 "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_333_8680371.1390152523746 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 stati= c reflection or to generate code that would be impossible to generate only = using templates.
An issue with macros is that passing arguments is some= times really counter-intuitive and dangerous. 

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


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


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


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


// The comma in "<int, int>" is read= correctly, but the generated code is invalid, as
// the round parenthesis persist in the r= eturn type (look below for the expansion)
GENERATE_FUNC((std::pair<int, int>), getPair2, return std::make_pair(1, 1);)
/*
    (std::pair<int, int>) get= Pair2() { 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 specifi= c to this case, and may not always be applicable. Additionally, it requires= the coder to define a new typedef,
2. Create multiple macros (for exam= ple, GENERATE_FUNC_START and GENERATE_FUNC_END), and let the user write the= code in-between - this solution is ugly and error prone. Also, it scales p= oorly, as k "body" arguments would require k+1 macro definitions.

These solutions, however, can be defined hacks. The = issue is that there is no way to pass a "raw" argument to the preprocessor.=  

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

Example:<= /div>
GENERATE_FUNC<= /span>(__R(std::pair<int, int>), __R(getPairRaw), __R(return std::mak= e_pair(1, 1))

Specification:
< __R > <= /span><prefix&= gt; <(&= gt; <...> <)> <suffix>

Prefix/suffix exa= mple:
GENERATE_FUNC(__R***(ReturnType(int*))***, __R= (getIntPtr= ),<= span style=3D"color: #000;" class=3D"styled-by-prettify"> __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);
     ...
))

T= his "raw syntax" would also fix the "comma problem", that forced users to d= efine 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_333_8680371.1390152523746-- .