Bad use of ASSERT...
-
Well I am in the midst of developing a personal project. Now there is a certain control which should be displayed when my application starts up. The type of control is decided at runtime. Debug version all is fine, the control shows up as it should. Release version the control fails to show up. I spent about one week scratching my head as to what was happening. I did not find any trouble with my code. After digging and tracing my code for sometime I found out that the control was not getting created at all in Release version. Further digging of my code led to this statement.
ASSERT( CreateControl() );
The problem was here. Since in non debug versions `ASSERT` expands to nothing. So any statement inside it does not get expanded.I knew thatASSERThad such an issue but still I did this mistake again.So the moral of the story is not to write any assignment or executable code inside `ASSERT` instead in such cases `VERIFY` should be used.
Nibu thomas A Developer Programming tips[^] My site[^]
-
Well I am in the midst of developing a personal project. Now there is a certain control which should be displayed when my application starts up. The type of control is decided at runtime. Debug version all is fine, the control shows up as it should. Release version the control fails to show up. I spent about one week scratching my head as to what was happening. I did not find any trouble with my code. After digging and tracing my code for sometime I found out that the control was not getting created at all in Release version. Further digging of my code led to this statement.
ASSERT( CreateControl() );
The problem was here. Since in non debug versions `ASSERT` expands to nothing. So any statement inside it does not get expanded.I knew thatASSERThad such an issue but still I did this mistake again.So the moral of the story is not to write any assignment or executable code inside `ASSERT` instead in such cases `VERIFY` should be used.
Nibu thomas A Developer Programming tips[^] My site[^]
Nibu babu thomas wrote:
the moral of the story is not to write any assignment or executable code inside ASSERT instead in such cases VERIFY should be used.
Generalization: Never assert an expression with side effects.
-- The Blog: Bits and Pieces
-
Well I am in the midst of developing a personal project. Now there is a certain control which should be displayed when my application starts up. The type of control is decided at runtime. Debug version all is fine, the control shows up as it should. Release version the control fails to show up. I spent about one week scratching my head as to what was happening. I did not find any trouble with my code. After digging and tracing my code for sometime I found out that the control was not getting created at all in Release version. Further digging of my code led to this statement.
ASSERT( CreateControl() );
The problem was here. Since in non debug versions `ASSERT` expands to nothing. So any statement inside it does not get expanded.I knew thatASSERThad such an issue but still I did this mistake again.So the moral of the story is not to write any assignment or executable code inside `ASSERT` instead in such cases `VERIFY` should be used.
Nibu thomas A Developer Programming tips[^] My site[^]
Nibu babu thomas wrote:
So the moral of the story is not to write any assignment or executable code inside ASSERT instead in such cases VERIFY should be used.
Yes, I've used this quite often especially around MFC API UI calls, which often return BOOL for control creation, updates, etc.
Kevin
-
Nibu babu thomas wrote:
So the moral of the story is not to write any assignment or executable code inside ASSERT instead in such cases VERIFY should be used.
Yes, I've used this quite often especially around MFC API UI calls, which often return BOOL for control creation, updates, etc.
Kevin
Kevin McFarlane wrote:
Yes, I've used this quite often especially around MFC API UI calls, which often return BOOL for control creation, updates, etc.
The problem is that people keep looking at the wrong places... I was purely lucky in catching this bug. :phew:
Nibu thomas A Developer Programming tips[^] My site[^]
-
Well I am in the midst of developing a personal project. Now there is a certain control which should be displayed when my application starts up. The type of control is decided at runtime. Debug version all is fine, the control shows up as it should. Release version the control fails to show up. I spent about one week scratching my head as to what was happening. I did not find any trouble with my code. After digging and tracing my code for sometime I found out that the control was not getting created at all in Release version. Further digging of my code led to this statement.
ASSERT( CreateControl() );
The problem was here. Since in non debug versions `ASSERT` expands to nothing. So any statement inside it does not get expanded.I knew thatASSERThad such an issue but still I did this mistake again.So the moral of the story is not to write any assignment or executable code inside `ASSERT` instead in such cases `VERIFY` should be used.
Nibu thomas A Developer Programming tips[^] My site[^]
I know one company that did this, and got away with it because they only shipped debug builds. Talk about clueless.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.
-
I know one company that did this, and got away with it because they only shipped debug builds. Talk about clueless.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.
Pete O`Hanlon wrote:
they only shipped debug builds
:omg: Stunning!
-
Pete O`Hanlon wrote:
they only shipped debug builds
:omg: Stunning!
How do you talk to rocket scientists like that?
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.
-
I know one company that did this, and got away with it because they only shipped debug builds. Talk about clueless.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.
Of course you ship debug builds. Debug builds work, but the stupid compiler does not know how to make release builds. Release builds always crash as soon as they are run. Release builds are just faulty and should never, ever be used.
You may be right
I may be crazy
-- Billy Joel --Within you lies the power for good, use it!!!
-
Of course you ship debug builds. Debug builds work, but the stupid compiler does not know how to make release builds. Release builds always crash as soon as they are run. Release builds are just faulty and should never, ever be used.
You may be right
I may be crazy
-- Billy Joel --Within you lies the power for good, use it!!!
PJ Arends wrote:
Release builds are just faulty and should never, ever be used.
Are you waiting for someone to take this statement serious to start a flame war? ;P Yours, Alois Kraus
-
Of course you ship debug builds. Debug builds work, but the stupid compiler does not know how to make release builds. Release builds always crash as soon as they are run. Release builds are just faulty and should never, ever be used.
You may be right
I may be crazy
-- Billy Joel --Within you lies the power for good, use it!!!
Too true, and how naive I was to expect otherwise.:-D
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.
-
I know one company that did this, and got away with it because they only shipped debug builds. Talk about clueless.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.
i worked at a company that only shipped debug builds.
-
Well I am in the midst of developing a personal project. Now there is a certain control which should be displayed when my application starts up. The type of control is decided at runtime. Debug version all is fine, the control shows up as it should. Release version the control fails to show up. I spent about one week scratching my head as to what was happening. I did not find any trouble with my code. After digging and tracing my code for sometime I found out that the control was not getting created at all in Release version. Further digging of my code led to this statement.
ASSERT( CreateControl() );
The problem was here. Since in non debug versions `ASSERT` expands to nothing. So any statement inside it does not get expanded.I knew thatASSERThad such an issue but still I did this mistake again.So the moral of the story is not to write any assignment or executable code inside `ASSERT` instead in such cases `VERIFY` should be used.
Nibu thomas A Developer Programming tips[^] My site[^]
:wtf: That is not an issue with
assertat all. It is 100% by design. It is also well known that you should never have working code inside of anassert. In fact, it is the most common example used to illustrate the danger of macros in general. The real lesson to be learned from this is to avoid macros! :mad: Replace the assert macro in your code with anassert()function and watch how much performance of the release version is not changed. Also, that allows you to turn on run-timeasserts (with a reg key, etc.) in the release version. Tracing can be handled similarly.Matt Gerrans
-
:wtf: That is not an issue with
assertat all. It is 100% by design. It is also well known that you should never have working code inside of anassert. In fact, it is the most common example used to illustrate the danger of macros in general. The real lesson to be learned from this is to avoid macros! :mad: Replace the assert macro in your code with anassert()function and watch how much performance of the release version is not changed. Also, that allows you to turn on run-timeasserts (with a reg key, etc.) in the release version. Tracing can be handled similarly.Matt Gerrans
Matt Gerrans wrote:
That is not an issue with assert at all. It is 100% by design.
Exactly, the title says so...
"Bad Use of Assert...".It doesn't sayASSERTis bad.Matt Gerrans wrote:
It is also well known that you should never have working code inside of an assert.
True. But sometimes you know that you won't do it but still you do it. Since you know that you won't do it hence you won't look there. That's what happened with me. I couldn't believe that I did this...:doh::sigh::doh:
Matt Gerrans wrote:
The real lesson to be learned from this is to avoid macros!
This is not true. These bugs happens due to carelessness. Macros are for a purpose and they satisfy that purpose well. Any other use leads to disaster.
Matt Gerrans wrote:
Also, that allows you to turn on run-time asserts (with a reg key, etc.) in the release version. Tracing can be handled similarly.
Thanks for this info. :)
Nibu thomas A Developer Programming tips[^] My site[^]
-
i worked at a company that only shipped debug builds.
Chris Losinger wrote:
i worked at a company that only shipped debug builds.
I am working with a company that only ships Release builds.
Nibu thomas A Developer Programming tips[^] My site[^]
-
Nibu babu thomas wrote:
the moral of the story is not to write any assignment or executable code inside ASSERT instead in such cases VERIFY should be used.
Generalization: Never assert an expression with side effects.
-- The Blog: Bits and Pieces
Don't assert logic?
On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Charles Babbage
-
Don't assert logic?
On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Charles Babbage
No, I don't consider the value of an assertable expression to be a side effect, if that's what you mean. The side effect obviously occurs when the state of one or more inputs to the expression have changed when the expression was evaluated.
-- The Blog: Bits and Pieces
-
Well I am in the midst of developing a personal project. Now there is a certain control which should be displayed when my application starts up. The type of control is decided at runtime. Debug version all is fine, the control shows up as it should. Release version the control fails to show up. I spent about one week scratching my head as to what was happening. I did not find any trouble with my code. After digging and tracing my code for sometime I found out that the control was not getting created at all in Release version. Further digging of my code led to this statement.
ASSERT( CreateControl() );
The problem was here. Since in non debug versions `ASSERT` expands to nothing. So any statement inside it does not get expanded.I knew thatASSERThad such an issue but still I did this mistake again.So the moral of the story is not to write any assignment or executable code inside `ASSERT` instead in such cases `VERIFY` should be used.
Nibu thomas A Developer Programming tips[^] My site[^]
Nibu - did that once... *once*, will never do it again. It's like writing if (i = 1) { }; You learn to look for these things....
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. My son's PDA is an M249 SAW. My other son commutes in an M1A2 Abrams
-
Well I am in the midst of developing a personal project. Now there is a certain control which should be displayed when my application starts up. The type of control is decided at runtime. Debug version all is fine, the control shows up as it should. Release version the control fails to show up. I spent about one week scratching my head as to what was happening. I did not find any trouble with my code. After digging and tracing my code for sometime I found out that the control was not getting created at all in Release version. Further digging of my code led to this statement.
ASSERT( CreateControl() );
The problem was here. Since in non debug versions `ASSERT` expands to nothing. So any statement inside it does not get expanded.I knew thatASSERThad such an issue but still I did this mistake again.So the moral of the story is not to write any assignment or executable code inside `ASSERT` instead in such cases `VERIFY` should be used.
Nibu thomas A Developer Programming tips[^] My site[^]
-
Well I am in the midst of developing a personal project. Now there is a certain control which should be displayed when my application starts up. The type of control is decided at runtime. Debug version all is fine, the control shows up as it should. Release version the control fails to show up. I spent about one week scratching my head as to what was happening. I did not find any trouble with my code. After digging and tracing my code for sometime I found out that the control was not getting created at all in Release version. Further digging of my code led to this statement.
ASSERT( CreateControl() );
The problem was here. Since in non debug versions `ASSERT` expands to nothing. So any statement inside it does not get expanded.I knew thatASSERThad such an issue but still I did this mistake again.So the moral of the story is not to write any assignment or executable code inside `ASSERT` instead in such cases `VERIFY` should be used.
Nibu thomas A Developer Programming tips[^] My site[^]
Can I suggest you look up VERIFY?
VERIFY(CreateControl());This will do the same as assert in debug builds, but in release builds will compile to:CreateControl();Which gives you the best of both worlds. -
Can I suggest you look up VERIFY?
VERIFY(CreateControl());This will do the same as assert in debug builds, but in release builds will compile to:CreateControl();Which gives you the best of both worlds.Soundman32.2 wrote:
Can I suggest you look up VERIFY? VERIFY(CreateControl()); This will do the same as assert in debug builds, but in release builds will compile to: CreateControl(); Which gives you the best of both worlds.
Yeah I've already mentioned that towards the end of my message. Thanks. :) :)
Nibu thomas A Developer Programming tips[^] My site[^]
