Hello,
What are the default value for initialized variable?
e.g.
int d; // debug give me -858993460
char c; // debug give me -52
I am using VS.net 2005
Thanks.
39  4960 
howa wrote:
Hello,
What are the default value for initialized variable?
e.g.
int d; // debug give me -858993460
char c; // debug give me -52
I am using VS.net 2005
Thanks.
There is no default value, just the random bits that happen to be in
that memory location.
If you want a non-random value, just ask for it:
int d = 0;
char c = 'a';
Bo Persson
howa wrote:
Hello,
What are the default value for initialized variable?
e.g.
int d; // debug give me -858993460
char c; // debug give me -52
I am using VS.net 2005
It's either unspecified or implementation defined.
However, in the case of VS, it's all cc's.
howa wrote:
Hello,
What are the default value for initialized variable?
e.g.
int d; // debug give me -858993460
char c; // debug give me -52
I am using VS.net 2005
Now that I think of it, the value is undefined, and accessing an
undefined variable is undefined behavior.
red floyd wrote:
It's either unspecified or implementation defined.
However, in the case of VS, it's all cc's.
I'm glad you added your other post. MS write 0xCC in debug mode only...
Andy
red floyd write:
Now that I think of it, the value is undefined, and accessing an
undefined variable is undefined behavior.
You mean the following is actually UB, meaning that a conforming
implementation may e.g. crash the program or format your hard disk?
#include <iostream>
int main()
{
int x;
std::cout << x;
}
I thought the value was more or less random and that's it. Could you
clarify what the standard really has to say about it?
--
Christian Hackl
On 19 avr, 19:43, Christian Hackl <ha...@sbox.tugraz.atwrote:
red floyd write:
Now that I think of it, the value is undefined, and
accessing an undefined variable is undefined behavior.
You mean the following is actually UB, meaning that a
conforming implementation may e.g. crash the program or format
your hard disk?
#include <iostream>
int main()
{
int x;
std::cout << x;
}
I thought the value was more or less random and that's it.
Could you clarify what the standard really has to say about
it?
It's undefined behavior for all types except unsigned char. All
other types can have trap representations.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze wrote:
On 19 avr, 19:43, Christian Hackl <ha...@sbox.tugraz.atwrote:
>red floyd write:
>>Now that I think of it, the value is undefined, and
accessing an undefined variable is undefined behavior.
>You mean the following is actually UB, meaning that a
conforming implementation may e.g. crash the program or format
your hard disk?
>#include <iostream>
int main()
{
int x;
std::cout << x;
}
>I thought the value was more or less random and that's it.
Could you clarify what the standard really has to say about
it?
It's undefined behavior for all types except unsigned char. All
other types can have trap representations.
Representations. It's not undefined behavior, just an undefined value.
--
Jim Langston ta*******@rocketmail.com
"howa" <ho******@gmail.comwrote in message
news:7b**********************************@v23g2000 pro.googlegroups.com...
Hello,
What are the default value for initialized variable?
e.g.
int d; // debug give me -858993460
char c; // debug give me -52
I am using VS.net 2005
There is no default value. It's basically random in that it could be
anything. AFAICT, the only time your going to get a default value is when
you declare a static variable. Only then is the default is zero:
__________________________________________________ ________________
#include <cstdio>
static int s_a, s_b, s_c;
int main() {
int l_a, l_b, l_c;
std::printf("static vars:\ts_a(%d), s_b(%d), s_c(%d)\n",
s_a, s_b, s_c);
std::printf("local vars:\tl_a(%d), l_b(%d), l_c(%d)\n",
l_a, l_b, l_c);
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~*/
puts("\n\n________________________________________ _________\n\
press <ENTERto exit...");
getchar();
return 0;
}
__________________________________________________ ________________
The values for the 's_*' variables should all be zero. However, the values
for 'l_*' could be anything...
"Chris Thomasson" <cr*****@comcast.netwrote in message
news:hK******************************@comcast.com. ..
"howa" <ho******@gmail.comwrote in message
news:7b**********************************@v23g2000 pro.googlegroups.com...
>Hello,
What are the default value for initialized variable?
e.g.
int d; // debug give me -858993460
char c; // debug give me -52
I am using VS.net 2005
There is no default value. It's basically random in that it could be
anything. AFAICT, the only time your going to get a default value is when
you declare a static variable. Only then is the default is zero:
__________________________________________________ ________________
#include <cstdio>
static int s_a, s_b, s_c;
int main() {
int l_a, l_b, l_c;
std::printf("static vars:\ts_a(%d), s_b(%d), s_c(%d)\n",
s_a, s_b, s_c);
std::printf("local vars:\tl_a(%d), l_b(%d), l_c(%d)\n",
l_a, l_b, l_c);
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~*/
puts("\n\n________________________________________ _________\n\
press <ENTERto exit...");
getchar();
^^^^^^^^^^^^^^^^^^^^^^^
std::puts and std::getchar of course! ARGHGH.
return 0;
}
__________________________________________________ ________________
[...]
Jim Langston wrote:
James Kanze wrote:
>On 19 avr, 19:43, Christian Hackl <ha...@sbox.tugraz.atwrote:
>>red floyd write:
>>>Now that I think of it, the value is undefined, and
accessing an undefined variable is undefined behavior.
>>You mean the following is actually UB, meaning that a
conforming implementation may e.g. crash the program or format
your hard disk?
>>#include <iostream>
int main()
{
int x;
std::cout << x;
}
>>I thought the value was more or less random and that's it.
Could you clarify what the standard really has to say about
it?
It's undefined behavior for all types except unsigned char. All
other types can have trap representations.
Representations. It's not undefined behavior, just an undefined value.
A trap representation is a bit-pattern that does not correspond to a valid
value of the type of the object. Undefined behavior happens when such a
bit-pattern is present at &x when x is handed to std::cout.
Best
Kai-Uwe Bux
red floyd dixit:
howa wrote:
>Hello,
What are the default value for initialized variable?
e.g.
int d; // debug give me -858993460
char c; // debug give me -52
I am using VS.net 2005
Now that I think of it, the value is undefined, and accessing an
undefined variable is undefined behavior.
except if they are global, in which case they are initialized to 0.
int i; // <== garanty to be 0
int main() {}
Hi all,
Just find some interesting stuffs...on VS.net 2005
#include <iostream>
using namespace std;
int main() {
int j;
cout<<j;
system("pause");
return 0;
}
The above program always return "1"
Now try...
#include <iostream>
using namespace std;
int main() {
int a, j;
cout<<j;
system("pause");
return 0;
}
It always return "4428403"
I am running in debug mode of VS.net
Any idea?
Howard
On 4$B7n(B20$BF|(B, $B2<8a(B3$B;~(B11$BJ,(B, di <d...@siluverlghtt.cmowrote:
red floyd dixit:
howa wrote:
Hello,
What are the default value for initialized variable?
e.g.
int d; // debug give me -858993460
char c; // debug give me -52
I am using VS.net 2005
Now that I think of it, the value is undefined, and accessing an
undefined variable is undefined behavior.
except if they are global, in which case they are initialized to 0.
int i; // <== garanty to be 0
int main() {}
[please don't top-post]
howa wrote:
Hi all,
Just find some interesting stuffs...on VS.net 2005
#include <iostream>
using namespace std;
int main() {
int a, j;
cout<<j;
system("pause");
return 0;
}
It always return "4428403"
I am running in debug mode of VS.net
Any idea?
Luck.
--
Ian Collins.
Kai-Uwe Bux wrote:
Jim Langston wrote:
>James Kanze wrote:
>>>
On 19 avr, 19:43, Christian Hackl <ha...@sbox.tugraz.atwrote:
int x;
std::cout << x;
It's undefined behavior for all types except unsigned char. All
other types can have trap representations.
Representations. It's not undefined behavior, just an undefined value.
A trap representation is a bit-pattern that does not correspond to a valid
value of the type of the object. Undefined behavior happens when such a
bit-pattern is present at &x when x is handed to std::cout.
Thank you. Looks like I had no idea how evil it _really_ is to use
uninitialised variables! :)
--
Christian Hackl
On 19 avr, 23:15, "Jim Langston" <tazmas...@rocketmail.comwrote:
James Kanze wrote:
On 19 avr, 19:43, Christian Hackl <ha...@sbox.tugraz.atwrote:
red floyd write:
>Now that I think of it, the value is undefined, and
accessing an undefined variable is undefined behavior.
You mean the following is actually UB, meaning that a
conforming implementation may e.g. crash the program or format
your hard disk?
#include <iostream>
int main()
{
int x;
std::cout << x;
}
I thought the value was more or less random and that's it.
Could you clarify what the standard really has to say about
it?
It's undefined behavior for all types except unsigned char.
All other types can have trap representations.
Representations. It's not undefined behavior, just an
undefined value.
A trap representation means that the program "traps" whenever
that representation is read from memory. What happens when the
program traps is undefined behavior according to the
standard---in most modern hosted environments, it will cause a
core dump or its equivalent.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
red floyd wrote:
howa wrote:
>Hello,
What are the default value for initialized variable?
e.g.
int d; // debug give me -858993460
char c; // debug give me -52
I am using VS.net 2005
It's either unspecified or implementation defined.
However, in the case of VS, it's all cc's.
The word the standard uses is INDETERMINATE.
It's a gross piece of insanity left over from historical
C stupidity that certain types neglect to perform their
default initialization at times (the default initialization
of int and char is to zero initialize them by the way).
On 20 avr, 16:49, Ron Natalie <r...@spamcop.netwrote:
red floyd wrote:
howa wrote:
What are the default value for initialized variable?
e.g.
int d; // debug give me -858993460
char c; // debug give me -52
I am using VS.net 2005
It's either unspecified or implementation defined.
However, in the case of VS, it's all cc's.
The word the standard uses is INDETERMINATE.
For the contents of d and c. The word the standard uses for
"reading" the indeterminate contents of d is "undefined
behavior".
It's a gross piece of insanity left over from historical
C stupidity that certain types neglect to perform their
default initialization at times (the default initialization
of int and char is to zero initialize them by the way).
Well, I can't disagree with that.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
di wrote:
>>
Now that I think of it, the value is undefined, and accessing an
undefined variable is undefined behavior.
except if they are global, in which case they are initialized to 0.
int i; // <== garanty to be 0
int main() {}
The words you are looking for are "static storage duration". Objects with static
storage duration are zero-initialized.
--
Best regards,
Andrey Tarasevich
howa wrote:
Hi all,
Just find some interesting stuffs...on VS.net 2005
#include <iostream>
using namespace std;
int main() {
int j;
cout<<j;
system("pause");
return 0;
}
The above program always return "1"
Now try...
#include <iostream>
using namespace std;
int main() {
int a, j;
cout<<j;
system("pause");
return 0;
}
It always return "4428403"
I am running in debug mode of VS.net
Any idea?
There is no defined behavior for Undefined Behavior. Learn that. Live
that.
Brian
Stefan Ram wrote:
"Default User" <de***********@yahoo.comwrites:
>>>int a, j;
cout<<j;
Undefined Behavior
»if no initializer is specified for a non-static object,
the object and its subobjects, if any, have an
indeterminate initial value« - ISO/IEC 14882:2003(E), 8.5p9
Will writing an indeterminate value cause undefined behavior?
Unless the type is unsigned char, the object might have a bit-pattern that
does not correspond to a legal value (trap representation). If the
indeterminate value happens to be invalid, reading it can cause anything.
Therefore, reading an indeterminate value of type int is undefined
behavior.
Best
Kai-Uwe Bux
On Sun, 20 Apr 2008 10:49:55 -0400, Ron Natalie <ro*@spamcop.net>
wrote in comp.lang.c++:
red floyd wrote:
howa wrote:
Hello,
What are the default value for initialized variable?
e.g.
int d; // debug give me -858993460
char c; // debug give me -52
I am using VS.net 2005
It's either unspecified or implementation defined.
However, in the case of VS, it's all cc's.
The word the standard uses is INDETERMINATE.
It's a gross piece of insanity left over from historical
C stupidity that certain types neglect to perform their
default initialization at times (the default initialization
of int and char is to zero initialize them by the way).
The above disclaimer must be understood as representing the view of
some, but by no means all, C++ programmers.
One of the stated purposes in the development of the C++ language was
to keep the efficiency that makes C so valuable for system
programming. Adding extra overhead of initializing local variables
without directions from the programmer adds code size and execution
time.
When you consider the fact that one of the first features that C++
added to C was the ability to define local objects at any point in a
block, making it possible to defer definition until you know what you
want to initialize it with, the complaint above is can be seen in a
different context.
The author wants to add baggage to the language to protect programmers
from coding errors.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Jack Klein wrote:
<snip>
When you consider the fact that one of the first features that C++
added to C was the ability to define local objects at any point in a
block, making it possible to defer definition until you know what you
want to initialize it with, the complaint above is can be seen in a
different context.
I commonly write code of this form:
std::vector< std::string::const_iterator someItemIWantToProcess;
for (someItemIWantToProcess = collection.begin(); someItemIWantToProcess
!= collection.end(); ++someItemIWantToProcess)
{
....
}
Where the iterator is defined outside the for loop, *solely because it
would make the line too big and clumsy*. I don't want automatic
initialisation; I'd be quite happy if the debug-mode runtime checked
for uninitialised use.
That aside, I've never used an architecture with any int value that
would cause an error when used. It is however quite common for floating
point values (e.g. Intel's NAN), and AFAIK universal for pointers.
Andy
Andy Champ wrote:
Jack Klein wrote:
<snip>
>When you consider the fact that one of the first features that C++
added to C was the ability to define local objects at any point in a
block, making it possible to defer definition until you know what you
want to initialize it with, the complaint above is can be seen in a
different context.
I commonly write code of this form:
std::vector< std::string::const_iterator someItemIWantToProcess;
That'll be a syntax error.
for (someItemIWantToProcess = collection.begin(); someItemIWantToProcess
!= collection.end(); ++someItemIWantToProcess)
{
....
}
Where the iterator is defined outside the for loop, *solely because it
would make the line too big and clumsy*.
Ever thought of breaking the line down into its parts?
Long templated types are best tidied up using typedefs.
I don't want automatic
initialisation; I'd be quite happy if the debug-mode runtime checked
for uninitialised use.
It doesn't have to, that's a job for a static checking tool like lint,
or even the compiler.
--
Ian Collins.
On Apr 20, 11:54 pm, Jack Klein <jackkl...@spamcop.netwrote:
On Sun, 20 Apr 2008 10:49:55 -0400, Ron Natalie <r...@spamcop.net>
wrote in comp.lang.c++:
red floyd wrote:
howa wrote:
>What are the default value for initialized variable?
>e.g.
>int d; // debug give me -858993460
>char c; // debug give me -52
>I am using VS.net 2005
It's either unspecified or implementation defined.
However, in the case of VS, it's all cc's.
The word the standard uses is INDETERMINATE.
It's a gross piece of insanity left over from historical C
stupidity that certain types neglect to perform their
default initialization at times (the default initialization
of int and char is to zero initialize them by the way).
The above disclaimer must be understood as representing the
view of some, but by no means all, C++ programmers.
I think it pretty much sums up the only reasonable attitude for
a professional programmer to have.
One of the stated purposes in the development of the C++
language was to keep the efficiency that makes C so valuable
for system programming. Adding extra overhead of initializing
local variables without directions from the programmer adds
code size and execution time.
How much extra overhead does it really have? Have you measured
it? Most of the time, if you do actually initialize the
variable before use, the compiler will see it, and not bother
with any other initialization.
When you consider the fact that one of the first features that
C++ added to C was the ability to define local objects at any
point in a block, making it possible to defer definition until
you know what you want to initialize it with, the complaint
above is can be seen in a different context.
The author wants to add baggage to the language to protect
programmers from coding errors.
The author wants to make program behavior reproduceable, so that
a test means something. If you don't believe in testing code,
and don't mind random behavior, there's no problem. Otherwise,
there is.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Apr 20, 10:43 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
Kai-Uwe Bux <jkherci...@gmx.netwrites:
Unless the type is unsigned char, the object might have a
bit-pattern that does not correspond to a legal value (trap
representation).
I can't find the word »trap« in ISO/IEC 14882:2003(E),
but I know it from ISO/IEC 9899:1999 (E). Maybe the authors
of ISO/IEC 14882:2003(E) thought that this was self-evident
or only use »illegal value« - but I also can not find
»illegal value« or »legal vallue« in ISO/IEC 14882:2003(E).
You might be right, but I can not prove it from ISO/IEC
14882:2003(E). May ISO/IEC 14882:2003(E) targets a smaller set
of architectures than ISO/IEC 9899:1999 (E), where there are
no trap representations? A C++ compiler will not be able to
hide trap representation from the programmer if a C compiler
can't hide them.
I also found this suggestion from November 3, 1995, which does
/not/ seem to be implemented in ISO/IEC 14882:2003(E):
»476 - Can objects with "indeterminate initial value" be referred to?
8.5p6 says:
"If no initializer is specified for an object with automatic or
dynamic storage duration, the object and its subobjects, if any,
have an indeterminate initial value."
The C standard specifies that accessing a variable with
indeterminate value results in undefined behavior, but the C++ draft
contains no such language.
Proposed Resolution:
Add the following text at the end of 8.5 paragraph 6:
"Referring to an object with an indeterminate value results in
undefined behavior."«
http://www.open-std.org/jtc1/sc22/wg...1995/N0803.htm
ISO/IEC 14882:2003 is based on ISO/IEC 9899:1990. The wording
in it is very close to that in C90. The wording is not very
precise (and in fact contradicts C90 in one small
particular---unintentionally, I'm pretty sure). The C committee
addressed the issue, and rewrote the section to be more precise;
this results in the wording in C99.
Even without C99, however, the wording in C++03 explicitly says
that "For character types, all bits of the object representation
participate in the value representation. For unsigned character
types, all possible bit patterns of the value representation
represent numbers. These requirements do not hold for other
types." In other words, not all bits participate in the value
representation. So some are free to create trap values.
In practice, at least one currently marketed machine does have a
tag bit of some sort in its integral types, plus a number of
bits which must be 0. I don't know what happens if the tag bit
has the wrong value, but it could result in a trap. And if the
must be 0 bits are not 0, the value is interpreted as a floating
point value, which is another possible "undefined behavior".
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ian Collins wrote:
Andy Champ wrote:
>I commonly write code of this form:
std::vector< std::string::const_iterator someItemIWantToProcess;
That'll be a syntax error.
So it is. But I thnk you can gues what I mean.
>for (someItemIWantToProcess = collection.begin(); someItemIWantToProcess
!= collection.end(); ++someItemIWantToProcess)
{
....
}
Where the iterator is defined outside the for loop, *solely because it
would make the line too big and clumsy*.
Ever thought of breaking the line down into its parts?
Yes. That is precisely what I *was* doing.
>
Long templated types are best tidied up using typedefs.
.... and on that, well, it depends on circumstances. I was looking at
some code earlier today that has half-a-dozen typedefs at the front of a
bit of code. The names are chosen for the function of the types; I had
to keep flipping back to find out what they actually were. (Is a
thingyList a std::list of thingys, or is it some other kind of collection?)
Sometimes typedefs are good, sometimes a PITA.
>I don't want automatic
initialisation; I'd be quite happy if the debug-mode runtime checked
for uninitialised use.
It doesn't have to, that's a job for a static checking tool like lint,
or even the compiler.
If static checking tools and compilers could do all the checking for us
we would never need to debug.
Andy
Andy Champ wrote:
Ian Collins wrote:
>Andy Champ wrote:
>>I don't want automatic
initialisation; I'd be quite happy if the debug-mode runtime checked
for uninitialised use.
It doesn't have to, that's a job for a static checking tool like lint,
or even the compiler.
If static checking tools and compilers could do all the checking for us
we would never need to debug.
You said "I'd be quite happy if the debug-mode runtime checked for
uninitialised use". That is something lint or the compiler can do.
--
Ian Collins.
Ian Collins wrote:
You said "I'd be quite happy if the debug-mode runtime checked for
uninitialised use". That is something lint or the compiler can do.
Well I know my compiler (MS VC2005) doesn't.
However, let me give an example.
I pass a pointer (or reference) to an uninitialised variable to an
external function.
Will your static checker
(a) complain, possibly incorrectly, that you are passing an
uninitialised variable to a function that will initialise it or
(b) fail to complain that you are not initialising a variable when it is
passed to a function that uses it or
(c) use magic to work out whether this code it cannot see is going to
read the variable before writing it?
I don't know a 4th choice.
Andy
On Apr 21, 8:46 pm, Andy Champ <no....@nospam.comwrote:
[...]
If static checking tools and compilers could do all the
checking for us we would never need to debug.
In general, if code compiles without errors, and passes code
review, it should work. An error downstream is generally a very
strong indication that your process needs improvement.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze wrote:
>
In general, if code compiles without errors, and passes code
review, it should work. An error downstream is generally a very
strong indication that your process needs improvement.
Are you seriously telling me that as a result of compiler checks and
code reviews you never have a bug?
Andy
On Apr 22, 11:52 pm, Andy Champ <no....@nospam.comwrote:
James Kanze wrote:
In general, if code compiles without errors, and passes code
review, it should work. An error downstream is generally a very
strong indication that your process needs improvement.
Are you seriously telling me that as a result of compiler
checks and code reviews you never have a bug?
I'm seriously telling you that any bug which occurred downstream
from development was investigated, and the process modified so
that it wouldn't reoccur. This process was initially instigated
because we more or less had to: we were delivering a turn-key
system with contractual penalties for downtime---every minute
the system wasn't available, the customer billed us. What we
found out was that this process also reduced our development
costs: it's actually cheaper to produce quality software than it
is to produce junk. (I suspect that this is only true up to a
point, and that at one error per 100KLoc, we hadn't reached that
point.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze wrote:
>
I'm seriously telling you that any bug which occurred downstream
from development was investigated, and the process modified so
that it wouldn't reoccur. This process was initially instigated
because we more or less had to: we were delivering a turn-key
system with contractual penalties for downtime---every minute
the system wasn't available, the customer billed us. What we
found out was that this process also reduced our development
costs: it's actually cheaper to produce quality software than it
is to produce junk. (I suspect that this is only true up to a
point, and that at one error per 100KLoc, we hadn't reached that
point.)
James,
If most people posted this up I'd think it was BS - but I've seen enough
from you to be pretty sure it isn't. We've had all sorts of people in
to advise us on processes, and none of them has come up with anything
that would be a real change from the way we've always written software:
Engage brain, double check it, then test it to death. About the only
thing that's changed is a formal code review - and I know that does miss
things.
I'd be fascinated to know what you are doing. Is it documented anywhere?
Andy
On 2008-04-23 14:47:19 -0400, Andy Champ <no****@nospam.comsaid:
James Kanze wrote:
>>
I'm seriously telling you that any bug which occurred downstream
from development was investigated, and the process modified so
that it wouldn't reoccur. This process was initially instigated
because we more or less had to: we were delivering a turn-key
system with contractual penalties for downtime---every minute
the system wasn't available, the customer billed us. What we
found out was that this process also reduced our development
costs: it's actually cheaper to produce quality software than it
is to produce junk. (I suspect that this is only true up to a
point, and that at one error per 100KLoc, we hadn't reached that
point.)
James,
If most people posted this up I'd think it was BS - but I've seen
enough from you to be pretty sure it isn't. We've had all sorts of
people in to advise us on processes, and none of them has come up with
anything that would be a real change from the way we've always written
software:
Engage brain, double check it, then test it to death. About the only
thing that's changed is a formal code review - and I know that does
miss things.
I'd be fascinated to know what you are doing. Is it documented anywhere?
Take a look at "Quality is Free", by Philip Crosby. His core analogy is
an automobile assembly line. If a car comes off the line without
headlights, you put headlights on it. But you don't stop there: you go
to the station where headlights are installed and figure out why that
car didn't get headlights.
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
Andy Champ wrote:
James Kanze wrote:
>>
I'm seriously telling you that any bug which occurred downstream
from development was investigated, and the process modified so
that it wouldn't reoccur. This process was initially instigated
because we more or less had to: we were delivering a turn-key
system with contractual penalties for downtime---every minute
the system wasn't available, the customer billed us. What we
found out was that this process also reduced our development
costs: it's actually cheaper to produce quality software than it
is to produce junk. (I suspect that this is only true up to a
point, and that at one error per 100KLoc, we hadn't reached that
point.)
James,
If most people posted this up I'd think it was BS - but I've seen enough
from you to be pretty sure it isn't. We've had all sorts of people in
to advise us on processes, and none of them has come up with anything
that would be a real change from the way we've always written software:
Engage brain, double check it, then test it to death. About the only
thing that's changed is a formal code review - and I know that does miss
things.
There's also Engage brain, write test, write code to pass test, repeat.
--
Ian Collins.
James Kanze wrote:
On Apr 22, 11:52 pm, Andy Champ <no....@nospam.comwrote:
>James Kanze wrote:
>>In general, if code compiles without errors, and passes code
review, it should work. An error downstream is generally a very
strong indication that your process needs improvement.
>Are you seriously telling me that as a result of compiler
checks and code reviews you never have a bug?
I'm seriously telling you that any bug which occurred downstream
from development was investigated, and the process modified so
that it wouldn't reoccur. This process was initially instigated
because we more or less had to: we were delivering a turn-key
system with contractual penalties for downtime---every minute
the system wasn't available, the customer billed us. What we
found out was that this process also reduced our development
costs: it's actually cheaper to produce quality software than it
is to produce junk. (I suspect that this is only true up to a
point, and that at one error per 100KLoc, we hadn't reached that
point.)
You're describing a CMMI Level 4 process. Good stuff.
On Apr 23, 8:47 pm, Andy Champ <no....@nospam.comwrote:
James Kanze wrote:
I'm seriously telling you that any bug which occurred downstream
from development was investigated, and the process modified so
that it wouldn't reoccur. This process was initially instigated
because we more or less had to: we were delivering a turn-key
system with contractual penalties for downtime---every minute
the system wasn't available, the customer billed us. What we
found out was that this process also reduced our development
costs: it's actually cheaper to produce quality software than it
is to produce junk. (I suspect that this is only true up to a
point, and that at one error per 100KLoc, we hadn't reached that
point.)
If most people posted this up I'd think it was BS - but I've seen enough
from you to be pretty sure it isn't. We've had all sorts of people in
to advise us on processes, and none of them has come up with anything
that would be a real change from the way we've always written software:
Engage brain, double check it, then test it to death. About the only
thing that's changed is a formal code review - and I know that does miss
things.
I'd be fascinated to know what you are doing. Is it documented anywhere?
SEI. ( http://www.sei.cmu.edu/)
Of course, it's not been the case everywhere I've worked. But
when the contract with the final user specifies contractual
penalties for down time, management is motivated to make it
work.
The key, or one of them, is the feedback. You get an error in
the field; you ask "what could we have done differently so that
it would have been caught in code review?" Sometimes, it's a
question of simply taking code review a bit more seriously, and
checking for "obvious" things, like uninitialized variables.
Other times, it's a question of writing simpler code (although
if the code is too complicated for the reviewers to be 100% sure
that it works, it needs to be reworked to be simpler). Or are
you forgetting to consider the border cases---make it a point
for a while to list them explicitly, and verify them. I've also
found writing things out to be helpful---somehow, what
"obviously works" ends up having flaws when you try to explain
in writing why you're sure it works. The point is, of course,
that someone looking at your code should be rapidly convinced
that it is correct. Not that he doesn't see any errors, but
that he can see clearly that there aren't any.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Apr 23, 11:42 pm, Ian Collins <ian-n...@hotmail.comwrote:
Andy Champ wrote:
[...]
Engage brain, double check it, then test it to death. About
the only thing that's changed is a formal code review - and
I know that does miss things.
There's also Engage brain, write test, write code to pass
test, repeat.
Which doesn't change the basic problem. If an error slips
through the code review/tests/etc., what do you do about it?
What do you have to change so that code review will find similar
errors in the future, and to be sure that tests will reveal the
error (if possible---some things can't reasonably be tested).
And so on. The problem has to be addressed at a higher level.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze wrote:
>
SEI. (http://www.sei.cmu.edu/)
Of course, it's not been the case everywhere I've worked. But
when the contract with the final user specifies contractual
penalties for down time, management is motivated to make it
work.
The key, or one of them, is the feedback. You get an error in
the field; you ask "what could we have done differently so that
it would have been caught in code review?" Sometimes, it's a
question of simply taking code review a bit more seriously, and
checking for "obvious" things, like uninitialized variables.
Other times, it's a question of writing simpler code (although
if the code is too complicated for the reviewers to be 100% sure
that it works, it needs to be reworked to be simpler). Or are
you forgetting to consider the border cases---make it a point
for a while to list them explicitly, and verify them. I've also
found writing things out to be helpful---somehow, what
"obviously works" ends up having flaws when you try to explain
in writing why you're sure it works. The point is, of course,
that someone looking at your code should be rapidly convinced
that it is correct. Not that he doesn't see any errors, but
that he can see clearly that there aren't any.
Thanks for that James. One to read on Tuesday (as I have a long weekend
booked...)
As for complexity. We're stuck with that, it's a result of working with
a spec that came from a committee.
Andy This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: G Kannan |
last post by:
Hey all!
I have written a perl script to retrieve information from a HTML Form
and insert the data into an Oracle database table. I am gettting the
the following error message:
"Use of...
|
by: rk |
last post by:
Hi,
I'm a beginner for perl/cgi programs and i tried to write a cgi script
and when i ran it, i got the following error. But when i verified it
from the book i typed exactly whatever it is there...
|
by: Liang |
last post by:
Hi,
I use "defined $r_libs->{$name}" to check first if a key exists in a hash
table. But Perl gives a warning WHENEVER the key exists: "Use of
uninitialized value".
Would u please help to...
|
by: Marcin Kalicinski |
last post by:
int a; // #1 uninitialized value
int a(0) // #2 zero-initialized value
std::vector<int> v(10); // #3 zero-initialized values (why?)
std::vector<int> v(10, 0); // #4...
|
by: rswanster |
last post by:
When I compile and run the following:
#include <iostream>
int main() {
bool f;
std::cout << f << std::endl;
f = not(f);
std::cout << f << std::endl;
}
| | |
by: jyu.james |
last post by:
I'm trying to detect reads of uninitialized global variables (that are
declared in one file, and used in another as an extern).
I know that ANSI C initializes all global variables to 0, however,...
|
by: julien |
last post by:
Hello,
Is it possible if a boolean was initialized or not? For other types of
variable, I usually check if it is null. But this not possible for a
boolean.
Thank you
Julien
|
by: sanjaymeher |
last post by:
Hi,
Right now addDynamicMemory(char **ptr, int size) method can able to
handle if input ptr is intitialized to NULL or something. But how to
improve this method to handle uninitialized pointed...
|
by: pnsreee |
last post by:
Hi All,
I have the following code.
The array @sub_data will contain integers or a string"NO". I have to validate if the array contain integer. If it contain "NO" then no need to validate.
...
|
by: Spoon |
last post by:
Hello everyone,
I suppose using uninitialized automatic integer variables leads
to undefined behavior?
i.e.
int foo(void)
{
int bar; /* bar may be 0, or it may be non-0 */
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
| | |
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
