wpw_tool_vcpp_95.html

VC programing

>different effects when the memory image changes, but I am quite certain that is not the case
>here.
>
>I believe this is a compiler bug that only occurs once you think
>you've finished your testing and re-compile in release mode. 
>
>       
>       silly_1 = date_1.GetDay();
>       silly_2 = date_2.GetDay();
>       if (silly_1 != silly_2) {
>               sprintf(msg, "Method 2: Obviously the dates are different\n");
>       }
>       else {
>               sprintf(msg, "Method 2: MICROSOFT SAYS THE DATES ARE THE SAME!!!\n");
>       }
>       OutputDebugString(msg);
>}
>
>======================================================================================
>Max Davies - Software Specialist 
>Open Universal Software, Montreal CANADA
>[e-mail]

I had an almost identical problem in an On Command Update routine:

   pCmdUI->Enable (date_1.GetYear() < date_2.GetYear());
  
which always disabled the menu item in the release version, not in the
debug version. If I used the silly_1 and silly_2 variables, it worked fine.
-- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joern Yngve Dahl-Stamnes, The University of Trondheim, Norway   |
| e-mail: [e-mail]                         | 
| phone : [phone], fax: [phone]                         |
| Surfing the net? Try http://www.fysel.unit.no/dahls/dahls.html  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<HR>

[e-mail] (Max Davies) writes:


> In Visual C++ 1.51 the following code snippet works perfectly when
> compiled in DEBUG mode, but misbehaves (without warning) when
> re-compiled in RELEASE mode.

> I realize that most such discrepencies are caused by programming
> errors that simply have different effects when the memory image
> changes, but I am quite certain that is not the case here.

> I believe this is a compiler bug that only occurs once you think
> you've finished your testing and re-compile in release mode.

Looks like you're right. Have you looked at the generated code?  It
would be nice to know whether the error is caused by optimisations or
by errors in the RELEASE libraries?  What happens if you turn off all
optimisations in the release mode version? if it works with that, turn
them on one by one to determine exactly which optimization7combination
of optimisations cause these error.  This will enable you to turn them
off in the relevant function using #pragma optimize(...).

