Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #62931 > unrolled thread

Do variables need to be initialized?

Back to article view | Back to comp.lang.c

Contents

  Do variables need to be initialized? fl <rxjwg98@gmail.com> - 2015-06-01 16:48 -0700
    Re: Do variables need to be initialized? Richard Heathfield <rjh@cpax.org.uk> - 2015-06-02 00:55 +0100
      Re: Do variables need to be initialized? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-06-01 18:22 -0600
        Re: Do variables need to be initialized? Keith Thompson <kst-u@mib.org> - 2015-06-02 08:05 -0700
          Re: Do variables need to be initialized? Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:07 -0700
            Re: Do variables need to be initialized? Keith Thompson <kst-u@mib.org> - 2015-07-11 16:47 -0700
              Re: Do variables need to be initialized? Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 07:42 -0700
        Re: Do variables need to be initialized? Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:03 -0700
    Re: Do variables need to be initialized? David Brown <david.brown@hesbynett.no> - 2015-06-02 09:15 +0200
      Re: Do variables need to be initialized? Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:09 -0700
    Re: Do variables need to be initialized? David Kleinecke <dkleinecke@gmail.com> - 2015-06-03 09:30 -0700
      Re: Do variables need to be initialized? gwowen <gwowen@gmail.com> - 2015-06-03 09:41 -0700
        Re: Do variables need to be initialized? David Kleinecke <dkleinecke@gmail.com> - 2015-06-04 10:17 -0700
          Re: Do variables need to be initialized? Stephen Sprunk <stephen@sprunk.org> - 2015-06-05 11:10 -0500
            Re: Do variables need to be initialized? Bartc <bc@freeuk.com> - 2015-06-05 18:22 +0100
              Re: Do variables need to be initialized? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-06-05 20:54 -0600
                Re: Do variables need to be initialized? Ian Collins <ian-news@hotmail.com> - 2015-06-06 15:49 +1200
                  Re: Do variables need to be initialized? Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-06 08:42 +0100
                    Re: Do variables need to be initialized? Keith Thompson <kst-u@mib.org> - 2015-06-06 13:11 -0700
                      Re: Do variables need to be initialized? Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-07 16:58 +0100
                  Re: Do variables need to be initialized? Bartc <bc@freeuk.com> - 2015-06-06 11:01 +0100
                    Re: Do variables need to be initialized? Ian Collins <ian-news@hotmail.com> - 2015-06-07 09:07 +1200
                  Re: Do variables need to be initialized? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-06-06 15:06 -0600
                    Re: Do variables need to be initialized? gwowen <gwowen@gmail.com> - 2015-06-08 05:39 -0700
                      Re: Do variables need to be initialized? Bartc <bc@freeuk.com> - 2015-06-08 14:10 +0100
                        Re: Do variables need to be initialized? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-08 14:21 +0100
                          Re: Do variables need to be initialized? Bartc <bc@freeuk.com> - 2015-06-08 14:34 +0100
                            Re: Do variables need to be initialized? David Brown <david.brown@hesbynett.no> - 2015-06-08 16:51 +0200
                              Re: Do variables need to be initialized? Richard Heathfield <rjh@cpax.org.uk> - 2015-06-08 16:15 +0100
                              Re: Do variables need to be initialized? Bartc <bc@freeuk.com> - 2015-06-08 17:31 +0100
                                Re: Do variables need to be initialized? Ian Collins <ian-news@hotmail.com> - 2015-06-09 08:06 +1200
                                  Re: Do variables need to be initialized? Bartc <bc@freeuk.com> - 2015-06-08 22:58 +0100
                            Re: Do variables need to be initialized? Keith Thompson <kst-u@mib.org> - 2015-06-08 08:27 -0700
                        Re: Do variables need to be initialized? gwowen <gwowen@gmail.com> - 2015-06-08 08:01 -0700
              Re: Do variables need to be initialized? Stephen Sprunk <stephen@sprunk.org> - 2015-06-06 11:11 -0500
                Re: Do variables need to be initialized? Bartc <bc@freeuk.com> - 2015-06-06 19:09 +0100
                  Re: Do variables need to be initialized? Robert Wessel <robertwessel2@yahoo.com> - 2015-06-06 13:57 -0500
                    Re: Do variables need to be initialized? Keith Thompson <kst-u@mib.org> - 2015-06-06 13:52 -0700
                      Re: Do variables need to be initialized? James Kuyper <jameskuyper@verizon.net> - 2015-06-06 20:57 -0400
                  Re: Do variables need to be initialized? Stephen Sprunk <stephen@sprunk.org> - 2015-06-10 14:33 -0500
            Re: Do variables need to be initialized? Keith Thompson <kst-u@mib.org> - 2015-06-05 10:56 -0700

