Steve Summit C notes , exercise

[Richard Heathfield]

arnuld said:

actually, my style is to FIRST declare all the variable and then
initialize them.

A minor nit: if it doesn't happen at the time you define the object, it
isn't initialisation, merely assignment. That isn't /quite/ the same
thing - there are things you can do in initialisation that you can't do
in assignment.

 

[arnuld]

A minor nit: if it doesn't happen at the time you define the object, it
isn't initialisation, merely assignment. That isn't /quite/ the same
thing

i did not get what you meant by *it* in "if it does nothappen" .

- there are things you can do in initialisation that you can't do
in assignment.

so what style you advise Richard ?

 

[Richard Heathfield]

arnuld said:

i did not get what you meant by *it* in "if it does nothappen" .

The provision of the value.

int x = 6; /* this is an initialisation - the object x is defined and
gets the value 6, all in one step */

int y; /* this is a definition, but no initialisation is performed */

y = 42; /* this is an assignment - it is NOT an initialisation */

so what style you advise Richard ?

Some people, including myself, prefer to ensure that all objects have a
deterministic value at all possible times. Thus, on definition, they
use initialisation either to give the object the value it requires or,
if that value isn't yet available, to give the object a default value
(typically 0 or -1 or NULL depending on the circumstances) whose only
role is to ensure that the value ascribed is determinate (known). The
value of this approach is that the behaviour of the program is
deterministic even if you accidentally use an object's value before
you've given it the value you intended - you'll almost certainly get
the wrong answer, but at least you'll get an answer.

Other people prefer to avoid what they see as unnecessary overhead,
choosing instead to rely on their compiler to warn them of a reference
to an object's value where no value has been written to that object,
and it is indeed true that some compilers can sometimes do this.

 

[arnuld]

Some people, including myself, prefer to ensure that all objects have a
deterministic value at all possible times. Thus, on definition, they
use initialisation either to give the object the value it requires or,
if that value isn't yet available, to give the object a default value
(typically 0 or -1 or NULL depending on the circumstances) whose only
role is to ensure that the value ascribed is determinate (known). The
value of this approach is that the behaviour of the program is
deterministic even if you accidentally use an object's value before
you've given it the value you intended - you'll almost certainly get
the wrong answer, but at least you'll get an answer.

that seems fine, so i will choose it and i do so because of this
sentence you said:

"there are things you can do in initialisation that you can't do in
assignment"

Other people prefer to avoid what they see as unnecessary overhead,
choosing instead to rely on their compiler to warn them of a reference
to an object's value where no value has been written to that object,
and it is indeed true that some compilers can sometimes do this.

they keyword is: "sometimes".

so i see, "always getting an answer, whether wrong/right" style will
be good.

 

[Richard Heathfield]

arnuld said:

so i see, "always getting an answer, whether wrong/right" style will
be good.

I see it that way too. Of course, it does mean that you have to be able
to tell the difference between a right answer and a wrong answer, but I
think of that skill as an intrinsic part of programming anyway.

 

[Dave Vandervies]

Some people, including myself, prefer to ensure that all objects have a
deterministic value at all possible times. Thus, on definition, they
use initialisation either to give the object the value it requires or,
if that value isn't yet available, to give the object a default value
(typically 0 or -1 or NULL depending on the circumstances) whose only
role is to ensure that the value ascribed is determinate (known). The
value of this approach is that the behaviour of the program is
deterministic even if you accidentally use an object's value before
you've given it the value you intended - you'll almost certainly get
the wrong answer, but at least you'll get an answer.

The utility here isn't in always getting an answer, but in always getting
the *same* answer. Deterministic-but-wrong code is a lot easier to
debug than nondeterministic code.


dave
(get it to fail reliably, and it's half fixed)

 

[Richard Heathfield]

Dave Vandervies said:

The utility here isn't in always getting an answer, but in always
getting
the *same* answer. Deterministic-but-wrong code is a lot easier to
debug than nondeterministic code.

Quite so. That's what I meant to say, and it's what I thought I'd said.
It just isn't what I *actually* said.