why do some writers declare and define variables separately

[Ian Collins]

Gordon Burditt wrote:

Don't snip attributions if you reply.

Those who program for pay sometimes have an incentive to *INCREASE*
code lines because it gives them a bigger paycheck.

Yeah right. Utter nonsense.

I find the warning some compilers generate about uninitialized
variables useful, and I really don't want to defeat it by getting
into the habit of always initializing variables using some value I
don't think about much (especially I don't want to initialize it
before having thought much about the code that will use it).

Why on Earth would you introduce a variable if you don't know how it
would be used?

 

[Öö Tiib]

Object-oriented programming - both the term and the concept -
predates not only C++-style destructors but C++ itself.

How does that matter? Why particular style of computer programming
(OOP) can not evolve while styles of activity in every other field
(and the fields) do evolve? Most fields of human activity (like
Mathematics, Physics, Metallurgy or Biology) predate computer
programming by millenniums. Those do evolve.

Anyone who thinks destructors are part of OOP doesn't
understand the term.

What is your ground to say so? Also ... why to hold that lamp under a
bushel? It might be worth to say it elsewhere too (even more so).
For example go fix Wikipedia and shed that true light to masses:
http://en.wikipedia.org/wiki/Destructor_(computer_programming)

For me a destructor is merely a special /method/ that is as strongly
related to /object/'s lifetime as is /constructor/. It fits very
well into OOP. The alternatives like finalizers and disposers feel
inelegant hacks.

 

[James Kuyper]

Gordon Burditt wrote: ....

Why on Earth would you introduce a variable if you don't know how it
would be used?

He wasn't talking about introducing a variable, but about initializing
one. He wasn't talking about not knowing how it would be used, but about
not knowing yet what value it should be given.

In order to give a variable the right scope, it is sometimes necessary
to define it before it can be given any value that will actually be
used. This was common in C90, though less so C99 and C2001, since
intermixed declarations and statements are now allowed, but the issue
can still come up. Some people even deliberately define variables with a
wider scope than necessary, because of a dogma that all variables must
be declared at the start of a function, making the issue come up more
often than it has to.

Some people follow a dogma that says that a variable should always be
initialized at the point of definition, even if doing so means that it
must be initialized with a value that should never be used. That's what
he's talking about. By doing so they disable the warnings he was talking
about. That's because the compiler has no way of knowing that the
initializer provided was NOT intended to be used.

 

[Noob]

Don't snip attributions if you reply.

He's been doing it for years, and will not relent.
It bothered me to the point that I KFed him, even
though some of his posts are genuinely insightful.

 

[James Kuyper]

He's been doing it for years, and will not relent.
It bothered me to the point that I KFed him, even
though some of his posts are genuinely insightful.

Keith Thompson and I have both informed him that he does not have
permission to quote us without proper attribution. With a few minor
exceptions, I believe that he's avoided directly quoting either of us
since we told him that.

 

[Keith Thompson]

used. This was common in C90, though less so C99 and C2001, since

C2011.

 

[Keith Thompson]

Object-oriented programming - both the term and the concept -
predates not only C++-style destructors but C++ itself.
Anyone who thinks destructors are part of OOP doesn't
understand the term.

According to the Official Definition of OOP -- which exists where,
exactly?

 

[glen herrmannsfeldt]

According to the Official Definition of OOP -- which exists where,
exactly?

I don't know where exactly, but I was using an OO graphics system
in the Fortran 66 days. I didn't know it was OO at the time, but
looking back now, it obviously was. The objects, called graphic
elements, were stored in static allocated arrays (the only kind
available). (There was also a PL/I version, which would have allowed
for dynamic allocation. The allocation was done by the user, though.)

Maybe not official, but I recommend "Handbook of Programming
Languages, volume I". (Volume I is Object Oriented Languages.)

http://www.biblio.com/9781578700080

I remember TXR telling me about Simula on the PDP-10 many
years ago. Years before C++.

-- glen

 

