edw@IUS1.CS.CMU.EDU (Eddie Wyatt) (02/20/88)
I'm soliticing comments on two new macro I added to my repetoire of useful things. #define IMPORT(from) extern #define EXPORT(to) example of usage: IMPORT (geometry.c) TOKEN vw_trans_at(); EXPORT (tokenf.c main.c) void add_to_frametable(); -- Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu
angst%csilvax@hub.ucsb.edu (The Stinkpuff) (02/20/88)
In article <906@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: > I'm soliticing comments on two new macro I added to my repetoire of >useful things. > >#define IMPORT(from) extern >#define EXPORT(to) > >example of usage: > >IMPORT (geometry.c) TOKEN vw_trans_at(); >EXPORT (tokenf.c main.c) void add_to_frametable(); Yes! I like them. I usually use #define import extern #define export but yours are better, in my humble opionion. BTW, other useful macros for information hiders/software engineers are: #define private static /* function or variables */ #define public /* same */ #define procedure void /* Comments? Dave Stein Running without aim through the razor weeds that angst%csilvax@hub.ucsb.edu only reach my knees. And when I'm lying in the ...ucbvax!hub!csilvax!angst grey sleep, I don't know how to walk the boards.
rbutterworth@watmath.waterloo.edu (Ray Butterworth) (02/21/88)
In article <906@PT.CS.CMU.EDU>, edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: > I'm soliticing comments on two new macro I added to my repetoire of > useful things. > IMPORT (geometry.c) TOKEN vw_trans_at(); > EXPORT (tokenf.c main.c) void add_to_frametable(); Compare that form with this form: extern Token vw_trans_at(); /* defined in geometry.c */ void add_to_frametable(); /* used by tokenf.c and main.c */ I think both forms say more or less the same thing. The first form is understandable by you and anyone else familiar with your style and macros. The second form is understandable by anyone that has even a small understanding of C (and English). The first form looks like it might actually do something, and the reader will be forced to figure out what the macros do and be somewhat peeved when he finds they don't do anything. The second form is a comment that the reader can use his own judgement on (e.g. vw_trans_at might actually be in algebra.c since you rearranged things last month. And you forgot that flibit.c also has references to add_to_frametable()). I've worked for companies that tried to do such cross referencing manually. It was a very expensive overhead, and I'm sure they got at least 90% of it correct. If you want to define macros to obscure your code, perhaps you should enter the obfuscated C contest this year. But if all you want to do is to comment the code, why not simply use the standard comment mechanism defined by the language?
rsalz@bbn.com (Rich Salz) (02/21/88)
In article <906@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) asks for
feedback on:
#define IMPORT(from) extern
#define EXPORT(to)
with this sample usage;
IMPORT (geometry.c) TOKEN vw_trans_at();
EXPORT (tokenf.c main.c) void add_to_frametable();
Cute, but I don't like them because they violate the "write once" rule.
If you move a routine, you have to remember to change the header file
where the #define's appear.
It's much better to use information abstractors on the primary source to
get the data you seek. In less jargon, use ctags or something similar;
it was published in comp.sources.unix some while ago, and can be freely
redistributed.
--
For comp.sources.unix stuff, mail to sources@uunet.uu.net.djones@megatest.UUCP (Dave Jones) (02/22/88)
in article <906@PT.CS.CMU.EDU>, edw@IUS1.CS.CMU.EDU (Eddie Wyatt) says: > > > I'm soliticing comments on two new macro I added to my repetoire of > useful things. > > > #define IMPORT(from) extern > #define EXPORT(to) > > > example of usage: > > IMPORT (geometry.c) TOKEN vw_trans_at(); > EXPORT (tokenf.c main.c) void add_to_frametable(); > -- > > Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu Did you say what you meant to say? I think not. If so I don't understand. So I don't know if the following comment is applicatble or not. But here goes, anyway: Macros constitute a flawed but useful mechanism for abstraction. Use them for that purpose. Macros which effectively make changes to C syntax are a pain in the butt. I too find many deficits in C syntax. But trying to correct them with SLM's (silly little macros) just forces the code maintainer to grep around in your .h files trying to figure out what you REALY were saying. I a m p u t t i n g t h i s h e r e f o r i n e w s , to make my reply as long as the original. Phfft!