Jan Knepper wrote:

> Paul McKenzie wrote:
> 
> 
>>Nic Tiger wrote:
>>
>>>As for debugger, my opinion is: it is usefult for novices, for those who
>>>want to understand how (particular) compiler works or for fighting minor
>>>bugs.
>>>For anything else it is useless.
>>
>>A debugger is useless?  Tell that to the thousands of software
>>professionals that rely on debuggers to solve complex problems and issues.
> 
> 
> "Software Professionals" should know that using a debugger requires things as
> optimization  to be turned off. It also requires extra data to be added to the
> executable for the debugger to work with and have a reference to the source
> code.
> 
> These things more often than not happen to cover up serious problems as
> not-intialized pointers, not-initialized data and quite a few more with the
> cute result that a program runs fine in the debugger, but seriously fails in
> release versions.
> 

This is not true for today's Windows debuggers, especially the one that comes with Visual C++.  All you need to do is to build a release version with debugging information turned on in the compiler and linker.  You *are* getting a release version, with the added benefit that you can run the program under the debugger.

Paul McKenzie

> This is not true for today's Windows debuggers, especially the one that comes with Visual C++.  All you need to do is to build a release version with debugging information turned on in the compiler and linker.  You *are* getting a release version, with the added benefit that you can run the program under the debugger.

If this were TRULY the case you would get an assembler display while debugging. If you get the sources you do not REALLY have a RELEASE version.

I would suggest you study a few more things on debug/release and other modes.

--
ManiaC++
Jan Knepper

"Jan Knepper" <jan@smartsoft.us> wrote in message
news:3F331A3A.64EAABF5@smartsoft.us...
| > This is not true for today's Windows debuggers, especially the one that
| > comes with Visual C++.  All you need to do is to build a release version
| > with debugging information turned on in the compiler and linker.  You
| > *are* getting a release version, with the added benefit that you can run
| > the program under the debugger.

I don't really agree with that statement. Isn't the term "Release Version" synonymous with "Build lacking symbols/etc"? If you are doing that then you are just making a debug-enabled version, which defeats the purpose of it being a commercial release.

> "Jan Knepper" <jan@smartsoft.us> wrote in message
> news:3F331A3A.64EAABF5@smartsoft.us...
> | > This is not true for today's Windows debuggers, especially the one
that
> | > comes with Visual C++.  All you need to do is to build a release
version
> | > with debugging information turned on in the compiler and linker.  You | > *are* getting a release version, with the added benefit that you can
run
> | > the program under the debugger.
>
> I don't really agree with that statement. Isn't the term "Release Version" synonymous with "Build lacking symbols/etc"? If you are doing that then
you
> are just making a debug-enabled version, which defeats the purpose of it being a commercial release.

I'm having a hard time with this conv, since it seems that positions are being argued out of conviction than common-sense. And by such smart folks too !?!

A release build is whatever you release to your clients. If it's got debug symbols in it, that's ok, you've chosen to help yourself should your product crash. You've also reduced the likelihood of experiencing a release-only crash, which (along with its pervese sibling the debug-only crash) is a total PITA to fix. If it is appropriate to your deployment circumstances, then this is a good thing to do,

Using a debugger marks you out as neither hopelessly reliant on a mental crutch for GUI cissys, nor terribly more modern than those sad cmd-line stuck-in-the-80s UNIX die-hards. It's horses for courses.

Debuggers are great for learning about code. Debuggers can be integral to the development of a non-trivial quality product.

Debuggers can get in the way of what's really happening. Debuggers can actually be impossible to use in certain circumstances.

If you're developing a complex GUI a debugger is good, except where menus
are concerned, in which case you'll have to use lots of tracing.
If you're developing shell extensions, a debugger is very useful, but it can
be a real pain to keep killing Explorer.exe (esp on WinNT 4)
If you're developing a server using IO Completion Ports, a debugger is
completely useless.
If you're trying to fix a bug in your prematurely released template library
component, then a debugger is almost mandatory

Basically, like everything else in SW, it depends. Let's have a good debugger for DMC++ (and DMD!!), and let's also have language support and develop skills that facilitate debugging the "old" way, i.e. tracing/logs

The Grinch that ate C++

"Matthew Wilson" <matthew@stlsoft.org> wrote in message
news:bgvg6k$1vgt$1@digitaldaemon.com...
| A release build is whatever you release to your clients. If it's got debug
| symbols in it, that's ok, you've chosen to help yourself should your
product
| crash. You've also reduced the likelihood of experiencing a release-only
| crash, which (along with its pervese sibling the debug-only crash) is a
| total PITA to fix. If it is appropriate to your deployment circumstances,
| then this is a good thing to do,

This is true. But what about products that have been fully tested (such as commercial games). In cases where a problem may occur, wouldn't a simple static assert be applied rather than increasing the executable size of your application? Why should my new Advanced Dungeons and Dragons tag an extra couple MB to the exe when I have no way to debug it myself (minus assembly steps)?

