|
Stefan_Lang wrote: Woot, they wondered for decades and never demanded a fix? Can I have your users
please??
Can't fix it unless you can find it, and an uninitialized pointer can often be found to be pointing at something that looks like valid memory (say, some other string's buffer that isn't getting used at the moment) so the error doesn't occur all the time. Errors like this become "cold cases" because there are so few clues to follow. I sort of doubt that the users were quiet about it, either.
Pertinent to but opposing a point made by someone's tag line I read today, this is why I always initialize as close to the definition as possible, just to keep in the habit - I work in environments that assume initialization as well as environments like C where assumptions make asses out of everyone.
|
|
|
|
|
Yes, uninitialized pointers can be nasty, especially since they normally will be 0 when you look at the problem in debug builds and thus fail to reproduce the issue. But that alone (i. e. a bug that happens only in release) is enough of on an indication for me to look at initialization first.
Fortunately modern runtimes will no longer accept pointers that do not point into at least the data segment, or aren't aligned properly, so you're normally able to find the culprit very fast.
I, too, intialize every variable, to the point of assigning at least 0 (or nullptr , now), even when the actual initialization happens only two lines below. The point being, that 'two lines below' will likely not remain 'only two lines' in the long run.
I also sometimes use an intialization function for a class, so I can call it in each constructor. While it's more efficient to use initializers in each constructor, it's way too easy to forget one when introducing additional members later. I wonder why initializers for member variables are not allowed...
|
|
|
|
|
|
Blame can be put on the compiler that didn't raise an "uninitialized variable" warning, or triple blame on the programmer if he ignored it.
|
|
|
|
|
The originally used compiler was MSC 6. May be the latest versions has been build using VC 1.52. I don't remember if these C compilers generate such warnings. A look into the make file shows that warning level /W3 has been used.
|
|
|
|
|
|
MSC6 is Microsoft C Compiler version 6 (no 'V') released 1990! VC 1.52c has been released 1995 and is the last version with full MS-DOS support.
|
|
|
|
|
Yep. I started using Visual C++ with VC 1.51. You find traces of it on web pages. MSC6 is much more forgotten... (no confusion)
|
|
|
|
|
I still have an VC 1.52 installation in XP Mode and checked the help:
Warnings C4700 and C4701 are present but require /Oe (global register allocation) which is not set in the make file.
|
|
|
|
|
|
YvesDaoust wrote: IMHO such a condition (potentially uninitialized variable) should be signalled by default by any compiler because this can rescue you from painful bugs.
C4700 is a level 1 warning and therefore shown by default (the /Oe limitation does not exist anymore for actual compilers).
With debug versions, I always use level 4. Code is not allowed to be released, if there are any warnings. In some special cases, I use the method from your 2nd link to disable warnings including a comment.
Thank you for the 1st link. I did not know about until now.
|
|
|
|
|
Strange that the warning levels did depend on the optimization levels. In theory, optimization is fully transparent to the program semantics, isn't it ?
"Code is not allowed to be released, if there are any warnings": it is tempting for some developers to bypass this by just disabling the warnings. As heavy as this may be, such twists should be appropriately commented.
|
|
|
|
|
YvesDaoust wrote: Strange that the warning levels did depend on the optimization levels. In theory, optimization is fully transparent to the program semantics, isn't it ?
Of course. But the used compilers are historic.
YvesDaoust wrote: "Code is not allowed to be released, if there are any warnings": it is tempting for some developers to bypass this by just disabling the warnings. As heavy as this may be, such twists should be appropriately commented.
They must be commented. But there are situations where warnings may be disabled. An example would be using DAO which floods the output with C4995 warnings (name was marked as #pragma deprecated).
|
|
|
|
|
Today I found this code, from DAL class
public Boolean Execute_NoN_Query(string Sqlstring)
{
int ResultFlag = 0;
ResultFlag = MSSqlHelper.SqlHelper.ExecuteNonQuery(SqlServerConnection.Cn, CommandType.Text, Sqlstring);
if (ResultFlag != 0)
return true;
else
return false;
}
My Code is ....
public Boolean Execute_NoN_Query(string Sqlstring)
{
return (0 != MSSqlHelper.SqlHelper.ExecuteNonQuery(SqlServerConnection.Cn, CommandType.Text, Sqlstring));
}
|
|
|
|
|
That
if(something)
return true;
else return false;
... is far too prevalent. Its cousin,
if(something)
return a;
else return b;
... is at least understandable as some people have an allergic reaction to even simple ternaries (I have no idea why, they are a perfectly valid part of the language and have been since C).
Interesting to see someone else who likes to do
if(0 != ...)
... as well.
|
|
|
|
|
Ternaries ... you're right, as long as the expressions in the ternaries are simple, they are readable. But they can be simple initially, and become monstrous as the code evolves. Which may be why many people avoid ternaries - the same as with braces around blocks consisting of a single statement.
Although I don't buy either (no ternaries and braces around single statements) - you write the code as is fit initially, and reformat/refactor as needed when you change it.
There's another horror format:
boolean b;
...
if (b == true)
return x;
else
return y;
A variant is b being a boolean function.
|
|
|
|
|
Florin Jurcovici wrote: Although I don't buy either (no ternaries and braces around single statements) - you write the code as is fit initially, and reformat/refactor as needed when you change it.
Yes, exactly. And a simple
return statement ? a : b
... is not too hard to read, for sure.
Someone here is really passive-aggressive anti-ternary, judging by the downvote my other post got
Heh, that pattern is even worse.
|
|
|
|
|
Probably gets paid by lines of code.
|
|
|
|
|
BobJanova wrote: Someone here is really passive-aggressive anti-ternary, judging by the downvote
my other post got
Some people hate concision. Many of them, IMO, will need to look that word up :P
Truly, I've seen some real abuse of ternaries, which becomes a real horror if you have to add "elseif" cases. This is why some organizations ban them completely.
|
|
|
|
|
BobJanova wrote: Interesting to see someone else who likes to do
if(0 != ...)
... as well.
This is called Yoda condition.
|
|
|
|
|
VUnreal wrote:
BobJanova wrote: Interesting to see someone else who likes
to do
<SPAN class=code-keyword>if</SPAN>(<SPAN class=code-digit>0</SPAN> != ...) ...
as well.
This is called Yoda condition.
LMAO, I first saw this suggestion somewhere around 1991, and Yoda had nothing to do with it (it might have been Michael Abrash or Kent Porter, or some one-shot contributor to Dr. Dobbs, which had just stopped doing Software Orthodontia and Calisthenics a couple of years before).
|
|
|
|
|
Personally, I'm not a fan of ...
if (0 != ...)
I understand the arguments, that its less likely to cause an error if you use = rather than ==, but seriously, that doesn't occur that often (at least with reasonably competent developers), and I prefer readability to obscurity.
I've never seen a mathematical formula with the constant term on the l.h.s.
|
|
|
|
|
Rob Grainger wrote: I understand the arguments, that its less likely to cause an error if you use =
rather than ==, but seriously, that doesn't occur that often (at least with
reasonably competent developers), and I prefer readability to
obscurity.
Uh, huh....try bouncing back and forth several times a day between Pascal and C (then) or C# and VB.NET (now) and see how "competent" you stay, good buddy (BTW, that code-reading problem you have can be solved with practice...and this isn't mathematics). At the time this technique was suggested, it was one of the most common errors in C/C++ programming, and it's still a common error in all C's descendants when the coder spent signficant school or work time working in just about any other classical imperative language framework as most of them used a single equal sign as the operator for logical equivalence. Ah, the light just went on! You haven't spent much if any time outside the C box. You should get out more.
|
|
|
|
|
"You haven't spent much if any time outside the C box"
VB, Smalltalk, Eiffel, Haskell, LISP, to name a few. But evidentally, while I can manage to read both and learn to switch, you seem to be incapable. Every day I switch between VB, C#, and C++ which have similar differences.
"just about any other classical imperative language framework"
You may not have got out much recently, but the vast majority of languages in use nowadays have adopted these conventions.
|
|
|
|
|
Rob Grainger wrote: VB, Smalltalk, Eiffel, Haskell, LISP, to name a few.
Is this for product, or for your own research? under what time constraints for production delivery?
Rob Grainger wrote: Every day I switch between VB, C#, and C++ which have similar differences.
Just those? oh happy day. And how many separate projects are you working on simultaneously? How often do you have to drop one at your manager's demand to make a change in another for QA within the hour? If you are juggling four or five projects with at least four of them modifications to existing items and two of them were given to you yesterday for delivery the day before that, AND you still never, ever type a single equal sign where you meant a double equal sign...you're still too snotty to be let near most production programmers in corporate environments. No one who thinks they're perfect belongs near a production system, IMO - I've seen that sort of arrogance in action, and failed releases and recalls are just the biggest scratches in that surface. It's not the things you don't know that get you, it's the things you think you know that just aren't so, like the myth of your own continuing perfection. Good luck with that, btw
|
|
|
|
|