andrew@comp.vuw.ac.nz (Andrew Vignaux) (06/08/88)
Something that I would like to see in LSC is the ability to define preprocessor symbols for the *project* as a whole (ala Unix "cc -D"). I think there is a need for a conditional compilation facility even when writing Macintosh-only code. Consider a "change cursor" module to be used in two programs, one event-driven and the other a more batch-like processor. There is no need have the "maintain cursor" code when there will be no event loop to call it. One solution is for LSC to define the symbol `LSC' and the "project symbol" (a canonicalized version of the project file name ?). Then the programmer can define whatever s/he likes in a header file. A better solution might be to "include" the data fork of the project file before compiling each file so s/he can do anything they want -- this fork is currently unused. "Putting the definitions in an include file" doesn't work because I want different definitions depending on the particular project. LSC's #include search path partially solves the problem, except it means that you can only have one project per directory, and the "library" file must be in a distinct directory. Of course if LSC (2.15) already has things predefined and they are in TFM, or there's a nicer/better way, i'll shutup and go back to doing my Masters :-) Comments? Andrew ------------------------------------------------------------------------------ Domain address: andrew@comp.vuw.ac.nz Path address: ...!uunet!vuwcomp!andrew
Michael_mkahl_Kahl@cup.portal.com (06/26/88)
> Something that I would like to see in LSC is the ability to define > preprocessor symbols for the *project* as a whole (ala Unix "cc -D"). > ... > "Putting the definitions in an include file" doesn't work because I want > different definitions depending on the particular project. LSC's #include > search path partially solves the problem, except it means that you can only > have one project per directory, and the "library" file must be in a distinct > directory. There is no great way to do this in LSC 2.xx, but there is in 3.0 (shipping imminently). The method is basically the "put the definitions in an include file" approach, with a hack to make it work for multiple projects in a single directory. As you may know, any directory whose name is parenthesized is skipped during directory searches. In 3.0, this rule is modified: if a directory's name is the parenthesized name of the project, it's not skipped. Thus each project sharing a directory can have its own private subdirectory. Each subdirectory can have a different "config.h", for example. In addition, LSC 3.0 pre-#defines the symbol "THINK_C". -- Michael Kahl, Symantec
dwb@Apple.COM (David W. Berry) (06/28/88)
In article <6879@cup.portal.com> Michael_mkahl_Kahl@cup.portal.com writes: >In addition, LSC 3.0 pre-#defines the symbol "THINK_C". Any particular reason for using THINK_C instead of the more ANSI-acceptable __THINK_C? Opinions: MINE, ALL MINE! (greedy evil chuckle) David W. Berry apple!dwb@sun.com dwb@apple.com 973-5168@408.MaBell
nagel@ics.uci.edu (Mark Nagel) (06/28/88)
In article <12917@apple.Apple.COM> dwb@apple.apple.com.UUCP (David W. Berry) writes: +In article <6879@cup.portal.com> Michael_mkahl_Kahl@cup.portal.com writes: +>In addition, LSC 3.0 pre-#defines the symbol "THINK_C". + Any particular reason for using THINK_C instead of the +more ANSI-acceptable __THINK_C? Speaking of ANSI-acceptability, can anyone from THINK expand on the changes (if any) made to LightspeedC in order to bring it more into ANSI compliance? E.g. have prototypes been modified to reflect the new standard? Have the new keywords (const, volatile, etc.) been added? Anything?? -- Mark D. Nagel Department of Information and Computer Science, UC Irvine nagel@ics.uci.edu (ARPA) I'm not a graduate student, {sdcsvax|ucbvax}!ucivax!nagel (UUCP) but I play one on TV...
Michael_mkahl_Kahl@cup.portal.com (06/30/88)
> Any particular reason for using THINK_C instead of the >more ANSI-acceptable __THINK_C? No particular reason. I don't imagine THINK_C will lead to many conflicts. >Speaking of ANSI-acceptability, can anyone from THINK expand on the changes >(if any) made to LightspeedC in order to bring it more into ANSI compliance? >E.g. have prototypes been modified to reflect the new standard? Have the new >keywords (const, volatile, etc.) been added? Anything?? The preprocessor now supports the # and ## operators for string-izing and token-splicing. Full ANSI support was delayed in order to get the debugger out. However, we do intend to fully conform to the ANSI standard (when it is finalized), and hope that our customers appreciate the preprocessor extensions as a step in this direction. -- Michael Kahl, Symantec