🚀 go-pugleaf

[preamble:
I had finished composing the following message, then found the thread 
"Problems using gcc 2.3.3" which told me that I am not the first person
to notice this.  However, someone mentioned that NeXT does contain a 
"non-ansi c++" -- where is that?  Then again, what is this message in the
release notes pertaining to? 
] 

I am in the process of trying to build an application in NS3.0,
via the AppKit/Project Builder, and including a C++ class.

First off, a little verbatim (via cut & paste) from the 
NS3.0 release notes file "C++.rtf":

---------------------------------------------------------------
The Release 3.0 compiler driver /bin/cc handles C, Objective-C, C++ and 
Objective-C++ source files.  The C++ compiler driver program /bin/cc++ is 
no longer needed (but is still poresent for compatibility).  The compiler 
driver determines the appropriate language from the suffix of the source 
files or command line options.  Files ending in .c are taken to be C source 
files, .m indicates an Objective-C source file, and .cc, .cxx, and .C are 
recognized as C++ source files.  The -ObjC flag specifies that source files 
should be considered to be Objective-C source files regardless of their 
extension.  Similarly, the -ObjC+ flag specifies that source files should 
be considered to be Objective-C++ source files.  The /bin/cc++ driver is 
simply a shell script which calls the /bin/cc driver with the -ObjC+ flag.
---------------------------

Maybe I take too much for granted, but this paragraph gave me the
impression that NS3.0 was all set up for compiling c++.  I was rudely 
awakened when I tried to compile a c++ version of "hello, world" to check
out the compiler, and though I used the above-mentioned switches, I was 
informed that it couldn't find iostream.h (c++ equivalent to stdio.h).
A search of the file system revealed no such file.  (BTW, the extension on
my source file is cc) 

Well, my quest led me to downloading the g++ compiler, libs and includes
from the archives (my thanks to the person who put that package together).
Via the g++ compiler and a Makefile (defining my include path and lib path),
I was able to successfully compile a c++ program.   I then switched the compiler name ONLY, g++ to cc, the compiler bundled with NS3.0, all else 
(include and libs) intact.  I then get the message:  
	cppt.cc:4: iostream.h: No such file or directory

Strange, because g++ was able to follow the same path and find it.
(also, it compiled with gcc, part of the same bundle on the archives)
Does the bundled compiler expect the includes to be in a specific
(that is, pre-defined/hard-coded) spot?

Anyway, I've come to terms with the fact that I must compile my c++ code
with a different compiler.  Now, I would like a NeXT app, created via 
Project Builder, to contain both Objective C and c++ code.  If I were 
using a makefile, I would know how to do it.  But now, I must tell PB 
to use a different compiler to create the .o file for the c++ source and
link it in to the app being created.  I used Makefile.preamble to define
the compile of the .cc file, which succeeds in creating the .o file.
However, I'm not doing enough here: it's not able to link it to the rest of 
the app.

To summarize, my goal is to use both c++ and Objective C in the same app;
I must be able to do one of the following:
	1) find a way to get the compiler bundled with NS3.0 to compile my 
		    c++ code and link it with the rest of the app
	2) get PB to know how to compile the c++ code with the g++ compiler 
		    AND link it with the app.
		
I would much appreciate hearing from anyone who has succeeded with such.
(please, no flames about using c++ )
Also, if anyone from NeXT would care to expand upon the quoted release notes,
I would very much like to hear it.  Is Objective-C++ (mentioned in 
release notes) NeXT's dialect of c++?


	   
   
-- 
                                         --vin
vin@netcom.com
------------------------------------------------------------------------
If productivity can really be measured as the rate at which lines of
code are produced, why not just use a tight loop to spew code as fast
as possible, and send the programmers home?
                                            --Brad Cox