[Ian Collins]

He wasn't talking about introducing a variable, but about initializing
one. He wasn't talking about not knowing how it would be used, but about
not knowing yet what value it should be given.

I was commenting on "before having thought much about the code that will
use it".

 

[James Kuyper]

I was commenting on "before having thought much about the code that will
use it".

I hadn't noticed before - that IS odd wording. It seems to conflate the
development sequence with sequence of statements in the code. By the
time you've finished writing the code, any lack of knowledge you had
when you first introduced a variable into your code should be irrelevant
to whether or not it's initialized at the point of definition.

However, not "having thought much" about a variable is not the same as
"not knowing how it would be used". In general, the very first thought I
have about a variable is "how it would be used". How it should be
initialized is often a much later thought.

 

[Ian Collins]

I hadn't noticed before - that IS odd wording. It seems to conflate the
development sequence with sequence of statements in the code. By the
time you've finished writing the code, any lack of knowledge you had
when you first introduced a variable into your code should be irrelevant
to whether or not it's initialized at the point of definition.

However, not "having thought much" about a variable is not the same as
"not knowing how it would be used". In general, the very first thought I
have about a variable is "how it would be used". How it should be
initialized is often a much later thought.

At the point of first use.

That way you always know how it is going to be used and what the correct
initial value is. No uninitialised variables to worry or warn about.
Well, OK, there are output parameter values which don't have a "correct"
initialisation value. These leave you with a choice of a compiler
warning or a dummy initial value.

 

[Öö Tiib]

At the point of first use.

That way you always know how it is going to be used and what the correct
initial value is. No uninitialised variables to worry or warn about.
Well, OK, there are output parameter values which don't have a "correct"
initialisation value. These leave you with a choice of a compiler
warning or a dummy initial value.

It depends how deeply people think before they type in some code.
Prevailing approach to programming seems to be to consider code
that passes some tests already "better than nothing" but also it may
be is still "not thought much about" like "how it should work when
that parameter is negative?". Warning about uninitialized variable can
help to draw attention to such case earlier. Dummy may also work but
give wrong results that will be discovered later.

 

[James Kuyper]

On 09/25/2013 05:17 PM, Ian Collins wrote:
....

Well, OK, there are output parameter values which don't have a "correct"
initialisation value. These leave you with a choice of a compiler
warning or a dummy initial value.

It is precisely such variables, and precisely that choice, which are the
subject of this sub-thread.

 

[Ian Collins]

It depends how deeply people think before they type in some code.
Prevailing approach to programming seems to be to consider code
that passes some tests already "better than nothing" but also it may
be is still "not thought much about" like "how it should work when
that parameter is negative?". Warning about uninitialized variable can
help to draw attention to such case earlier. Dummy may also work but
give wrong results that will be discovered later.

Did you actually read what I wrote? The only uninitialised variables I
mentioned were those used as output function parameters.

 

[Ian Collins]

On 09/25/2013 05:17 PM, Ian Collins wrote:
....

It is precisely such variables, and precisely that choice, which are the
subject of this sub-thread.

Really? I thought I was the first to mention them.

 

[Ben Bacarisse]

I recommend joining the modern world and using a C99 compiler.

Good advice but...

Then you
can write "int x = foo();" when you need it rather than declaring "int
x;" at the top of the function and assigning "x = foo();" later on.

You don't need C99 for that. It's valid in ANSI C (AKA C90). What ANSI
C forbids is non-constant initialisers for aggregate or union objects --
a restriction that is indeed lifted in C99.

All C versions require constant initialisers where the object has static
storage duration, but that's no the case being discussed.

 

[Les Cargill]

[snip]

One of the more useful things from OO is RAII - Resource
Allocation Is Initialization.

RAII is a C++ -ism. It has nothing to do with OOP.

Historically, yes. It's crept out of only that pond.

Sometimes I think the only reason there is OO is to
provide opportunities for the "no true Scotsman" ... thing.

 

[James Kuyper]

