why do some writers declare and define variables separately

[yoodavid]

Can anyone tell me why some writers decide to declare and
write definitions for variables separately, rather than
together?

That is:
int definelater;
...
definelater = 0;

rather than:
int definelater = 0;

wouldn't the later reduce code lines?
thanks.
--
to authenticate is not to authorize. be responsible.
--
comp.lang.c.moderated - moderation address: cl...@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[mt]

I don't really know, and I am sure there is a good explanation for it. But from my own coding experience, I prefer to initialize variables when I declare them because if you don't, it may be some random number and you could use it and not get an error that its being used.

[James Kuyper]

On 10/03/2013 02:37 PM, mt wrote:
...

> I don't really know, and I am sure there is a good explanation for it. But from my own coding experience, I prefer to initialize variables when I declare them because if you don't, it may be some random number and you could use it and not get an error that its being used.

I prefer to leave variables uninitialized if I cannot initialize them
with the value they're supposed to have the next time their value is
read. That's because any decent compiler will give you a warning if its
analysis of the code flow suggests that there's a possibility of the
value of that variable being read before it gets written. Initializing a
variable with a value that's not actually intended to be used turns off
that warning, because the compiler doesn't know that you don't intend it
to be used.
--
James Kuyper

[ThosRTanner]

On Tuesday, October 8, 2013 10:38:14 PM UTC+1, James Kuyper wrote:
> I prefer to leave variables uninitialized if I cannot initialize them
> with the value they're supposed to have the next time their value is
> read. That's because any decent compiler will give you a warning if its
> analysis of the code flow suggests that there's a possibility of the
> value of that variable being read before it gets written. Initializing a
> variable with a value that's not actually intended to be used turns off
> that warning, because the compiler doesn't know that you don't intend it
> to be used.

I have to say I prefer the other way round, and also to keep the declarations in as small a scope as possible (i.e. only in the block, rather than declaring every variable ever used at the top of the function). Given you have a decent compiler, it should be able to tell you that you have assigned a value to a variable without using it as well as reading before initialising.

[Jens Schmidt]

ThosRTanner wrote:

> On Tuesday, October 8, 2013 10:38:14 PM UTC+1, James Kuyper wrote:
>> I prefer to leave variables uninitialized if I cannot initialize them
>> with the value they're supposed to have the next time their value is
>> read. That's because any decent compiler will give you a warning if its
>> analysis of the code flow suggests that there's a possibility of the
>> value of that variable being read before it gets written. Initializing a
>> variable with a value that's not actually intended to be used turns off
>> that warning, because the compiler doesn't know that you don't intend it
>> to be used.
>
> I have to say I prefer the other way round, and also to keep the
> declarations in as small a scope as possible (i.e. only in the block,
> rather than declaring every variable ever used at the top of the
> function). Given you have a decent compiler, it should be able to tell you
> that you have assigned a value to a variable without using it as well as
> reading before initialising.

Here is an example of an algorithm where you can neither declare the
variable in the innermost block where it is used nor intitialize with a
good value. I have yet to see a compiler which is able to detect that there
is no read-before-write here.

int f (int x, int *ax, int n)
{
int i;

assert (0 < x && x < n);
for (j = 0; j < n; ++j) {
if (j > x)
g (i, ax[j]);
if (j == x)
i = h (ax[j]);
}
}

The variable i must be declared before the loop, and inside the read
of i is statically before the write, but never dynamically before a
previous execution of the body did the write. Unfotunately I forgot
what the algorithm was good for. :-(
--
Greetings,
Jens Schmidt

[Francis Glassborow]

On 22/10/2013 22:36, ThosRTanner wrote:
> On Tuesday, October 8, 2013 10:38:14 PM UTC+1, James Kuyper wrote:
>> I prefer to leave variables uninitialized if I cannot initialize them
>> with the value they're supposed to have the next time their value is
>> read. That's because any decent compiler will give you a warning if its
>> analysis of the code flow suggests that there's a possibility of the
>> value of that variable being read before it gets written. Initializing a
>> variable with a value that's not actually intended to be used turns off
>> that warning, because the compiler doesn't know that you don't intend it
>> to be used.
>
> I have to say I prefer the other way round, and also to keep the declarations in as small a scope as possible (i.e. only in the block, rather than declaring every variable ever used at the top of the function). Given you have a decent compiler, it should be able to tell you that you have assigned a value to a variable without using it as well as reading before initialising.
>

In the long distant past (in computer terms where a second is a long
time) local variables had to be declared at the start of a block where
they were used. This meant that that either you had to delay
initialisation until you could provide a valid value or you had to
create ever more deeply nested blocks.

More recently the rules have been changed so that variables can be
declared, defined and initialised (largely) at the point of first use.
That means that we can almost always delay definition until we are ready
to initialise.

By the way, the difference between declaration and definition is NOT
whether the variable is initialised or not. Declarations introduce
names but do not create the object named. Definitions create objects and
attach a name. It is not possible (I think) to write a definition that
is not a declaration but it is possible to write declarations that are
not definitions:

void foo(void);

declares foo to be the name of a function that takes no arguments and
returns nothing.

void foo(void){}

defines a function that takes no arguments and returns nothing and binds
the result to the name foo which is also declared by that statement. If
foo has previously been declared the implementation will attempt to link
the two declarations.

extern int i;

Declares that i is the name of an int but does not create an int object
(that is simplified because C has a number of extra rules to confuse the
simple minded :)

int i;

Defines an uninitialised int (i.e. assigns storage for an int value but
does not initialise it) and then binds the name i to that storage.

[Hans-Bernhard Bröker]

On 25.10.2013 03:10, Francis Glassborow wrote:

> int i;
>
> Defines an uninitialised int (i.e. assigns storage for an int value but
> does not initialise it) and then binds the name i to that storage.

Actually that's only one of four things the above line can mean.

The above is correct only if that line appears inside a statement block.
In that case it defines an automatic, block-scoped, un-initializaed
variable.

If that line appears inside a struct or union type declaration, it
declares an element of said struct or union type.

If the same line appears outside any block, it can do one of two things:

a) it can define a variable of static duration and external linkage,
with implied initialization to zero, or
b) it can act the same as if you had written "extern int i;", i.e. be a
pure declaration.

The distinction between a) and b) is ruled by the somewhat complicated
concept of a "tentative definition".