468,257 Members | 1,449 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,257 developers. It's quick & easy.

Uninitialized values?

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.

Jun 27 '08 #1
39 4693
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
Jun 27 '08 #2
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.
Jun 27 '08 #3
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.
Jun 27 '08 #4
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
Jun 27 '08 #5
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
Jun 27 '08 #6
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
Jun 27 '08 #7
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
Jun 27 '08 #8
"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...

Jun 27 '08 #9

"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;
}

__________________________________________________ ________________
[...]
Jun 27 '08 #10
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
Jun 27 '08 #11
di
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() {}
Jun 27 '08 #12
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() {}
Jun 27 '08 #13
[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.
Jun 27 '08 #14
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
Jun 27 '08 #15
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
Jun 27 '08 #16
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).

Jun 27 '08 #17
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
Jun 27 '08 #18
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
Jun 27 '08 #19
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

Jun 27 '08 #20
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
Jun 27 '08 #21
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
Jun 27 '08 #22
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
Jun 27 '08 #23
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.
Jun 27 '08 #24
Jack Klein <ja*******@spamcop.netwrites:
The author wants to add baggage to the language to protect programmers
from coding errors.
That way lies Java... :-(

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
Jun 27 '08 #25
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
Jun 27 '08 #26
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

Jun 27 '08 #27
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
Jun 27 '08 #28
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.
Jun 27 '08 #29
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
Jun 27 '08 #30
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
Jun 27 '08 #31
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
Jun 27 '08 #32
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
Jun 27 '08 #33
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
Jun 27 '08 #34
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)

Jun 27 '08 #35
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.
Jun 27 '08 #36
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.
Jun 27 '08 #37
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
Jun 27 '08 #38
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
Jun 27 '08 #39
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
Jun 27 '08 #40

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by rk | last post: by
3 posts views Thread by Marcin Kalicinski | last post: by
13 posts views Thread by rswanster | last post: by
12 posts views Thread by jyu.james | last post: by
3 posts views Thread by julien | last post: by
21 posts views Thread by sanjaymeher | last post: by
18 posts views Thread by Spoon | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by kermitthefrogpy | last post: by
reply views Thread by zattat | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.