ho@hoss.unl.edu (Tiny Bubbles...) (08/28/90)
Thanks to all who responded to my post about Turbo C++, which was even
put into the wrong newsgroup (egg on my face).
I heard it was good, fast and rodent-friendly; tradeoffs include bugginess
and lack of speed. That's a problem when I only have an 8-MHz XT.
Of course, most of the people complaining of bugs said they happened in
conjunction with a destructor thingamajigie when mounted sufficiently
close to Saddam Hussein's chemical factory tent land mine tank anti-missile
launcher submarine hangar. I haven't the foggiest idea what a destructor
is, not being a C++ programmer, but most of the rest of that stuff sounds
pretty destructive to me. :-)
I'll wait for another of Borland's incessant "buy! buy!" flyers. Strange,
I get flyers for Quattro Pro every month or so, but I've gotten a grand
total of one for Turbo C++. Hmmm... wonder why that is.
--
---
... Michael Ho, University of Nebraska
Internet: ho@hoss.unl.edujohnm@cory.Berkeley.EDU (John D. Mitchell) (12/11/90)
In article <25839@uflorida.cis.ufl.EDU> jdb@reef.cis.ufl.edu (Brian K. W. Hook) writes: [...] >get VERY unreliable and my .EXE finished file is pretty buggy when my .PRJ >and/or .DSK files get rather large (32+K). Is there a way to "clean up" my >.PRJ file without deleting it. I dont use many project notes, and it is a [...] There's a bug in the compiler that was supposedly fixed in v1.01 and by the patch disk. Good luck, John D. Mitchell johnm@cory.Berkeley.EDU
cla@isis.cs.du.edu (Chuck Anderson) (12/12/90)
In article <25804@uflorida.cis.ufl.EDU> jdb@reef.cis.ufl.edu (Brian K. W. Hook) writes: >I have Turbo C++ 1.00 but have noticed that it has a couple of errors, ie. >bugs. Has anyone encountered the fact that the debugger REALLY screws up >when tracing code? It seems that it arbitrarily jumps to come code at >times that resembles other code. For example: What I have noticed is the debugger getting confused with reentrant routines. If I am on a statement within proc A, that calls routine B, which happens to call proc A, the debugger's next step is the next line in proc A (The statement following the call to proc B.), but it is the second instance of the call that is now being traced. I suppose that it would be difficult for the debugger to determine that this set of events have taken place. But it is confusing because there's no obvious indication that you are now tracing through another (the second) instance of the routine. Know whadda mean? -- ************************************************************************* Chuck Anderson uucp : uunet!isis!cla Boulder, Co. (303) 494-6278 internet: cla@isis.cs.du.edu *************************************************************************
dgil@pa.reuter.COM (Dave Gillett) (12/12/90)
In <25804@uflorida.cis.ufl.EDU> jdb@reef.cis.ufl.edu (Brian K. W. Hook) writes: >I have Turbo C++ 1.00 but have noticed that it has a couple of errors, ie. >bugs. Has anyone encountered the fact that the debugger REALLY screws up >when tracing code? It seems that it arbitrarily jumps to come code at >times that resembles other code. For example: >....code... >return (0) >.....code.... >return (0) >When it should hit the first return (0) it instead jumps to the other, >completely unrelated, but syntactically similar, piece of code. The debugger works by cross-referencing locations in the source to locations in the machine language. (Use "View CPU" to see this level.) So what happens when the compiler doesn't generate any object code for the source line? The trace and breakpoints get redirected to where the actual code is. In your example, "return (0)" appears twice. This is pretty trivial, but it's not inconceivable that the compiler, as an optimization, generated the code for the second instance and a jump to it for the first instead of two copies of the code. The debugger is torn between stepping through what you wrote, and following the actual path of execution, and has opted for the latter. Dave
spolsky-joel@cs.yale.edu (Joel Spolsky) (12/12/90)
In article <25804@uflorida.cis.ufl.EDU> jdb@reef.cis.ufl.edu (Brian K. W. Hook) writes: >I have Turbo C++ 1.00 but have noticed that it has a couple of errors, ie. >bugs. Has anyone encountered the fact that the debugger REALLY screws up >when tracing code? It seems that it arbitrarily jumps to come code at >times that resembles other code... Hello, That is not a bug. What is happening is that the optimizer is rearranging your code so that it can be made smaller or faster. The debugger, admittedly, gets confused trying to map the binary reality to the source code ideal... When you want to debug, you should just turn off all optimizations. Joel Spolsky spolsky@cs.yale.edu Silence = Death
jdb@reef.cis.ufl.edu (Brian K. W. Hook) (12/13/90)
Okay, I'll say it...I need the number for Borland Tech Support. Could someone please e-mail me the number so I can get my upgrade from 1.00 to 1.01? *sigh*
jdb@reef.cis.ufl.edu (Brian K. W. Hook) (12/18/90)
I am using Turbo C++ 1.00 for my current development. However, I have an excessively large project file (about 26 files, 55K of source) and when I change a single #include that is included by ALL files it will do a build all to keep everything consistent. The question is: Common sense lends one to believe that using TCC would be MUCH faster than recompiling within the environment. If that is the case, is there a way to use my .PRJ file as a response file? I've tried @FILE.PRJ on a whim, and, of course, it didn't work. The only way I can think of is to go into my options windows and write everything down then make a batch file. This is not my idea of fun, especially since a lot of things are already going to be defined in my .TC file and .CFG file. And of course, certain things that it assumes are set are not explicity displayed in the options windows and thus I do not know what switches to set....also, certain thigs set in the .TC file are overridden by my .PRJ file and thus at the command line, certain .TC switches may be used instead of ones in my .PRJ file. THIS GETS VERY CONFUSING AND ANNOYINGH!! ARGH! Anyone know how to handle this in a sane manner? Thanks.... Brian
beoneel@well.sf.ca.us (Bruce O'Neel) (12/21/90)
jdb@reef.cis.ufl.edu (Brian K. W. Hook) writes: >In response to everyone, I have ordered the TC++ patch disk from Borland. >Also, as for the fact that I have only 1 include file, this is because >I am writing a future shareware windowing library and I don't want users >having to worry about multiple include files and what not when and if they >purchse the source code. >Next...does or does not TCC run faster vs. the TC IDE when compiling identical >files? I would assume so, but in e-mail some have disagreed. Actually, you've ordered tc++ 1.01 from borland, right :-) ? TCC faster than TC IDE? Well, yes and no. It is basically the same compiler so the speed difference depends on how much memory you have (regular and EMS) how fast the disk is, and how fast the cpu is. I've found that on my system (Nec v30 8mhz, 640k memory, no ems, quick but not too 20meg disk) if I want to compile 1 file it is faster to use tcc. If I want to edit, compile, edit, compile, etc, the IDE is faster in my experience. Your milage may vary. bruce
dougs@videovax.tv.tek.com (Doug Stevens) (12/22/90)
In article <2261@abcom.ATT.COM>, mdb@abcom.ATT.COM (5013 ) writes: > Have you looked at using make to manage your project?? > At one point Borland was distributing a .PRJ to a .MAK which could then > be used by MAKE. I have used both MAKE with TCC and project-make within TC. The project make appears to be MUCH (much, much ...) faster. I speculate that the main difference is that when running MAKE, TCC must be re-loaded every time that a dependency triggers a compilation, and that TC loads the compiler only once before checking dependencies and compiling. I also prefer the project make because I don't have to maintain dependency lists in the makefile (even with automated tools, such as Polymake, you have to remember to run the tool to update the dependencies). I think the original complaint had to do more with changes in a single .h file triggering compilation in manyh .c files in the system. Changing from TC to make with TCC is not going to fix this (unless you don't add the dependencies into the makefile, in which case you can really generate some confusing problems). My approach is to use lots of .h files, each dealing with a subsystem within the system being created, instead of a single massive .h file; that way, changing a .h only triggers re-compilation in the files in that subsystem.