Page 1 of 3  [1] 2 3  Next page →

#62931 — Do variables need to be initialized?

Hi,

When I read a post on-line, my answer to the question is a 'yes'. It is a 
surprise. I have a strong impression that a variable must be given a value
before it is used. Otherwise, the garbage data will result in unpredictable
result. It perhaps the word 'initialized' definition in the post (except
 below) is different from mine. What is your opinion on its answer? 



Thanks,




Do variables need to be initialized?


No. All variables should be given a value before they are used, and a good
 compiler will help you find variables that are used before they are set to a
 value. Variables need not be initialized, however. Variables defined outside
 a function or defined inside a function with the static keyword are already
 initialized to 0 for you if you do not explicitly initialize them.

[toc] | [next] | [standalone]

#62932

On 02/06/15 00:48, fl wrote:
> Hi,
>
> When I read a post on-line, my answer to the question is a 'yes'.

[Subject line: "Do variables need to be initialized?"]

Answer: No, but read on.

> It is a
> surprise. I have a strong impression that a variable must be given a value
> before it is used.

If it isn't, the behaviour of the program is undefined. But a value can 
be given at a time later than initialisation:

int i; /* Declaration, yes. Definition, yes. Initialisation, no. */
i = 6; /* Assignment, not initialisation. */
printf("%d\n", i); /* writes 6 to stdout */

The thrust of your point is valid:
int j;
printf("%d\n",j); /* undefined behaviour */

but all that is required is that j be given a value before use, not that 
it be given a value at the time it is defined (which is what 
"initialise" means).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#62934

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 02/06/15 00:48, fl wrote:
>> Hi,
>>
>> When I read a post on-line, my answer to the question is a 'yes'.
>
> [Subject line: "Do variables need to be initialized?"]
>
> Answer: No, but read on.

<good answer snipped>

To elaborate on this just a bit:  The C language uses the word
"initialize" in a very specific way, which is narrower than the way most
programmers will.  When most of us talk informally about initializing a
variable, we'll refer to something like

int i;

i = 7; // occurs before we read the value of i

as initializing the variable.  This is, however, not how C uses the
term.  When you ask about variable initialization in C, you're referring
very specifically to saying something like

int i = 7;

[toc] | [prev] | [next] | [standalone]

#62952

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 02/06/15 00:48, fl wrote:
>>> Hi,
>>>
>>> When I read a post on-line, my answer to the question is a 'yes'.
>>
>> [Subject line: "Do variables need to be initialized?"]
>>
>> Answer: No, but read on.
>
> <good answer snipped>
>
> To elaborate on this just a bit:  The C language uses the word
> "initialize" in a very specific way, which is narrower than the way most
> programmers will.  When most of us talk informally about initializing a
> variable, we'll refer to something like
>
> int i;
>
> i = 7; // occurs before we read the value of i
>
> as initializing the variable.  This is, however, not how C uses the
> term.  When you ask about variable initialization in C, you're referring
> very specifically to saying something like
>
> int i = 7;

True, but the standard also uses the word "uninitialized" to refer to
objects that have neither been initialized or assigned to.

N1570 6.3.2.1p2:

    ... and that object is uninitialized (not declared with an
    initializer and no assignment to it has been performed prior
    to use) ...

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#65283

Keith Thompson <kst-u@mib.org> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> On 02/06/15 00:48, fl wrote:
>>>> Hi,
>>>>
>>>> When I read a post on-line, my answer to the question is a 'yes'.
>>>
>>> [Subject line:  "Do variables need to be initialized?"]
>>>
>>> Answer:  No, but read on.
>>
>> <good answer snipped>
>>
>> To elaborate on this just a bit:  The C language uses the word
>> "initialize" in a very specific way, which is narrower than the way most
>> programmers will.  When most of us talk informally about initializing a
>> variable, we'll refer to something like
>>
>> int i;
>>
>> i = 7; // occurs before we read the value of i
>>
>> as initializing the variable.  This is, however, not how C uses the
>> term.  When you ask about variable initialization in C, you're referring
>> very specifically to saying something like
>>
>> int i = 7;
>
> True, but the standard also uses the word "uninitialized" to refer to
> objects that have neither been initialized or assigned to.
>
> N1570 6.3.2.1p2:
>
>     ... and that object is uninitialized (not declared with an
>     initializer and no assignment to it has been performed prior
>     to use) ...

