why do some writers declare and define variables separately

Discussion in 'C Programming' started by yoodavid, Sep 18, 2013.

  1. yoodavid

    Ian Collins Guest

    Gordon Burditt wrote:

    Don't snip attributions if you reply.
    Yeah right. Utter nonsense.
    Why on Earth would you introduce a variable if you don't know how it
    would be used?
     
    Ian Collins, Sep 25, 2013
    #21
    1. Advertisements

  2. yoodavid

    Öö Tiib Guest

    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.
    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.
     
    Öö Tiib, Sep 25, 2013
    #22
    1. Advertisements

  3. yoodavid

    James Kuyper Guest

    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.
     
    James Kuyper, Sep 25, 2013
    #23
  4. yoodavid

    Noob Guest

    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.
     
    Noob, Sep 25, 2013
    #24
  5. yoodavid

    James Kuyper Guest

    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.
     
    James Kuyper, Sep 25, 2013
    #25
  6. C2011.
     
    Keith Thompson, Sep 25, 2013
    #26
  7. According to the Official Definition of OOP -- which exists where,
    exactly?
     
    Keith Thompson, Sep 25, 2013
    #27
  8. 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
     
    glen herrmannsfeldt, Sep 25, 2013
    #28
  9. yoodavid

    Ian Collins Guest

    I was commenting on "before having thought much about the code that will
    use it".
     
    Ian Collins, Sep 25, 2013
    #29
  10. yoodavid

    James Kuyper Guest

    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.
     
    James Kuyper, Sep 25, 2013
    #30
  11. yoodavid

    Ian Collins Guest

    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.
     
    Ian Collins, Sep 25, 2013
    #31
  12. yoodavid

    Öö Tiib Guest

    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.
     
    Öö Tiib, Sep 25, 2013
    #32
  13. yoodavid

    James Kuyper Guest

    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.
     
    James Kuyper, Sep 25, 2013
    #33
  14. yoodavid

    Ian Collins Guest

    Did you actually read what I wrote? The only uninitialised variables I
    mentioned were those used as output function parameters.
     
    Ian Collins, Sep 25, 2013
    #34
  15. yoodavid

    Ian Collins Guest

    Really? I thought I was the first to mention them.
     
    Ian Collins, Sep 25, 2013
    #35
  16. Good advice but...
    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.
     
    Ben Bacarisse, Sep 25, 2013
    #36
  17. yoodavid

    Les Cargill Guest

    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.
     
    Les Cargill, Sep 25, 2013
    #37
  18. yoodavid

    James Kuyper Guest

    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.
    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, Sep 25, 2013
    #38
  19. yoodavid

    James Kuyper Guest

    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.
     
    James Kuyper, Sep 25, 2013
    #39
  20. yoodavid

    Ian Collins Guest

    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.
    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.
     
    Ian Collins, Sep 26, 2013
    #40
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.