Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!wuarchive!uunet!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: C++
Message-ID: <14422@cbmvax.commodore.com>
Date: 13 Sep 90 21:38:10 GMT
References: <26ed022f-8f5comp.sys.amiga.tech@tronsbox.xei.com>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 52

In article <26ed022f-8f5comp.sys.amiga.tech@tronsbox.xei.com> tron1@tronsbox.xei.com (HIM) writes:

>     1) I have examined the output C from C++ , it makes very standard
>        1.2 Style calls to the OS. The example programs that use
>        windows/gadgets/draw graphics all run under 2.0 without
>        problem.
>
>        HOW compatible is 2.0 to 1.3 code ? I am not talking about 
>        manipulating device drivers, or playing with the blitter here,
>        just standard MENU/WINDOW/GADGET work assuming the C code plays
>        "By the rules" ?

There's no problem with correctly written 1.3 software running under 2.0; as
long as you're not counting on private parts of structures looking the same,
or similar dirty tricks, you're in great shape.  For example, every program
I've written that doesn't depend on some 1.3 trick (eg, SetFont) or something
unsupported under 1.3 (eg, SetCPU V1.5, which ran into problems since it 
dealt with cache control issues that 2.0 solved differently) work just great.

>     2) Has anyone on the net attempted to work with the C++ compiler ?
>        ESPECIALLY under 2.0 ??  I hvae seen posts about that it is
>        buggy to the point that it is un-usable, but aside from the
>        obvious problem that 1.0 is a BIG step back from 2.0
>        (I WANT FSTREAMS) .. I havent seen any BUGS. But this is
>        is only with the SIMPLE tests I have run. Any opinions
>        (as opposed to flames) welcome.

I have only used it under 1.3.  While I didn't have any trouble with the 
resulting code, I did have some troubles with the C++ compiler.  It wanted
a heck of alot of stack (512K worked good) to avoid some crashes, and yet
it still had a problem with crashing on syntax errors.  The biggest problem
is the lack of a debugger -- once you're used to using a decent source level
debugger, you don't want to go back to "printfs" (or cout << for that matter).

>     3) The Documentation is a bit sparse ( ;-) ) with the C++
>        that Lattice provided. It IS consistent, so if someone has
>        related the approach between the C++ objects and the
>        C struct counterparts one example will unlock the text.

I was actually surprised they included a text on the C++ language; most
compilers only discuss the differences between their implementation of
the language, if any, and probably list all library functions.  I wouldn't
have minded a few details on some of the rather esoteric stuff (for 
example, a way to replace the C++ allocator with my own, globally) but 
overall, I didn't find the docs that bad.

>============= Ken Jamieson: uunet!tronsbox.xei.com!tron1  ==================

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
      Get that coffee outta my face, put a Margarita in its place!