Path: utzoo!attcan!uunet!portal!cup.portal.com!Michael_mkahl_Kahl From: Michael_mkahl_Kahl@cup.portal.com Newsgroups: comp.sys.mac.programmer Subject: Re: Lightspeed C projects Message-ID: <6980@cup.portal.com> Date: 30 Jun 88 01:38:07 GMT References: <1407@its63b.ed.ac.uk> <4710@husc6.harvard.edu> <6879@cup.porta Organization: The Portal System (TM) Lines: 17 XPortal-User-Id: 1.1001.4169 > 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