sw@nan.co.uk (Sak Wathanasin) (05/23/91)
Got my copy of Zortech C++ today, installed it as per instructions (which were pretty clear). I modified the MacApp C++ header files following the supplied instructions (Zortech could have distributed them in the form of executable MPW scripts, and saved me some copying & pasting). I can build both non-MacApp and MacApp programs and they run, so I think I have all the include files and libraries all in the right folders. The problem is with programs that I build that incorporate the MacApp debugger. The built program runs, and puts up the "Debug" menu. I can open the debug transcript from the menu, but as soon as I try to "Enter MacApp Debugger" or try typing in the Debug transcript window, the Mac freezes and I can only get out of it by rebooting; I can't even get into Macsbug. Even "Show software versions" is enough to cause the freeze sometimes. The release and installation notes do not mention this, nor does the manual (or at least I haven't been able to spot it). Have anyone else tried this? I'm using MPW 3.2b12 (with the 3.3a1 shell) and MacApp 2.0.1 (from the ETO #3 CD) using 6.0.7 on a IIfx with 8MB. If I rebuild using CFront, all is well, so I do not suspect INIT clashes. If you have had ZTC for a while, I'd be interested in hearing about your experiences with it. I have it on a 30 day mbg, and I need to decide whether to keep it. I've only tried it so far on small programs (about 2.5K lines), but it doesn't seem any faster than MPW's CFront/C combo. In fact, if the MacApp hdrs are precompiled, CPlus beats ZTC. The good news is that turning on optimization doesn't appreciably slow down the compiler (despite the manual giving impressions to the contary). Just to get a feel for kind of speedups possible, I tried ZTC on the dhrystone benchmark, and with all opts turned on, ZTC generated code that ran 25% faster than compiling with no opt. It was about 10% faster than MPW C's efforts, and just slightly better than MPW C with 68020 code generation (ZTC doesn't have a '020 option; at least I couldn't find one). Of course, one can't read too much into this one test, so if you have any more data I'd be grateful for them. Thanks in advance, and I'll summarize if there's any interest. Sak Wathanasin Network Analysis Limited uucp: ...!ukc!nan!sw other: sw@network-analysis-ltd.co.uk phone: (+44) 203 419996 snail: 178 Wainbody Ave South, Coventry CV3 6BX, UK
anders@verity.com (Anders Wallgren) (05/24/91)
We just got Zortech C++, and I installed it, which was pretty easy, although there were a few typos in the 'recommended modifications' I had to make to MacApp. Luckily they were syntactic in nature, so you wouldn't have been able to compile without getting it right first. Unfortunately, that's about as far as I got. I couldn't get it to compile my app, because it complained about return values for MacApp methods that I override in my C++ classes, and I couldn't figure it out and haven't had time to call tech support. Speed-wise, I was somewhat impressed. I heard from the MacApp team at WWDC that "ztc without load/dump (which it doesn't have yet) was almost as fast as CFront with load/dump", but my experiences didn't really confirm this. On top of the already hefty MacApp headers, we have at least that much again of our own header files, and their preprocessor took its sweet time. Caveat this with my inability to compile my entire app, wasn't running with a ram disk (because I couldn't figure out what ztc was using as it's temporary area - turns out the documentation is wrong), and haven't done any rigorous tests. Lets just say that it definately isn't slower. With load/dump it may prove much faster. Another problem that I have is that it doesn't yet support the 32-bit-everything runtime environment, which I need since our app smokes the jump table and global data limits with a vengeance. Hopefully this will be forthcoming. Conclusion: not enough data yet to say whether it's worth the price or whether you should stick to MPW CFront. anders
sw@nan.co.uk (Sak Wathanasin) (05/25/91)
In article <0101000D.uxsb5f@nan.co.uk>, sw@nan.co.uk (Sak Wathanasin) writes: > I can build both non-MacApp and MacApp programs and they run, so I think I have > all the include files and libraries all in the right folders. The problem is > with programs that I build that incorporate the MacApp debugger. The built > program runs, and puts up the "Debug" menu. I can open the debug transcript > from the menu, but as soon as I try to "Enter MacApp Debugger" or try typing in > the Debug transcript window, the Mac freezes and I can only get out of it by > rebooting; I can't even get into Macsbug. Even "Show software versions" is > enough to cause the freeze sometimes. I have now found out that if I replace {ZLibraries}ZLibC.o in the build with the standard MPW C library, {CLibraries}StdCLib.o, everything works fine. I.e., I can use the MacApp debugger again. It seems to me that there is a problem with the Zortech libc, and the way the MacApp debugger traps writelns and printfs to its transcript window. By the way, their tech support called me back the next day after I reported the problem. They didn't have the right answer, but at least they called back. That was the good news. The bad news is that I've now discovered a bug in ZTC where it generates incorrect code in certain circumstances. I have sent details to Zortech tech support, but if you want to know, send me email. Sak Wathanasin Network Analysis Limited uucp: ...!ukc!nan!sw other: sw@network-analysis-ltd.co.uk phone: (+44) 203 419996 snail: 178 Wainbody Ave South, Coventry CV3 6BX, UK