I believe there are also uses of initialize (ie, without 'un' at
the beginning) which correspond to covering assignment.  (I
looked this up once, I don't have any citations at my fingertips,
but if you decide to do a search I'd be interested to hear what
you find.)

[toc] | [prev] | [next] | [standalone]

#65367

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> True, but the standard also uses the word "uninitialized" to refer to
>> objects that have neither been initialized or assigned to.
>>
>> N1570 6.3.2.1p2:
>>
>>     ... and that object is uninitialized (not declared with an
>>     initializer and no assignment to it has been performed prior
>>     to use) ...
>
> I believe there are also uses of initialize (ie, without 'un' at
> the beginning) which correspond to covering assignment.  (I
> looked this up once, I don't have any citations at my fingertips,
> but if you decide to do a search I'd be interested to hear what
> you find.)

Searching for the word "initialize" (with no prefix or suffix), I see no
such cases; likewise for "initialized".  I may have missed something.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#65622

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>>> True, but the standard also uses the word "uninitialized" to refer to
>>> objects that have neither been initialized or assigned to.
>>>
>>> N1570 6.3.2.1p2:
>>>
>>>     ... and that object is uninitialized (not declared with an
>>>     initializer and no assignment to it has been performed prior
>>>     to use) ...
>>
>> I believe there are also uses of initialize (ie, without 'un' at
>> the beginning) which correspond to covering assignment.  (I
>> looked this up once, I don't have any citations at my fingertips,
>> but if you decide to do a search I'd be interested to hear what
>> you find.)
>
> Searching for the word "initialize" (with no prefix or suffix), I see no
> such cases;  likewise for "initialized".  I may have missed something.

I find the following (my apologies if some of the citations are off, I
copied them down but have not double checked):

    6.2.6.1 p5 (footnote)
    several in 7.16.1.x, of which 7.16.1.1 p2 is typical
    7.17.2.2 p2,3
    7.21.6.1 p8 (this is ambiguous, but certainly it looks like
                 it is not meant to be limited to declarators with
                 initializers)
    several in 7.21.6.x, of which 7.21.6.8 p2 is typical
    7.22.3.2 p2
    7.26.1 p3 (ambiguous similarly to 7.21.6.1 p8 is)
    7.29.2.1 p8 (ambiguous similarly to above)
    several in 7.29.2.x, of which 7.29.2.5 p2 is  typical
    7.29.6.{3,4} p1 (ambiguous similarly to above)
    F.8.3
    J.2 (I think these are all duplicates from previous sections)

I acknowledge none of these mentions assignment specifically, and
in some cases it's clear that assignment is not one of the
possibilities.  However, all of them use a form of initialize
that if either definitely not a declarator with an initializer,
or non-specific and probably not meant as limited to a declarator
with an initializer.

[toc] | [prev] | [next] | [standalone]

#65282

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 02/06/15 00:48, fl wrote:
>>> Hi,
>>>
>>> When I read a post on-line, my answer to the question is a 'yes'.
>>
>> [Subject line:  "Do variables need to be initialized?"]
>>
>> Answer:  No, but read on.
>
> <good answer snipped>
>
> To elaborate on this just a bit:  The C language uses the word
> "initialize" in a very specific way, which is narrower than the
> way most programmers will.  When most of us talk informally about
> initializing a variable, we'll refer to something like
>
> int i;
>
> i = 7; // occurs before we read the value of i
>
> as initializing the variable.  This is, however, not how C uses
> the term.  When you ask about variable initialization in C, you're
> referring very specifically to saying something like
>
> int i = 7;

This description isn't right.  Looking through the Standard, I
find the word "initialize" used both in the sense of a declarator
having an initializer and in the sense of performing a first
assignment, and in normative text as well as in informative text.
So that idea that "initialize" or "initialization" in C refers
only to declarators with initializers is contrary to how the
Standard uses the term.  Please look through the Standard and
see if you agree (or not).

[toc] | [prev] | [next] | [standalone]

#62940

