From 8346882161550766325 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc772,a175c482da34ebf8 X-Google-Attributes: gidfc772,public X-Google-Thread: f78e5,765aa557d15ef5ba X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-05-09 08:50:39 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!uwm.edu!rpi!not-for-mail From: Mike Conley Newsgroups: comp.lang.c++.moderated,comp.std.c++ Subject: Re: Preprocessor evolution Date: 9 May 2003 11:52:44 -0400 Organization: Road Runner High Speed Online -- Columbus Lines: 87 Sender: cppmods@netlab.cs.rpi.edu Approved: hsutter@gotw.ca Message-ID: References: <652361f.0304032218.6b7a67e4@posting.google.com> <3e8f6897.709822312@News.CIS.DFN.DE> <3e920e1f.883270640@News.CIS.DFN.DE> NNTP-Posting-Host: netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.std.c++ X-Approved-For-Group: Fergus Henderson comp.std.c++ X-Original-Date: 09 May 03 04:52:45 GMT X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAPrvOyUHMCo9UcraBAQGmUAH9ECBVFSKr/mH62I2PEI4aj/wQ8E0BVLHH 8uS/I5cOM3x7Ut8pLz5TKp4minzBL02Mb3sUdttOXwvlzLXfIFelbg== =quXn Xref: archiver1.google.com comp.lang.c++.moderated:65700 comp.std.c++:19304 Paul Mensonides wrote in news:WuAta.745871$L1.211469@sccrnsc02: > I can count up to 2^512 arguments with my current "strict" > implementation of the Boost pp-lib. Granted, it isn't the limit that > matters. Rather, it that you have to count them at all. :) I thought the limit was much smaller. Guess I'll have to take a closer look at it. But, as you say, it's the need to count, not the limit, that's bothersome. > > Native > > overloaded macros would also provide a workaround for the token > > pasting problem you've mentioned: > No the wouldn't. The token pasting problem that I mentioned only > exists because there is no difference between ( placemarker ) and ( > argument ). Therefore, this would be ambiguous: > > #define MACRO() > #define MACRO(a) > > MACRO() // argument == placemarker? > // or, no argument at all? Ahh... I hadn't thought of that (obviously :) This should probably be a call to the nullary MACRO. Users can explicitly request the unary MACRO with an empty argument easily enough: #define nothing MACRO(nothing) > Furthermore, the problems compound if you separate the "recursive" > style macros from the overloading idea. Specifically, if an > identifier token that is found during the rescan of a macro's > replacement list that refers to a macro that is currently "disabled," > the identifier token itself is permanently disabled--this is even > without an attempted invocation, such as: > > #define MACRO(x) x > > MACRO( MACRO )( 1 ) // MACRO( 1 ) Right. If you want this to expand to 1, you'd need to use a recursive macro. Recursive macros would never be disabled. > No invocation is needed in order to disable specific identifiers. So, > either the entire overload set must be disabled, or the overloading > can only work when macros are recursive. Probably the thing to do is disable only the nonrecursive overloads. For example: #defrec A(arg1) arg1 #define A(arg1, arg2) arg1(arg2) A(1) // 1 A(A,A)(1) // A(A)(1) -> A(1) -> 1 (because unary A is recursive) A(A,A)(1,1) // A(A)(1,1) -> A(1,1) (stops here -- binary A is disabled) More specifically, let's suppose we're talking about a macro M. M_N represents a definition of M taking N arguments (let's not worry about variadics -- similar rules would apply to them). Within the body of M_N, M_N is disabled iff M_N is not recursive. M_K is available (whether M_N is recursive or not) for all K != N. If the name M is used in a context where an ordinary macro would be disabled without an invocation, then, for all N, M_N is disabled iff M_N is not recursive. > I like the overloading on number of arguments idea. I don't like the > variadic splitter because that is completely unnecessary: The point was that, with recursive macros and overloading, you could define a fully general list splitter (and other useful list manipulation macros, too :). -- Mike Conley --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]