🚀 go-pugleaf

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

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.

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

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

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

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

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

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?

[]

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

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

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.