On 02/06/15 01:48, fl wrote:
> Hi,
> 
> When I read a post on-line, my answer to the question is a 'yes'. It is a 
> surprise. I have a strong impression that a variable must be given a value
> before it is used. Otherwise, the garbage data will result in unpredictable
> result. It perhaps the word 'initialized' definition in the post (except
>  below) is different from mine. What is your opinion on its answer? 
> 
> 
> 
> Thanks,
> 
> 
> 
> 
> Do variables need to be initialized?
> 
> 
> No. All variables should be given a value before they are used, and a good
>  compiler will help you find variables that are used before they are set to a
>  value. Variables need not be initialized, however. Variables defined outside
>  a function or defined inside a function with the static keyword are already
>  initialized to 0 for you if you do not explicitly initialize them.
> 

In case this is not clear, this paragraph says that any data that exists
for the whole program's lifetime is initialised to 0 by default.  So any
global data, or file-scope static data, or function-scope static data,
is initialised to 0 before main() unless you have given it another
explicit initialisation.  But note that this is a form of initialisation
- it is implicit initialisation to 0.

Local variables in a function are not automatically initialised - you
need to make it explicit, or assign a value to them before using them
(as others have explained, this is technically not "initialisation"
according to the term in the C standards - but it does the same job and
generated code is usually the same).

And of course you only need to initialise the variable before using it
for /reading/.  Other forms of "use", such as writing to it or taking
its address or size, don't read the data in it, and therefore don't need
any initialisation.

[toc] | [prev] | [next] | [standalone]

#65284

David Brown <david.brown@hesbynett.no> writes:

