ix181@sdcc6.ucsd.EDU (John Ogawa) (10/04/86)
>>>>>>>>>>>> Eat away you monster!!! <<<<<<<<<<<
I am an avid C++ fan who is about to get an Atari 1040ST and a C
package. My question is: is there any way to get a C++ package for
the 1040? Alternately, is there any C source code for CC that I can
get my hands on?
Thanks in advance.
John Ogawa
UC San Diegodclemans@mntgfx.UUCP (Dave Clemans) (10/07/86)
Oasys Systems has been advertising commercial support for C++ in a variety of systems; in particular using Lattice C on the IBM PC. It would be relatively simple bring up C++ under Lattice C for the ST; Oasys just has to be convinced that it is worth the effort to do so. None of the other ST C compilers (especially Alcyon C which comes with the developers kit) would be usable back-ends for C++; the backend compiler the AT&T released C++ frontend REALLY!!! needs at least 32 significant characters in names. To my knowledge, Lattice C (using the GST linker) is the only ST C compiler that can support 32 significant characters in names. dgc
brinsmead@calgary.UUCP (Mark Brinsmead) (10/07/86)
In article <2939@sdcc6.ucsd.EDU>, ix181@sdcc6.ucsd.EDU (John Ogawa) writes: > I am an avid C++ fan who is about to get an Atari 1040ST and a C > package. My question is: is there any way to get a C++ package for > the 1040? Alternately, is there any C source code for CC that I can > get my hands on? I am afraid this is unlikely. All C++ compilers I am aware of (i.e. AT&T's) are actually fancy preprocessors that spit out rather wild looking C. If CC is to work on an atari, your ATARI C compiler must (and i mean MUST) be able to cope with *ARBITRARILY* long identifiers. I am not aware of any C compiler for the atari ST that will suffice, (my own Lattice C compiler nmormally uses only the first 8 characters, and will in any event, use at most 32 characters of an identifier. This is probably not enough for C++. ) M. Brinsmead @ Univewrsity of Calgary.
lbl@druhi.UUCP (LocklearLB) (10/09/86)
In article <429@vaxb.calgary.UUCP>, brinsmead@calgary.UUCP (Mark Brinsmead) writes: > In article <2939@sdcc6.ucsd.EDU>, ix181@sdcc6.ucsd.EDU (John Ogawa) writes: > > I am an avid C++ fan who is about to get an Atari 1040ST and a C > > package. My question is: is there any way to get a C++ package for > > the 1040? Alternately, is there any C source code for CC that I can > > get my hands on? > > I am afraid this is unlikely. All C++ compilers I am aware of > (i.e. AT&T's) are actually fancy preprocessors that spit out rather > wild looking C. If CC is to work on an atari, your ATARI C compiler > must (and i mean MUST) be able to cope with *ARBITRARILY* long > identifiers. > > I am not aware of any C compiler for the atari ST that will suffice, > (my own Lattice C compiler nmormally uses only the first 8 characters, > and will in any event, use at most 32 characters of an identifier. > This is probably not enough for C++. ) > > M. Brinsmead @ Univewrsity of Calgary. If your compiler is capable of handling 32 character variable names, you should normally not have any problems with using C++. There may be isolated cases where problems would occur, but the names that the C++ compiler generates are usually unique in the first 32 characters. Of course, it would be nice if one of the C vendors for the ST would provide a true flexname capability. It really isn't very difficult to do! Barry Locklear AT&T Information Systems Labs Denver, CO 80234 (303) 538-4954 ihnp4!drutx!druhi!lbl
braner@batcomputer.TN.CORNELL.EDU (braner) (10/10/86)
Regarding the need for a C compiler that would handle long identifiers, y'all might not know that Megamax recognizes the first 10 chars, and allows very long total length. That may still not be enough for C++ - I dunno. (and you still need to get that C++ preprocessor...) BTW: I devised a method to do object-oriented programming in C. Not fancy but simple, and you get inheritance and even late binding of sorts with high efficiency (about 100 microSecs for a typical invocation of a method). If anybody is interested let me know. - Moshe Braner
cgoudeseune@watnot.UUCP (center of gravity) (10/14/86)
I hear all these complaints that most C's only support 8-character identifiers, and the C++ preprocessor *needs* thirty-two. Say we use only 7-character letters-only identifiers. 26^7 = 8 031 810 176. Seeing as how any C++ preprocessor is unlikely to produce over 8 billion different identifiers, is there a good reason why a little filter couldn't be inserted between C++'s output and C's input to shrink the size of these huge identifiers to a manageable size. Sure, it's slow; we've got a 8 MHz 68000. Sure, it's a kludge; it works! (I hope) Camille
mvh@cbnap.UUCP (M.L. Vonder Haar x4126 3E257) (10/14/86)
In article <12069@watnot.UUCP> cgoudeseune@watnot.UUCP (center of gravity) writes: >I hear all these complaints that most C's only support 8-character >identifiers, and the C++ preprocessor *needs* thirty-two. > >Say we use only 7-character letters-only identifiers. >26^7 = 8 031 810 176. >Seeing as how any C++ preprocessor is unlikely to produce over 8 billion >different identifiers, is there a good reason why a little filter couldn't >be inserted between C++'s output and C's input to shrink the size of these >huge identifiers to a manageable size. >Sure, it's slow; we've got a 8 MHz 68000. Sure, it's a kludge; it works! >(I hope) > I just hope you never have a bug. Sdb is only fair as a debugger for C++. But if you generated names that could not be easily transformed by programmers to what they wrote in C++ sdb would be just about useless. The way I see it you'll need to write your own debugger at the same time. Mark L Vonder Haar {ihnp4|cbosgd}!cbnap!mvh
brinsmead@calgary.UUCP (Mark Brinsmead) (10/15/86)
In article <1117@druhi.UUCP>, lbl@druhi.UUCP (LocklearLB) writes: > > If your compiler is capable of handling 32 character variable names, you should > normally not have any problems with using C++. There may be isolated cases > where problems would occur, but the names that the C++ compiler generates are > usually unique in the first 32 characters. Of course, it would be nice if one > of the C vendors for the ST would provide a true flexname capability. It really > isn't very difficult to do! > Oops, I guess I stand corrected. Of course, I've always believed that if something dosen't work for certain isolated cases, it simply dosent work, however, I suppose that if it means we *CAN* have C++ on an ST, this is something we could learn to live with. (Provided, of course, that you don't mind not being able to count on a given (correct) program compiling.) Where do I order my Cfront?
braner@batcomputer.TN.CORNELL.EDU (braner) (10/16/86)
[] Filtering long identifiers into short (but not mnemonic) forms would work, I guess. But since we also have a Megabyte, it is not reasonable to limit identifiers to anything less than 255 chars! Come on, compiler makers: it's 1986! - Moshe Braner
desj@brahms@ndmce.uucp (David desJardins) (10/17/86)
In article <173@cbnap.UUCP> mvh@cbnap.UUCP (M.L. Vonder Haar x4126 3E257) writes: > I just hope you never have a bug. Sdb is only fair as a debugger > for C++. But if you generated names that could not be easily > transformed by programmers to what they wrote in C++ sdb would be > just about useless. > The way I see it you'll need to write your own debugger at the > same time. If it were important enough you could keep a table of the correspondences between symbol names and then write a postprocessor to rewrite the correct symbolic names into the a.out file; this shouldn't be more than a day's work. -- David desJardins
phr@ernie.Berkeley.EDU (Paul Rubin) (10/18/86)
In article <1222@batcomputer.TN.CORNELL.EDU> braner@batcomputer.UUCP (braner) writes: >[] > >Filtering long identifiers into short (but not mnemonic) forms would >work, I guess. But since we also have a Megabyte, it is not reasonable >to limit identifiers to anything less than 255 chars! Come on, compiler >makers: it's 1986! If anyone is interested, note that the past few GNU Emacs distributions have included a simple program that reads C source code and produces a file of #define statements to map long identifiers into short ones. It also includes a replacement C Preprocesor (cpp) in case the one you are currently using doesn't handle arbitrarily long identifiers.