Post by Oliver Regenfelder
Post by Girish
First I need to say thanks for every one for proving your ideas.
I got the solution for the problem which i was facing.
by setting the below variables to 0
#define _HAS_ITERATOR_DEBUGGING 0
#define _SECURE_SCL 0
after define this we can remove the below code and build the
application with out any error or any crash.
#define new DEBUG_NEW
static char THIS_FILE = __FILE__;
So you solved it by removing certain debug and error checks!?
In an (in)famous incident, the story goes, a torpedo was made "safe" by the following
One on the serious dangers to a submarine is having its own torpedo loop back and acquire
its sending submarine as a target. So a "safe" torpedo was created that had an inertial
platform, and if the torpedo every executed a 180-degree turn it would detonate.
During the testing, a torpedo with a small dummy warhead was taken out on trial. Due to
some mechanical failure in the torpedo tube, the torpedo jammed in the tube. After
several attempts to dislodge it, the submarine turned to head back to port.
Also, while the torpedo had not launched, its safety systems were activated. The torpedo
did as it was supposed to, and exploded.
Because the warhead was a small dummy load, it did not destroy the submarine, but caused
several million dollars in damage.
This taught the torpedo designers a lesson. The next torpedo had a LOT of safety software
in it. They took it out on trial. They fired it. As soon as it left the tube, all the
safety software enabled (no detonation in the tube) but what happened was the motor then
stopped and torpedo sank to the bottom of the ocean.
Moral: removing safety code is bad; putting in too much is worse.
Unfortunately, the way this was solved was simply by removing more and more safety code
until the torpedo actually appeared to work. Very little effort was expended in
determining if the safety code that was removed compromised ACTUAL safety. Sort of a
hack-and-try approach was used. It was then that some of the world's experits in software
safety were called in to do a review of the software. They were appalled at what they
found, but because of National Security Considerations can neither disclose what they
found nor discuss what they did to correct it. So the story above is pretty much all they
can give (I learned this from one of the software safety experts, at a conference on
Does anyone remember "Diamond" brand graphics cards? A few of us had them, but Diamond,
to make performance goals, got rid of a lot of code that contributed nothing to the
performance, such as bounds checking, parameter validation, etc., This is approximately
the phone call I had with them:
"...and every time I zoom into a slide in PowerPoint, Windows bluescreens"
"Well sir, do you have the latest build of the driver?"
"Yes, I downloaded it today."
"What timestmp does it have?"
<<Pause while I bring up the file manager and look at the timestamp>>
"[A little after 10am] today"
"Then you don't have the latest build. You need the 2pm release"
Shortly after that, I went out and bought a different brand of card. Diamond Video
shortly thereafter went out of business, because no one EVER bought a second card from
them, and those who paid attention to the newsgroups in which it was discussed never
bought a first card from them (lucky users!)
You need really good reasons for disabling safety code. Only if your torpedo sinks
immediately after launch is this justified. And then, it must be done with care. It is
more important to find out why you are getting failures than to just disable the safety
code and hope nothing goes wrong.
Joseph M. Newcomer [MVP]
MVP Tips: http://www.flounder.com/mvp_tips.htm