From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8c54bb73b6fd8d22 X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-96" Subject: Re: GDB Woes Continued... Date: 1998/02/02 Message-ID: <98020216364905@psavax.pwfl.com>#1/1 X-Deja-AN: 322087620 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU X-VMS-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" X-VMS-Cc: CONDIC Newsgroups: comp.lang.ada Date: 1998-02-02T00:00:00+00:00 List-Id: Robert Dewar writes: >However, to explain my comment above. I continue to think that most people >greatly overuse debuggers. It is much better to write error-free code in >the first place, and if you do have errors, to think about what is wrong, >and fix it, rather than spending ages in a debugger looking arond. > This is very true for most types of "workstation-ish" programs. In most of the things I've built using Gnat on a Sun platform, I've found very little use for a debugger because you can usually bench check the code to be mostly error free from the beginning. (At least for the kinds of errors most commonly found with a debugger. If the program executes, but doesn't perform the task correctly because you've messed up a requirement somewhere, the debugger is going to be of little value.) Bench checking for routine errors also invariably leads to: "Gee! That's not supposed to be here..." sorts of discoveries which tend to minimize the fundamental flaws you don't see when checking for superficial flaws with a debugger. My experience is that the more clear you are about what a program or piece of a program is supposed to do, the more likely you are to get it right the first time. Some folks can do this in their heads up front - sometimes it has to come from more formal methods. But either way, if you understand it thoroughly, you tend to write clear, direct, to-the-point code which doesn't need to be debugged. Although I don't use gdb that much, I still think it's handy - especially when you end up with an error during elaboration & don't get a traceback to know what module caused the trouble. Gdb is pretty good at filling that gap. I'd have to agree that there is a bit of a dearth of good documentation, but with what's available that I've seen, you can get it to work. >We have certainly found NT to be much more reliable than Win95, and most >of our customers using the NT/WIn95 version of GNAT are indeed using NT. >GDB itself has always been more stable under NT (the delay in releasing >it was solely because of the Win95 problems, since we realize that users >of the public version are more likely NOT to be serious developers and to >be fiddling with Win95). > I've driven Win95 around a bit on laptops and other platforms and my experience is that it is a pretty pathetic attempt to label something an operating system. I've never had much trouble getting Win95 to crash - even using Micro$oft's own software. Granted, my experience is limited - a little like my experience with sitting on hot stoves, or poking sharp objects into my eyes. Maybe you get used to it after a while. WinNT has performed for me quite reliably. I've occasionally had some applications go casters-up, but they have never taken down the whole system. For any sort of serious development I'd find WinNT the right way to go.... with a single caveat: From what I've been able to determine, you can't really use WinNT successfully for real time work if by "real time" you mean cycle times under 20 milliseconds. (O.K., maybe if WinNT doesn't have to drive anything but your app, you can make things predictable. But if the machine runs your app and may also be called on to run other apps, you have some real problems with guaranteeing latencies such as responding to interrupts.) For some of these apps, you might be better off working with an MS-DOS environment, because you can pretty much move MS-DOS out of your way and guarantee response based on the bare hardware. And for real time (embedded) apps you'll find me changing my tune entirely about debuggers because this is usually the only visibility you have into what the software is doing. So much so that we build our lab tests for embedded boxes around a home grown debugger. MDC Marin David Condic, Senior Computer Engineer Voice: 561.796.8997 Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600 Fax: 561.796.4669 West Palm Beach, FL, 33410-9600 Internet: CONDICMA@PWFL.COM ============================================================================= "Languages don't kill people. *Programmers* do!" -- Rich Stewart - Language Lawyer & Language Control Opponent. =============================================================================