James Kuyper wrote: ....

At the point of first use.

That way you always know how it is going to be used and what the correct
initial value is. No uninitialised variables to worry or warn about.

It's not uncommon for the point of first use to be a location where you
can't define the variable because doing so would give it the wrong
scope. For instance, first use might occur inside a block, even though
the variable must have a scope that extends outside that block. Such a
variable's definition would need to be in an outer scope, and would need
to occur before entry into that block - which might means that the
definition will be reached before the program can determine what value
it should have at the point of first use. Therefore, your criterion does
not solve the problem of whether, and how, such variables should be
initialized.

Well, OK, there are output parameter values which don't have a "correct"
initialisation value. These leave you with a choice of a compiler
warning or a dummy initial value.

When I first read that message, I didn't notice your restriction of that
comment to "output parameter values", and therefore misinterpreted that
statement as meaning something quite different - I've cancelled the
message that I wrote reflecting that misunderstanding, but cancellation
requests are only occasionally honored, and I see that you've already
responded to it.

Now that I've noticed that restriction, I'm not quite sure what you're
talking about. An "output" parameter value suggests to me that you're
talking about a pointer parameter used to write the output to the
pointed-at location. The parameter itself is initialized by copying from
the corresponding function argument. The compiler has no way of knowing
whether or not the memory it points is uninitialized, and therefore
can't warn you about the possibility of using uninitialized memory.
Therefore, you don't need to provide a dummy initial value to shut up
that warning, which is good, because you're also not allowed to provide one.

Therefore, I've almost certainly misunderstood the situation you're
describing. Could you expand on your comment a little? A concrete
example might be helpful.

 

[James Kuyper]

Good advice but...


You don't need C99 for that. It's valid in ANSI C (AKA C90).

In C90, you could put it at the top of any block, not just at the top of
the outermost block of a function. However, you do need C99 or later to
put it anywhere other than at the top of a block. I'm not sure whether
"the top of a block" is the right wording, since I don't have a copy of
that version of the standard; I only know that the restriction has been
removed from C99 and later.

 

[Ian Collins]

It's not uncommon for the point of first use to be a location where you
can't define the variable because doing so would give it the wrong
scope. For instance, first use might occur inside a block, even though
the variable must have a scope that extends outside that block. Such a
variable's definition would need to be in an outer scope, and would need
to occur before entry into that block - which might means that the
definition will be reached before the program can determine what value
it should have at the point of first use. Therefore, your criterion does
not solve the problem of whether, and how, such variables should be
initialized.

Yes and no. Such cases tend to require a means to determine whether the
value was correctly assigned, so a known default initial values is
required. I'm thinking of this style:

int result = FAIL;

if (someCondition)
{
// do something to get the result;
}
else
{
// do something else to get the result;
}

return result;

In most cases, this situation is a hint to extract the code in the block
into a separate function which will either remove the need for the
variable, or allow it to be initialised with the result of the function.

When I first read that message, I didn't notice your restriction of that
comment to "output parameter values", and therefore misinterpreted that
statement as meaning something quite different - I've cancelled the
message that I wrote reflecting that misunderstanding, but cancellation
requests are only occasionally honored, and I see that you've already
responded to it.

Now that I've noticed that restriction, I'm not quite sure what you're
talking about. An "output" parameter value suggests to me that you're
talking about a pointer parameter used to write the output to the
pointed-at location. The parameter itself is initialized by copying from
the corresponding function argument. The compiler has no way of knowing
whether or not the memory it points is uninitialized, and therefore
can't warn you about the possibility of using uninitialized memory.
Therefore, you don't need to provide a dummy initial value to shut up
that warning, which is good, because you're also not allowed to provide one.

Therefore, I've almost certainly misunderstood the situation you're
describing. Could you expand on your comment a little? A concrete
example might be helpful.

I was referring to a parameter used for an additional return value.
Something like

int doSomething( T* someStuff, int* someSize );

where someSize is filled in by the function.