Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site mtx5a.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!akguc!mtunh!mtung!mtunf!mtx5c!mtx5d!mtx5a!mat
From: mat@mtx5a.UUCP (m.terribile)
Newsgroups: net.lang.c++
Subject: Re: Re: C++ installation on 4.3bsd (Shorter!)
Message-ID: <1263@mtx5a.UUCP>
Date: Wed, 2-Apr-86 21:51:09 EST
Article-I.D.: mtx5a.1263
Posted: Wed Apr  2 21:51:09 1986
Date-Received: Sat, 5-Apr-86 12:14:00 EST
References: <952@megaron.UUCP> <278@cit-vax.Caltech.Edu>
Distribution: net
Organization: AT&T Information Systems, Middletown, NJ 07748-4801.
Lines: 49

>     WARNING: The following  is	a  LONG  (~440	lines)	message  about
> problems and experiences porting C++.  Hit  'n'  now  unless  you  are
> having problems getting the new release of C++ running.
. . .
>     B) Optimization
> 
> 	On UTS, the optimizer pass of the C compiler (/lib/c2)  core
>     dumps while trying to compile parts of the C++ library
>     (specifically lib/complex/io.c). Rather than try to figure out
>     why, I just removed the -O flag from 'lib/mk/makefile' and
>     'makefile'.  Bjarne says that many optimizers break on
>     automagically generated C code such as that produced by cfront.

I can understand why compilers might have difficulty.  On the other hand,
it is precisely on automagically generated code that optimization is
most needed, because such code is most likely to have extra copy and
conversion operations introduced by the crypto-automagicalator (eg. cfront :-)
Those of us who are in a postion to influence such things should push for
robust compilers and optimizers; Maytags, if you will, that can take lots of
use and come up for more.

> 	Getting cfront to recompile itself is certainly a  good  test.
> 
>     The only other test I have come up with is this progam:
> 
> 	#include <stream.h>
> 	main() {
> 	    cout << "Hello, world\n";
> 	}
> 
> 	What makes this worth  doing  is  that	'cout'	has  a	static
>     constructor; thus, if the 'munch' program does not work  properly,
>     said constructor will not be initialized and when the  program  is
>     run   you	will   probably   get	a   core   dump    (dies    in
>     __ostream__lshiftFPC__) instead of 'Hello, world'.

Ah, yes.  For those of you who have the ``patch'' version instead of the
``munch'' version, if this error occurs, check the symbols in the source
code for ``patch''.  You may find that your cc puts in more or fewer
underscores than patch expects.  There are two or three lines that need
to be changed, and the code is surprisingly simple.  I have the patch
version up here, and it seems to run fine.
-- 

	from Mole End			Mark Terribile
		(scrape .. dig )	mtx5b!mat
					(Please mail to mtx5b!mat, NOT mtx5a!
						mat, or to mtx5a!mtx5b!mat)
    ,..      .,,       ,,,   ..,***_*.