Bugs in translating code
-
The last my task was to translate code from Delphi to c++. Here is the worst bug: if you have Delphi code
if (count = 1) { ... }In c++ you must replace it withif (count == 1) { ... }else you'll got assignment in condition. But if you write constant first the compiler alert you if you leave "=" uncanged :if (1 = count)// Compiler error { ... }This trick helps me a lot.My english is not so good. Please, correct my errors. Best regards, Alexey.
-
The last my task was to translate code from Delphi to c++. Here is the worst bug: if you have Delphi code
if (count = 1) { ... }In c++ you must replace it withif (count == 1) { ... }else you'll got assignment in condition. But if you write constant first the compiler alert you if you leave "=" uncanged :if (1 = count)// Compiler error { ... }This trick helps me a lot.My english is not so good. Please, correct my errors. Best regards, Alexey.
This is also applicable for "!="
-Sarath_._ "Great hopes make everything great possible" - Benjamin Franklin
My blog - Sharing My Thoughts, An Article - Understanding Statepattern
-
This is also applicable for "!="
-Sarath_._ "Great hopes make everything great possible" - Benjamin Franklin
My blog - Sharing My Thoughts, An Article - Understanding Statepattern
Not really because != can't result in an assignment, although for consistency one should apply the tip to != as well.
-
Not really because != can't result in an assignment, although for consistency one should apply the tip to != as well.
What if forget to add "!" before "="?
-Sarath_._ "Great hopes make everything great possible" - Benjamin Franklin
My blog - Sharing My Thoughts, An Article - Understanding Statepattern
-
What if forget to add "!" before "="?
-Sarath_._ "Great hopes make everything great possible" - Benjamin Franklin
My blog - Sharing My Thoughts, An Article - Understanding Statepattern
Very good point. Thanks for bringing it up.
-
Very good point. Thanks for bringing it up.
Another one is strcmp or CString's Compare function. People often used to forget equate to 0 for successful case. last week I have reviewed some source code of my colleagues. some of them haven't noticed this :(
-Sarath_._ "Great hopes make everything great possible" - Benjamin Franklin
My blog - Sharing My Thoughts, An Article - Understanding Statepattern
-
The last my task was to translate code from Delphi to c++. Here is the worst bug: if you have Delphi code
if (count = 1) { ... }In c++ you must replace it withif (count == 1) { ... }else you'll got assignment in condition. But if you write constant first the compiler alert you if you leave "=" uncanged :if (1 = count)// Compiler error { ... }This trick helps me a lot.My english is not so good. Please, correct my errors. Best regards, Alexey.
That was one of the rules in the coding standards at a place used to work. I went along with it, but my counter arguments are: 1) That only works when intending to compare with a non-L-value. 2) If you have the presence of mind to write it that way, you probably aren't going to mess it up anyway. Eventually they relaxed the rule. This continues to be why I would prefer the assignment operator to be :=, and a bare = be invalid.
-
The last my task was to translate code from Delphi to c++. Here is the worst bug: if you have Delphi code
if (count = 1) { ... }In c++ you must replace it withif (count == 1) { ... }else you'll got assignment in condition. But if you write constant first the compiler alert you if you leave "=" uncanged :if (1 = count)// Compiler error { ... }This trick helps me a lot.My english is not so good. Please, correct my errors. Best regards, Alexey.
-
That was one of the rules in the coding standards at a place used to work. I went along with it, but my counter arguments are: 1) That only works when intending to compare with a non-L-value. 2) If you have the presence of mind to write it that way, you probably aren't going to mess it up anyway. Eventually they relaxed the rule. This continues to be why I would prefer the assignment operator to be :=, and a bare = be invalid.
PIEBALDconsult wrote:
- If you have the presence of mind to write it that way, you probably aren't going to mess it up anyway.
But when you do mess up and write
=instead of==, the compiler catches the mistake right away. That's the whole point - the bug never makes it into the compiled code, not even once.--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
-
The last my task was to translate code from Delphi to c++. Here is the worst bug: if you have Delphi code
if (count = 1) { ... }In c++ you must replace it withif (count == 1) { ... }else you'll got assignment in condition. But if you write constant first the compiler alert you if you leave "=" uncanged :if (1 = count)// Compiler error { ... }This trick helps me a lot.My english is not so good. Please, correct my errors. Best regards, Alexey.
In C# you cannot do this mistake, since any expression evaluted in an
ifstatement must be boolean. So if you write:if (count = 1) {...}The compiler will error. The only exception is when you write:if (flag = false) {...}orif (flag = true) {...}The compiler won't error for this, but from my point of view there is no reason to compare booleans with an equal sign. Just useif(!flag)orif(flag). Ami