Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!munnari.oz.au!csource!jhom From: jhom@csource.oz.au (joaquim homrighausen) Newsgroups: comp.sys.ibm.pc Subject: Any comments for TOPSPEED C? Message-ID: <172.260D7B8D@csource.oz.au> Date: 26 Mar 90 15:23:00 GMT Organization: Unique Computing Pty Limited Lines: 67 > I've been reading ACM's communication mag and usually > there is an ad for TOPSPEED C. They compare their compiler to > all other name brands. The question I have is, "If they are so > worthy of such a comparison, why haven't I seen a reference to > them on the net?" This seems to be the case with all new compilers, specially C compilers. Most people are waiting for others to try them out :-) I got involved with TopSpeed C from a fairly early stage and must say that I like it quite a bit. I can't say I'm overly impressed with their intergrated environment, but that's of course my personal opinion. You can customize their environment to a great extent, including redefine keys and menu layouts to your liking. Their built-in project management (make facility) is OK, but I'd prefer to use NDMAKE and BRIEF for my development and then just compile with TSC. Unfortunately, their project management makes this somewhat complicated. The way to get around it is to use NDMAKE (or whatever your favorite make utility is) to compile everything and then you create a .PRJ file and tell TSC to make it - in this case, linking would be the only thing left to do. The compiler is somewhere between MSC and Turbo C in regards to speed, but TSC comes very close and in some cases better than MSC in regards to optimization. Few compilers can claim the same. If you get their "techkit", which includes a post mortem debugger module and RTL source code as well as a cute 'watch' (tracks which INT 0x21 functions a program calls) program.. The biggest problem with TSC as I see it is caused by brain-dead third-party library developers.. TSC has a third (after pascal and cdecl type functions) calling convention, simply referred to as the JPI calling convention. In which case TSC uses registers to pass parameters to functions instead of on the stack. This causes problems with libraries that are not made with TSC. You get around it by explicitly defining the prototypes for the library as "pascal" or "cdecl" before you re-compile your application. I've "ported" (not much porting involved) several of my applications to TSC and can't say I regret it. A couple of #ifdef:s keeps me in touch with Turbo C and MSC just in case it'd ever be required :-) But I doubt it. All in all, TSC is a strong package and I would recommend it to anyone who's looking for a possible new compiler. I personally think they're here to stay, specially since they have one of the best Modula-2 environments for the PC.. a Pascal package is "on its way" and rumors about a C++ package is starting to pop up in various conferences. -- Software solutions on a silver platter -------------------------------------- UUCP: mulga!csource!jhom Internet: jhom@csource.oz.au FidoNet: 3:632/348 --------------------------------------------- Technotron debuggah, the ultimate technopunk! ---------------------------------------------