🚀 go-pugleaf

In article <1k1e30INNnuj@phakt.usc.edu> thartman@phakt.usc.edu (Tye) writes:
> I have a NeXTStation running 3.0, with the full development package  
installed. 
> The university here is using AT&T C++, whereas my NeXT is using the hacked
> ANSI C++ (I think?).  Are these compatible?  Similarly, if I install the 
> GNU G++, will this be compatible w/ AT&T?

The NeXT c++ is not compatible with the at&t (I would imagine your U is using  
the latest c++ specification -- NeXT isn't)  gcc 2.3.3 should be mostly  
compatible with at&t (I don't know if catch and throw are implemented in either  
at present).  I am also relatively certain that you can use gcc 2.3.3 and the  
corresponding libg++ on the next as long as you don't try to compile any obj-c  
with it (it will barf on the proprietary stuff next added onto o-c in 3.0 --  
expect this to be fixed in the next gnu release though). Do get gcc from the  
archives though, it makes installation so much easier!  To the person that  
compiled gcc 2.3.3 (I forget your name): there is space on cs.orst.edu!

> 
> Also, the school is using Lucid Common Lisp/SPARC 4.1 for Lisp development.
> Is this compatible w/ the Allegro Common Lisp on the NeXT?

Mostly.  You should probably compile your ACL as case-insensitive, upper-case  
preferred -- although this will preempt any attempt at using ACL with obj-c, IB  
etc. etc.

> 
> Why, oh why, can't there just be one standard?  (Dream, dream, dream...)

If every language could just compile their stuff (what a scientific term :)  
into a common library format, so that Joe programmer could use his chosen  
language (sounds religious doesn't it :) and just include the different  
libraries. Then everything could be written in the one and only language  
(programmer dependent of course :)  or alternatively the language best suited  
for the tast (... but language x is best for everything...)  A loader/linker   
that could make sense out of the resulting code would be nice too :)

> 
> Thanks!
> Tyson Hartman
> thartman@aludra.usc.edu
> 

(BTW, I know that O-C can represent any problem better than any other language;  
that it is the only OO language, or other language for that matter, that is  
worth using; and that if I even think of using another language I am a moron  
and I should probably go buy myself a sun. Since all of this was kindly pointed  
out to me in e-mail by people on the net.  And if you dare try flaming me for  
this through e-mail I will mail you a virus that instantly disables your ] key  
:)

Forever your humble servant,
	Bjorn

------------------------------------------------------------------------------
Bjorn S. Fjeld Pettersen
bjorn@doek.uoregon.edu                       NextMail Welcomed
#include <std-disclaimer.h>
------------------------------------------------------------------------------

>>>>> On 27 Jan 93 10:32:21 GMT, bjorn@darmok.uoregon.edu (Bjorn S.
Fjeld Pettersen) said: 

	Bjorn> In article <1k1e30INNnuj@phakt.usc.edu>
        Bjorn> thartman@phakt.usc.edu (Tye) writes: 
[C++ discussion deleted]
> 
> Also, the school is using Lucid Common Lisp/SPARC 4.1 for Lisp
> development.  Is this compatible w/ the Allegro Common Lisp on the
> NeXT?

	Bjorn> Mostly.  You should probably compile your ACL as
	Bjorn> case-insensitive, upper-case preferred -- although this
	Bjorn> will preempt any attempt at using ACL with obj-c, IB
	Bjorn> etc. etc.

A correction here: the most recent version of ACL for the NeXT is
still 3.1.20. This is compatible with the corresponding version on
Suns, and largely similar to Lucid CL of the same vintage - but
different in important ways from Lucid (and Allegro) CL 4.x. The main
difference is that both Lucid and Allegro include (slightly different
versions of) CLOS in their 4.x implementations. Franz has apparently
all but finished ACL 4.1 for NeXT, but hasn't seen fit to release it
yet :-(  Until they do, case sensititvity may be the least of your
problems in porting Sun CL code to the NeXT.

--Steve Anderson