Not a solution, but a work-around :-(. And file a bug report with MS
if this isn't already in the KB.

-- 
   Niels Ull Jacobsen, Dep. of CS, U of Copenhagen ([e-mail])
   Roenne Alle 3 st.th, 2860 Soeborg, Denmark, tel. [phone]
<HR>

In article <[e-mail]>, [e-mail] says...
>In article <[e-mail]> [e-mail] "Max Davies" writes:
>>In Visual C++ 1.51 the following code snippet works perfectly when compiled 
in
>>DEBUG mode, but misbehaves (without warning) when re-compiled in RELEASE 
mode.
[...]
>I also had a related problem. One of my program is built in release mode.
>It runs in one computer OK, but suddenly became a mess when I loaded in
>another computer. Again, I wasn't able to track it down, as I can't 
>reproduce the problem.
>
>Does anyone else have the same experience?

Yes, I have, and on several platforms.  The conclusion I've come to just about 
every time I've taken the time and tracked it down has been "programmer error" 
on my part.  The reasons something works in debug mode but not release mode are 
many and varied.  Sometimes a trivial change, reordering of variables, change 
of 'static'/'auto'/'extern' or compiler option will get something working (or 
vice versa)... generally due to rearranging placement or size of data 
structures in memory - one thing being stomped on versus something else.

Compiler and/or linker problems occur but they are rare compared to bugs in my 
own (and everybody else's) code.
-- 
Harvey Brydon         Internet: [e-mail]
Schlumberger Dowell   Phone:    [phone]

<HR>
In article <3s68bu$[e-mail]>,
Harvey Brydon <[e-mail]> wrote:
>In article <[e-mail]>, [e-mail] says...
>>In article <[e-mail]> [e-mail] "Max Davies" writes:
>>>In Visual C++ 1.51 the following code snippet works perfectly when compiled 
>in
>>>DEBUG mode, but misbehaves (without warning) when re-compiled in RELEASE 
>mode.
>[...]
>>I also had a related problem. One of my program is built in release mode.
>>It runs in one computer OK, but suddenly became a mess when I loaded in
>>another computer. Again, I wasn't able to track it down, as I can't 
>>reproduce the problem.
>>
>>Does anyone else have the same experience?
>
>Yes, I have, and on several platforms.  The conclusion I've come to just about 
>every time I've taken the time and tracked it down has been "programmer error" 
>on my part.  The reasons something works in debug mode but not release mode are 
>many and varied.  Sometimes a trivial change, reordering of variables, change 
>of 'static'/'auto'/'extern' or compiler option will get something working (or 
>vice versa)... generally due to rearranging placement or size of data 
>structures in memory - one thing being stomped on versus something else.
>
>Compiler and/or linker problems occur but they are rare compared to bugs in my 
>own (and everybody else's) code.
>-- 
>Harvey Brydon         Internet: [e-mail]
>Schlumberger Dowell   Phone:    [phone]
>

something to watch out for: the ASSERT(...) macro. i foolishly assumed this
was analogous to the C ``assert(...)'' macro. IT IS NOT!!! in standard `c',
the release version simply executes code within the assert, in MSVC,
anything in ASSERT(...) GOES AWAY.
  sorry, this caused much heartache.

i've also seen the optimizer code. don't use it. evil evil evil. turn all
optimization off when compiling for release. allow inlineing (at your own
risk)

--kyle

<HR>
just my 2c:
  (1) watch the ASSERT(...) macro. i assumed this is analagous to the
      normal assert(...) in C. it's not. the analogous macro is
      VERIFY(...). this caused a <<major>> headache since the visual
      C environ. doesn't allow multi-file replace :(
  (2) DO NOT USE THE OPTIMIZER!!! this has been a problem with m/s
      since the earliest versions of C (i remember C 6.0 was especially
      bad).

best o' luck
---kyle
<HR>
[e-mail] (Andrea Gambirasio) wrote:
>I'm writing a DLL with MSVC using MFC.
>Compiling it in DEBUG mode is OK, when I compile in release, sometimes it 
>crashes.
>I smell it is a pointer problem (far, near,...) but I cannot say more: I'm m 
>using the following options:
>
>DEBUG CL options
>/G2 /W4 /Zi /ALw /Od /D "_DEBUG" /D "_USRDLL" /GD /Fd"FME.PDB"
>RELEASE CL options
>/G2 /W4 /Zi /ALw /Od /D "NDEBUG" /D "_USRDLL" /GD /Fd"FME.PDB"
> and they look pretty much the same.
>Has anyone experienced this problem?
>

You haven't mentioned whether or not you also use ASSERT() and VERIFY().  
A very common mistake is using an ASSERT() when you should be using 
VERIFY().  Remember that ASSERT(), in RELEASE mode, will turn into a NOP 
(NULL operation) during a RELEASE build, whereas VERIFY() will continue 
to evaluate the expression, but will not cause a warning in the release 
build.

-- 
=========================================================================
=
May the FORCE be with you...

    Al Cilcius                    Internet:   [e-mail]
    3rd Sigma Software, Inc.      Voice:      [phone]
    1338 Hooksett Road            FAX:        [phone]
    Suite 125                     CompuServe: 70322,2343
    Hooksett, NH  03106-1842
=========================================================================
=
<HR>
[e-mail] (Kyle Anthony York) wrote:
>
>just my 2c:
>  (1) watch the ASSERT(...) macro. i assumed this is analagous to the
>      normal assert(...) in C. it's not. the analogous macro is
>      VERIFY(...). this caused a <<major>> headache since the visual
>      C environ. doesn't allow multi-file replace :(

The difference is that in the "release" mode ASSERT disappears entirely 
while VERIFY still evaluates the expression.  You only want to use VERIFY
for expressions with side effects, where you need the side effects to
happen in both cases; but that's not good practice anyway.  Instead of:
       VERIFY(myFile = fopen(...));
use    myFile = fopen(...);
       ASSERT(myfile);
(not the best of examples, but you get the point).


>  (2) DO NOT USE THE OPTIMIZER!!! this has been a problem with m/s
>      since the earliest versions of C (i remember C 6.0 was especially
>      bad).

The optimizer is now a whole bunch of individually-settable options that
work quite well.  But it's a good point to check.  When building release
versions, the optimizer is on by default.  The first thing I did was turn
it off and rebuild, but that didn't help.  In fact, I changed *all* of
the switches in the release version to match the debug version, except
for the _DEBUG symbol itself, with no effect on my bug.  That's what led
me into investigating operator new.

>
>best o' luck
>---kyle
>


--Jeremy

Jeremy H. Griffith  *  [e-mail]  *  Voice: 707-876-3412
Fax: [phone]  * Snail: PO Box 244, Valley Ford, CA 94972
</PRE>


<HR><A NAME=TOOL_MSVC_LIB_INFO>
Return to <a href="wpw_tool_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Find info for Link Library</H4><PRE>
Some of the Windows API in MFVC++2.0 is in separate DLLs
and assorted .LIBs have to be linked explicitly to use them.

So far I have fallen foul of the Multimedia library and the
VERSIONINFO routines.  I've found the libraries by trial and error
so far - I can't find a thing about it in the books on line or the
other parts of the help system.

Does anyone know where this is documented (in the on-line stuff
that comes with C++2.0)?

Dave
-- 
+---------------------------+-----------------------------------+
| Dave Webber                        [e-mail]   |
| Author of MOZART, the Windows 3.1 shareware Music Processor   |
| and member of the Association of Shareware Professionals      |
+---------------------------+-----------------------------------+

<HR>
David Webber <[e-mail]> writes:

>Some of the Windows API in MFVC++2.0 is in separate DLLs
>and assorted .LIBs have to be linked explicitly to use them.

>So far I have fallen foul of the Multimedia library and the
>VERSIONINFO routines.  I've found the libraries by trial and error
>so far - I can't find a thing about it in the books on line or the
>other parts of the help system.

>Does anyone know where this is documented (in the on-line stuff
>that comes with C++2.0)?

>Dave

Please look at the WIN32API.CSV file in \MSVC20\LIB.

.B ekiM
</PRE> 

</HTML>