aed@netcom.COM (Andrew Davidson) (03/09/91)
Hi I am having trouble with my preprcessor. I am trying to write a
macro that just concates its argument. ie
#define name2(a,b) ????????
the call name2(Andy,Davidson) should produce AndyDavidson.
I belive that ansi preprocessors are supposed to support this as
follows
#define name2(a,b) a##b
unfortuanly I am using a k&r compiler (I am working on a sun work
station and can not change compilers)
Anyone familar with C++ will noticed that the name2 macro is defined
in generic.h
thanks in advance
--
-----------------------------------------------------------------
"bede-bede-bede Thats all Folks"
Porky Pig
Andy Davidson
Woodside CA.
aed@netcom.COM
-----------------------------------------------------------------rjohnson@shell.com (Roy Johnson) (03/15/91)
In article <27489@netcom.COM> aed@netcom.COM (Andrew Davidson) writes:
I belive that ansi preprocessors are supposed to support this as
follows
#define name2(a,b) a##b
unfortuanly I am using a k&r compiler (I am working on a sun work
station and can not change compilers)
Instead of ##, use an empty comment: /**/
I've tried it, it works. Document it somewhere if the code is going
to move.
--
======= !{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!rjohnson =======
Feel free to correct me, but don't preface your correction with "BZZT!"
Roy Johnson, Shell Development Companygwyn@smoke.brl.mil (Doug Gwyn) (03/16/91)
In article <RJOHNSON.91Mar14111149@olorin.shell.com> rjohnson@shell.com (Roy Johnson) writes: >Instead of ##, use an empty comment: /**/ >I've tried it, it works. Document it somewhere if the code is going >to move. >Feel free to correct me, but don't preface your correction with "BZZT!" BONG! Sorry, I couldn't resist.. The /**/ kludge is not supposed to "work" (i.e. accomplish token pasting). However, in some implementations it does. It cannot work in any standard conforming implementation, however.
dave@cs.arizona.edu (Dave P. Schaumann) (03/16/91)
In article <RJOHNSON.91Mar14111149@olorin.shell.com> rjohnson@shell.com (Roy Johnson) writes: |In article <27489@netcom.COM> aed@netcom.COM (Andrew Davidson) writes: |>[wants token pasting on a pre-ansi compiler] | |Instead of ##, use an empty comment: /**/ |I've tried it, it works. Document it somewhere if the code is going |to move. Actually, from what I understand, this only works on *some* pre-ansi preprocessors. It is by no means universal. Let the programmer beware. -- Dave Schaumann | dave@cs.arizona.edu | Short .sig's rule!
catfood@NCoast.ORG (Mark W. Schumann) (03/17/91)
In article <27489@netcom.COM> aed@netcom.COM (Andrew Davidson) writes: >I belive that ansi preprocessors are supposed to support this as >follows > >#define name2(a,b) a##b > >unfortuanly I am using a k&r compiler (I am working on a sun work >station and can not change compilers) You could try #dfine name2(a,b) a/**/b This might work, but I am not sure whether K&R compilers strip comments before or after evaluating macros. Try it. -- ============================================================ Mark W. Schumann 3111 Mapledale Avenue, Cleveland 44109 USA Domain: catfood@ncoast.org UUCP: ...!mailrus!usenet.ins.cwru.edu!ncoast!catfood
grogers@convex.com (Geoffrey Rogers) (03/18/91)
In article <1991Mar16.213446.20392@NCoast.ORG> catfood@NCoast.ORG (Mark W. Schumann) writes: >You could try > > #dfine name2(a,b) a/**/b > >This might work, but I am not sure whether K&R compilers strip >comments before or after evaluating macros. Try it. Yes this works on some not all pre-ANSI cpp. Another to do the same thing is: #define name2(a,b) name2_(a)b #define name2_(a) a this also works. But I do not know if it works on all pre-ANSI cpp. +------------------------------------+---------------------------------+ | Geoffrey C. Rogers | "Whose brain did you get?" | | grogers@convex.com | "Abbie Normal!" | | {sun,uunet,uiucdcs}!convex!grogers | | +------------------------------------+---------------------------------+
rjohnson@shell.com (Roy Johnson) (03/18/91)
In article <15485@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: In article <RJOHNSON.91Mar14111149@olorin.shell.com> rjohnson@shell.com (Roy Johnson) writes: >Instead of ##, use an empty comment: /**/ >I've tried it, it works. Document it somewhere if the code is going >to move. >Feel free to correct me, but don't preface your correction with "BZZT!" BONG! Sorry, I couldn't resist.. The /**/ kludge is not supposed to "work" (i.e. accomplish token pasting). However, in some implementations it does. It cannot work in any standard conforming implementation, however. BZZZT! ;^) The original question asked about how to do it on the Sun, since the ## which *should* work, doesn't, because sun cc is not ANSI- compliant. -- ======= !{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!rjohnson ======= Feel free to correct me, but don't preface your correction with "BZZT!" Is it appropriate to post here about what's appropriate to post here? Roy Johnson, Shell Development Company
gwyn@smoke.brl.mil (Doug Gwyn) (03/19/91)
In article <RJOHNSON.91Mar18095140@olorin.shell.com> rjohnson@shell.com (Roy Johnson) writes: >BZZZT! ;^) The original question asked about how to do it on the Sun, >since the ## which *should* work, doesn't, because sun cc is not ANSI- >compliant. But even if it "works" today, it may stop working tomorrow, as indeed it must do once Sun releases a standard conforming C implementation.
rjohnson@shell.com (Roy Johnson) (03/19/91)
In article <15506@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: In article <RJOHNSON.91Mar18095140@olorin.shell.com> rjohnson@shell.com (Roy Johnson) writes: >BZZZT! ;^) The original question asked about how to do it on the Sun, >since the ## which *should* work, doesn't, because sun cc is not ANSI- >compliant. But even if it "works" today, it may stop working tomorrow, as indeed it must do once Sun releases a standard conforming C implementation. Right. *That's* why I told him to document it. Are you suggesting that he shouldn't write code that works because it isn't standard? I suspect he has a job to do. -- ======= !{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!rjohnson ======= Feel free to correct me, but don't preface your correction with "BZZT!" Is it appropriate to post here about what's appropriate to post here? Roy Johnson, Shell Development Company
gwyn@smoke.brl.mil (Doug Gwyn) (03/21/91)
In article <RJOHNSON.91Mar19092554@olorin.shell.com> rjohnson@shell.com (Roy Johnson) writes: > But even if it "works" today, it may stop working tomorrow, as indeed > it must do once Sun releases a standard conforming C implementation. >Right. *That's* why I told him to document it. Are you suggesting that >he shouldn't write code that works because it isn't standard? I suspect >he has a job to do. That's a short-sighted attitude. We KNOW such code will quit "working" some day. That should be sufficient reason to find a better solution that does not depend on errors in the C implementation.
rjohnson@shell.com (Roy Johnson) (03/22/91)
In article <15523@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: > That's a short-sighted attitude. We KNOW such code will quit "working" > some day. That should be sufficient reason to find a better solution > that does not depend on errors in the C implementation. Such as...? I suggested a kludge that I know works in the present. If that's all he needs, I've given him a working solution. If the code will eventually need to be recompiled (which we do not know), then the documentation should include the relatively small changes required to get it up to snuff -- and he knows what those changes are, since he needed a kludge to work around them in the present. Please explain why working with what you have, with an eye on the future is short-sighted. P.S. Thanks for clarifying my confusion on hex/oct constants. I was pretty sure about the dec-hex-oct equivalence, but not about differing bit-representations. -- ======= !{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!rjohnson ======= Feel free to correct me, but don't preface your correction with "BZZT!" Roy Johnson, Shell Development Company
gwyn@smoke.brl.mil (Doug Gwyn) (03/23/91)
In article <RJOHNSON.91Mar21104253@olorin.shell.com> rjohnson@shell.com (Roy Johnson) writes: >In article <15523@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >> That's a short-sighted attitude. We KNOW such code will quit "working" >> some day. That should be sufficient reason to find a better solution >> that does not depend on errors in the C implementation. >Such as...? As usual when someone asks how to do something that has no good answer, insufficient information was provided about the context for the respondent to be able to solve the REAL problem. Experienced systems analysts can attest to the fact that frequently the question actually asked is the wrong question because it already presupposes certain constraints on the answer that are not in fact necessary constraints, and the best overall solution often requires backing up to the real issue and solving that free of the unnecessary assumed constraints. I don't know why the original requestor thought he needed token pasting. I do know that in all cases where *I* have had a use for token pasting, I have also been able to find alternative solutions not involving token pasting at the C compilation level. For example, one might create a program that generates the desired C source code, using C, awk, m4, or some other existing language is a perfectly straightforward manner. >P.S. Thanks for clarifying my confusion on hex/oct constants. You're welcome -- that's what this newsgroup is for.