> Local variables in a function are not automatically initialised -
> you need to make it explicit, or assign a value to them before using
> them (as others have explained, this is technically not
> "initialisation" according to the term in the C standards - [snip]

To repeat my answer to Joe Pfeiffer, this assertion is commonly
made but I believe it is incorrect.

[toc] | [prev] | [next] | [standalone]

#62962

On Monday, June 1, 2015 at 4:48:45 PM UTC-7, fl wrote:
> Hi,
> 
> When I read a post on-line, my answer to the question is a 'yes'. It is a 
> surprise. I have a strong impression that a variable must be given a value
> before it is used. Otherwise, the garbage data will result in unpredictable
> result. It perhaps the word 'initialized' definition in the post (except
>  below) is different from mine. What is your opinion on its answer? 
> 
> 
> 
> Thanks,
> 
> 
> 
> 
> Do variables need to be initialized?
> 
> 
> No. All variables should be given a value before they are used, and a good
>  compiler will help you find variables that are used before they are set to a
>  value. Variables need not be initialized, however. Variables defined outside
>  a function or defined inside a function with the static keyword are already
>  initialized to 0 for you if you do not explicitly initialize them.

One can adopt different styles. The two most noticeable are:
    1. always initialize
    2. never initialize
but the commonest strategy is more subtle
    3. initialize if there is an obvious initial value otherwise don't.

I don't think there are compelling reasons for requiring any of these
alternatives. I have been around and around in my own code. Today I
using convention 1. But only last week I was using 2. I think 1 wins
over 2 (but not necessarily over all other) because it reduces clutter 
and because it makes it easier to think of the local variables as 
members of a data object apart from the code (something I feel many 
other people are not interested in).

It's all a matter of style.

[toc] | [prev] | [next] | [standalone]

#62963

On Wednesday, June 3, 2015 at 5:30:50 PM UTC+1, David Kleinecke wrote:

> One can adopt different styles. The two most noticeable are:
>     1. always initialize
>     2. never initialize
> but the commonest strategy is more subtle
>     3. initialize if there is an obvious initial value otherwise don't.

...

> It's all a matter of style.

True, but ... in post C90 versions, where you can mix code and declarations, its often a good question to ask "if I don't know what the initial value is, why am I declaring it here?"  

There are many legitimate answers to that question, but its a neat guiding principle for code structure.  The most common thing I see:

int i;
if(ugly_condition()) {
  /* complicated calculation */
  i = this_result;
} else {
  /* alternative complicated calculation */
  i = that_result;
}

is screaming for to be replaced by a function call (or two).

[toc] | [prev] | [next] | [standalone]

#62974

On Wednesday, June 3, 2015 at 9:42:03 AM UTC-7, gwowen wrote:
> On Wednesday, June 3, 2015 at 5:30:50 PM UTC+1, David Kleinecke wrote:
> 
> > One can adopt different styles. The two most noticeable are:
> >     1. always initialize
> >     2. never initialize
> > but the commonest strategy is more subtle
> >     3. initialize if there is an obvious initial value otherwise don't.
> 
> ...
> 
> > It's all a matter of style.
> 
> True, but ... in post C90 versions, where you can mix code and declarations, its often a good question to ask "if I don't know what the initial value is, why am I declaring it here?"  
> 
> There are many legitimate answers to that question, but its a neat guiding principle for code structure.  The most common thing I see:
> 
> int i;
> if(ugly_condition()) {
>   /* complicated calculation */
>   i = this_result;
> } else {
>   /* alternative complicated calculation */
>   i = that_result;
> }
> 
> is screaming for to be replaced by a function call (or two).


Same points still apply. The C90 (and earlier) rule against mixing
declarations and statements was clearly wrong and I cannot imagine
why they imposed it. One reason it was silly is that mixing changes
nothing significant.

I agree about initialization where mixing is possible. I wouldn't 
mix even if I were writing C11 code but that's for reasons that have
nothing to do with initialization.

   int i = ugly_condition() ? /* complicated calculation */ :
            /* alternative complicated calculation */ ;
 
I've never actually seen that done - but it could be. And, of
course more tertiaries can be added to the string (you can replace
entire switch statements). I think this would be bad practice.

[toc] | [prev] | [next] | [standalone]

#62996

On 04-Jun-15 12:17, David Kleinecke wrote:
> On Wednesday, June 3, 2015 at 9:42:03 AM UTC-7, gwowen wrote:
>> David Kleinecke wrote:
>>> It's all a matter of style.
>> 
>> True, but ... in post C90 versions, where you can mix code and
>> declarations, its often a good question to ask "if I don't know
>> what the initial value is, why am I declaring it here?"
>> ...
>
> Same points still apply. The C90 (and earlier) rule against mixing 
> declarations and statements was clearly wrong and I cannot imagine 
> why they imposed it. One reason it was silly is that mixing changes 
> nothing significant.

AIUI, early compilers worked line-by-line, and they needed all the
declarations in one place so they could set up the stack frame before
translating the following statements into code.  If a declaration came
later, then there would be no space left in the stack frame to put the
variable, and they couldn't go back and increase the frame size because
they'd already output the frame setup code--and the code in between that
assumed a particular frame size.

Once you can assume optimizing compilers that look at entire functions
(or at least blocks) before outputting anything, mixing declarations and
statements is an obvious improvement.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#62997

On 05/06/2015 17:10, Stephen Sprunk wrote:
> On 04-Jun-15 12:17, David Kleinecke wrote:

>> Same points still apply. The C90 (and earlier) rule against mixing
>> declarations and statements was clearly wrong and I cannot imagine
>> why they imposed it.

I can.

> One reason it was silly is that mixing changes
>> nothing significant.
>
> AIUI, early compilers worked line-by-line, and they needed all the
> declarations in one place so they could set up the stack frame before
> translating the following statements into code.

That seems to be still the case, in that functions need to be declared 
before use (or at least, will cause problems if they're not).

>  If a declaration came
> later, then there would be no space left in the stack frame to put the
> variable, and they couldn't go back and increase the frame size because
> they'd already output the frame setup code--and the code in between that
> assumed a particular frame size.

That sounds very unlikely, unless somehow all the code for one function 
didn't fit into memory. How did they manage to do a forward jump without 
knowing what the offset was going to be? Same sort of thing, and 
actually harder than the frame size problem

> mixing declarations and
> statements is an obvious improvement.

In some people's view. Not in others'. Take file-scope variables and 
macros and other declarations usually placed before all the function 
definitions. Now imagine them disseminated throughout the file, placed 
just before the first function they are referenced. It would look terrible.

Or take function parameters. Instead of listing them in the function 
signature, just declare them at various points in the body of the 
function, just before they are needed (there would need to be some way 
to denote they are parameters for the function).

That would also be a terrible idea. So why is untidily mixing up 
declarations and statements in the function body a good one? Also, what 
happens here:

int a=1,b,c;

if (a==1) {
    a=2;
    b=a;
    int a=3;
    c=a;
}

which a is which in that inner block? If you had a big, sprawling block, 
you would need to examine it in minute detail to see if there's a 
declaration lurking which completely changes the meaning of an 
identifier used later in the block. (I don't like nested block 
declarations either.)

 > Once you can assume optimizing compilers that look at entire functions
 > (or at least blocks) before outputting anything,

You don't need an optimising compiler to not generate code until an 
entire function has been processed! Surely that is normally going to be 
the case in pretty much any compiler?

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#63002

> On 05/06/2015 17:10, Stephen Sprunk wrote:
>
>> mixing declarations and
>> statements is an obvious improvement.

When mixing became possible I tried it on a couple of projects and
concluded I hate it.  I want to be able to look in one place for my
variables' declarations, not have to go searching through the function.

[toc] | [prev] | [next] | [standalone]

#63004

Joe Pfeiffer wrote:
>> On 05/06/2015 17:10, Stephen Sprunk wrote:
>>
>>> mixing declarations and
>>> statements is an obvious improvement.
>
> When mixing became possible I tried it on a couple of projects and
> concluded I hate it.  I want to be able to look in one place for my
> variables' declarations, not have to go searching through the function.

If you have to search, the function is too long.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#63006

Ian Collins <ian-news@hotmail.com> writes:

> Joe Pfeiffer wrote:
>>> On 05/06/2015 17:10, Stephen Sprunk wrote:
>>>
>>>> mixing declarations and
>>>> statements is an obvious improvement.
>>
>> When mixing became possible I tried it on a couple of projects and
>> concluded I hate it.  I want to be able to look in one place for my
>> variables' declarations, not have to go searching through the function.
>
> If you have to search, the function is too long.

I have a couple of enormous "dispatcher" functions which are basically
just switch statements.

Sometimes I need to keep a value for a short while:

case seventeenth_case:
     x = Get_Me_An_Item();
     Log_Item(x);
     Process_Item(x);
     break;

Cases 23 and 61 might also need a temporary variable of the same type.

I agonise far too much between:

char x;
...
case seventeenth_case:
     x = Get_Me_An_Item();
     Log_Item(x);
     Process_Item(x);
     break;

and

case seventeenth_case:
     char x17 = Get_Me_An_Item();
     Log_Item(x17);
     Process_Item(x17);
     break;
...
case twentythird_case:
     char x23 = Get_Me_An_Item();
     Save_Copy_Of_Item(x23);
     Destroy_Item(x23);
     break;

and

case seventeenth_case:
{
     char x = Get_Me_An_Item();
     Log_Item(x);
     Process_Item(x);
     break;
}

(obviously, if 17,23 and 61 are identical I should put the variable and
the three calls in a function).

And in the third case I then get myself in stylistic panic about whether
the break should be inside or outside the braces.

[toc] | [prev] | [next] | [standalone]

#63026

Dr Nick <nospam-4@temporary-address.org.uk> writes:
[...]
> case seventeenth_case:
>      char x17 = Get_Me_An_Item();
>      Log_Item(x17);
>      Process_Item(x17);
>      break;
> ...
> case twentythird_case:
>      char x23 = Get_Me_An_Item();
>      Save_Copy_Of_Item(x23);
>      Destroy_Item(x23);
>      break;
>
> and
>
> case seventeenth_case:
> {
>      char x = Get_Me_An_Item();
>      Log_Item(x);
>      Process_Item(x);
>      break;
> }
>
> (obviously, if 17,23 and 61 are identical I should put the variable and
> the three calls in a function).

No need for that:

    case seventeenth_case:
    case twentythird_case:
    case sixtyfirst_case:
        common_code;
        break;

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#63039

Keith Thompson <kst-u@mib.org> writes:

> Dr Nick <nospam-4@temporary-address.org.uk> writes:
> [...]
>> case seventeenth_case:
>>      char x17 = Get_Me_An_Item();
>>      Log_Item(x17);
>>      Process_Item(x17);
>>      break;
>> ...
>> case twentythird_case:
>>      char x23 = Get_Me_An_Item();
>>      Save_Copy_Of_Item(x23);
>>      Destroy_Item(x23);
>>      break;
>>
>> and
>>
>> case seventeenth_case:
>> {
>>      char x = Get_Me_An_Item();
>>      Log_Item(x);
>>      Process_Item(x);
>>      break;
>> }
>>
>> (obviously, if 17,23 and 61 are identical I should put the variable and
>> the three calls in a function).
>
> No need for that:
>
>     case seventeenth_case:
>     case twentythird_case:
>     case sixtyfirst_case:
>         common_code;
>         break;
>
> [...]

True.  Unless I really want to order them or something.  That's what
comes of adding a parenthetical aside!

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web