Walter wrote:

> "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>.
> 
> 

I started young :)

Paul McKenzie

Paul,

A very simple example like this:

char    str [ 2 ];

for ( int  i = 0 ; i < 3 ; ++i )
   *( str + i ) = 'A' + i;

Could fail in a true optimized release build and work fine in a release build with debugging info and in a bug version.

If your release build with debug info would optimize there is change that you would not see this loop at all, but rather:

*( str + 0 ) = 'A';
*( str + 1 ) = 'B';
*( str + 2 ) = 'C';

It would be pretty difficult for a debugger to refer to a line of code that ain't there anymore...

> 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.

I still contest that although M$'s C-- compiler might not truely optimize and for that reason indeed generate the same code. Other... There very well might be serious difference...

> 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

No time to do that...
I am currently working on stuff were there is also no debugger available...
Besides, I try not to promote or use M$ software any more than I have to. ;-)

> > 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.

Well, I am almost as ancient with about 18 years...

I have developed and maintained commercial software for the last 18 years or so.

A couple of those product are freely available...

http://www.currency-calculator.net/
Download it for free @
ftp://ftp.currency-calculator.net/free/CUCAStdIS.exe

http://www.imagener.com/
Download it for free @
http://www.imagener.com/Download.html

Both of them build without using a debugger... ;-)


--
ManiaC++
Jan Knepper

Jan Knepper wrote:

> It would be pretty difficult for a debugger to refer to a line of code that ain't there anymore...
> 

Yes.  This is the disadvantage of debugging optimized code.  No argument there.

>> 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.
> 
> I still contest that although M$'s C-- compiler might not truely optimize and for that reason indeed generate the same code. Other... There very well might be serious difference...
> 

I've never run into any differences.  Everything is the same (at least with my experience) if you add symbols or not.  If it crashes in the release without symbols and optimization on, it will crash in the release with the symbols and optimization on in the same area of code (of course, given that the input to the program is the same for both versions, and you run both versions on the same machine)

>> 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
>>
> No time to do that...
> I am currently working on stuff were there is also no debugger available...
> Besides, I try not to promote or use M$ software any more than I have to. ;-)
> 

Yes, I understand.  I've had to do that with older compilers that can compile my code, but cannot use a debugger due to the large library sizes that are generated.

I'm no Microsoft promoter by any means (I'm mad as heck at VC++ 6.0 for not supporting member templates) -- I just wanted to bring up how MS accomplishes debugging.  Since 32-bit VC++, MS stores the debug info in PDB (Program Database) files and not the executable.  By storing all the debug information in seperate files, the "real" EXE stays intact with next to no extra information (a stub is added to the EXE, telling where the path of the PDB file is located).  Maybe Walter has thought of this type of a setup if he or someone else plans to upgrade the DMC debugger.

> I have developed and maintained commercial software for the last 18 years or so.
> 
> A couple of those product are freely available...
> 
> http://www.currency-calculator.net/
> Download it for free @
> ftp://ftp.currency-calculator.net/free/CUCAStdIS.exe
> 
> http://www.imagener.com/
> Download it for free @
> http://www.imagener.com/Download.html
> 
> Both of them build without using a debugger... ;-)
>  

Walter's "Related Sites" page at www.digitalmars.com/related.html lists one of my products (DTWAIN).  And yes, a debugger was used, but mostly to debug what a non-compliant TWAIN drivers is doing wrong :)

Paul McKenzie

"Paul McKenzie" <paul@paul.net> wrote in message news:bh0qc7$5pv$1@digitaldaemon.com...
> 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".

They probably have. When you get three shy bashful types like Jan, Greg and me, that's all too probable ... ;)

> 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.

This is practically true in most cases, but as you'll no doubt agree, it is not theoretically correct. Different memory footprint !== identical execution.

> 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.

AFAIK, no-one's disputing this. I'm certainly not.

"Paul McKenzie" <paul@paul.net> wrote in message news:bh0rdt$6pc$1@digitaldaemon.com...
> 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.

Indeed. This is the point we all agree on.

> 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.

I think your interpretation was well-founded, and I agree with your contending the point.

Horses for courses dear chaps!

> Paul McKenzie
>

"Walter" <walter@digitalmars.com> wrote in message news:bh0sdu$899$1@digitaldaemon.com...
>
> "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>.

You guys are babies. I've just been blown away by the wisdom and switched-on-ness of Robert L Glass, and he's 71. Rock on Rob!!

"Paul McKenzie" <paul@paul.net> wrote in message news:bh0std$8m1$1@digitaldaemon.com...
> Walter wrote:
>
> > "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>.
> >
> >
>
> I started young :)

Ah, if we count teen-stuff, then you can include me as a 23-year vet. Sigh ...

> Walter's "Related Sites" page at www.digitalmars.com/related.html lists one of my products (DTWAIN).  And yes, a debugger was used, but mostly to debug what a non-compliant TWAIN drivers is doing wrong :)

Hey Walter,

Can you link in http://shellext.com in related sites. Some of these were built with a debugger, and some not. ;)

"Matthew Wilson" <matthew@stlsoft.org> wrote in message
news:bh14bg$fom$1@digitaldaemon.com...
| > I believe that my original words have been twisted into "it's OK to
| > distribute your commercial products with debug information".
|
| They probably have. When you get three shy bashful types like Jan, Greg
and
| me, that's all too probable ... ;)

Yup I misinterpreted your words. Sorry about that. I have been reading a thread in comp.unix.programmer regarding this topic and figured I could make the same argument here...to save me words =P

"Matthew Wilson" <matthew@stlsoft.org> wrote in message
news:bh14is$g2q$1@digitaldaemon.com...
| > > You must be almost as ancient as I <g>.
| > >
| > >
| >
| > I started young :)
|
| Ah, if we count teen-stuff, then you can include me as a 23-year vet. Sigh
Bah, I'm a young-un then. no fun =(