"Greg Peet" <admin@gregpeet.com> wrote in message news:bgvjgc$233o$1@digitaldaemon.com...
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message
> news:bgvg6k$1vgt$1@digitaldaemon.com...
> | A release build is whatever you release to your clients. If it's got
debug
> | symbols in it, that's ok, you've chosen to help yourself should your
> product
> | crash. You've also reduced the likelihood of experiencing a release-only
> | crash, which (along with its pervese sibling the debug-only crash) is a
> | total PITA to fix. If it is appropriate to your deployment
circumstances,
> | then this is a good thing to do,
>
> This is true. But what about products that have been fully tested (such as commercial games). In cases where a problem may occur, wouldn't a simple static assert be applied rather than increasing the executable size of
your
> application? Why should my new Advanced Dungeons and Dragons tag an extra couple MB to the exe when I have no way to debug it myself (minus assembly steps)?

It shouldn't. I wasn't saying that all released code should have debug info included; far from it. Just that some do. As I said, it all depends. I don't release debug info in the shell extensions (http://shellext.com/) because it is important that they are small, and - inviting bug reports by the 1000s - they have proved sufficiently robust that they don't need it. When I ship serious pieces of kit, and they are fat GUIs anyway, then I often do ship debug info.

Case-by-case, mi auld mucker!

Jan Knepper wrote:
> 
> If this were TRULY the case you would get an assembler display while debugging. If
> you get the sources you do not REALLY have a RELEASE version.
> 

I am strictly talking about "debugging a release version".  Of course you don't ship a version with debug symbols, but a release version with debug symbols is no different, in terms of execution, than a release version without debug symbols.

Please go to the page below and scroll down to "Turn on Symbols".  It shows exactly how to accomplish what I'm trying to convey to you.

http://www.codeproject.com/debug/survivereleasever.asp

> I would suggest you study a few more things on debug/release and other modes.

After programming for 23 years, and currently developing and maintaining commercial software, I am well-versed in release and debug modes, thank you.

Paul McKenzie

Greg Peet wrote:

> "Jan Knepper" <jan@smartsoft.us> wrote in message
> news:3F331A3A.64EAABF5@smartsoft.us...
> | > This is not true for today's Windows debuggers, especially the one that
> | > comes with Visual C++.  All you need to do is to build a release version
> | > with debugging information turned on in the compiler and linker.  You
> | > *are* getting a release version, with the added benefit that you can run
> | > the program under the debugger.
> 
> I don't really agree with that statement. Isn't the term "Release Version"
> synonymous with "Build lacking symbols/etc"? If you are doing that then you
> are just making a debug-enabled version, which defeats the purpose of it
> being a commercial release.
> 
> 

I believe that my original words have been twisted into "it's OK to distribute your commercial products with debug information".

What I'm trying to say is that you can debug a release version of your software, if you use a compiler/linker that supports this (VC++ does). The release version with debug symbols will run *no differently* than a release version without debug symbols.  It is not going to suffer from "the debug build initializing variables automatically" or the "guard bytes around allocated areas" that "real debug" versions do.

For the VC++ compilers, the real "debug version" (for lack of a better term) *does* auto-initialze variables to NULL or 0, put extra checks in for memory corruption, etc.  However, the "release" versions, which do not do these checks, can also be debugged, just like the "debug" version by turning on the symbol generation for the release build.

Paul McKenzie

Matthew Wilson wrote:

> I'm having a hard time with this conv, since it seems that positions are
> being argued out of conviction than common-sense. And by such smart folks
> too !?!
> 
> A release build is whatever you release to your clients. If it's got debug
> symbols in it, that's ok, you've chosen to help yourself should your product
> crash. You've also reduced the likelihood of experiencing a release-only
> crash, which (along with its pervese sibling the debug-only crash) is a
> total PITA to fix. If it is appropriate to your deployment circumstances,
> then this is a good thing to do,
> 

If you ever have the opportunity to do remote debugging to a client site running your software, the release build with symbols is a must.

> Debuggers can get in the way of what's really happening. Debuggers can
> actually be impossible to use in certain circumstances.
> 
> If you're developing a complex GUI a debugger is good, except where menus
> are concerned, in which case you'll have to use lots of tracing.
> If you're developing shell extensions, a debugger is very useful, but it can
> be a real pain to keep killing Explorer.exe (esp on WinNT 4)
> If you're developing a server using IO Completion Ports, a debugger is
> completely useless.

In that case, you have log files and tracing.  There are multiple ways to attack a problem, depending on the type of problem you're trying to solve.  A debugger is somewhat useless if you're trying to debug a multi-thread issue.  However, I initially got into this discussion when I felt that the debugger is being dismissed by some (or at least one here) as a tool for incompetent, beginner, or lazy programmers.

Paul McKenzie

"Paul McKenzie" <paul@paul.net> wrote in message news:bh0ov7$4kd$1@digitaldaemon.com...
> After programming for 23 years, and currently developing and maintaining commercial software, I am well-versed in release and debug modes, thank
you.

You must be almost as ancient as I <g>.