why do some writers declare and define variables separately

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

  1. yoodavid

    James Kuyper Guest

    So far, so good - that's what I thought you were talking about - until I
    got to the sentence "These leave you with a choice of a compiler warning
    or a dummy initial value." How does that sentence apply to someSize?
    What would the compiler be warning about? How and why would the dummy
    initial value be given? To put it another way, what would code look like
    that corresponds to the two choices you mentioned?
     
    James Kuyper, Sep 26, 2013
    #41
    1. Advertisements

  2. yoodavid

    Ian Collins Guest

    The example I was thinking of:

    int n;
    int result = doSomething( someBuffer, &n );

    Doesn't generate any warnings. I'm sure I've seen used before assigned
    warnings either from lint or gcc in such cases.
     
    Ian Collins, Sep 26, 2013
    #42
    1. Advertisements

  3. yoodavid

    James Kuyper Guest

    On 09/26/2013 03:10 AM, David Brown wrote:
    ....
    Not exactly. It's only in the block-item-list of a compound statement
    that declarations and statements are interchangeable. In all of the
    other contexts where a statement is allowed, a declaration is not allowed:

    label: statement
    case 1: statement
    default: statement

    if(x) statement
    else statement
    switch (y) statement
    while(z) statement
    do statement while(a);
    for(int i=0; i<n; i++) statement

    Of course, a compound statement is itself a statement, and can therefore
    be put in any of those locations, and can contain a declaration - but
    you can't put in a bare declaration in any of those locations.

    I confess to being surprised by the first three examples. If I hadn't
    bothered checking, I would have expected to be able to put bare
    declarations in those locations. Having to wrap such a declaration in a
    compound statement would limit its scope to that compound statement.
    However, an empty statement followed by a declaration is permitted, and
    would have the same practical effect as allowing a declaration in those
    locations, so it's not an onerous restriction, just a surprising one (at
    least to me).

    For each of the last six examples, the statement is also a block, which
    means that if a declaration were allowed there, the scope of the
    declaration would end at the terminating semi-colon. Such a declaration
    would be completely useless (except for any side-effects of the
    initializers) which is probably why declarations are not allowed in
    those locations.

    In C++, declarations are statements, and as such are allowed in all of
    those locations. That makes more sense in C++ than it would in C,
    because a simple declaration of an object that goes out of scope
    immediately can still be a very active piece of code, because of the
    automatically invoked constructor and destructor.
     
    James Kuyper, Sep 26, 2013
    #43
  4. yoodavid

    James Kuyper Guest

    An empty statement is a statement, and as such can be the statement that
    immediately follows a label. Any following declaration would simply be
    the next block-item in the block-item-list of the enclosing compound
    statement. As such, it's prohibited only if such a block-item would not
    be allowed. The only example I can think of would be:

    do
    loop_body: x++;
    int j;
    while(a>3);

    The 'int j;' declaration is not allowed int that location, but a
    statement would be equally disallowed, and it has nothing to do with the
    statement label. It's because that labeled expression-statement is the
    entire statement controlled by the do-statement, and the next token is
    therefore required to be "while".

    Something that's almost an example of a prohibited declaration after a
    labeled statement would be:

    if(a)
    case 3: x = z-y;
    double d;
    else
    y = z-x;

    The declaration is not itself a problem, but it is parsed as the next
    block-item after a complete if() statement, rendering the 'else' keyword
    a syntax error. Again, a statement would be just as much of a problem as
    a declaration, and the "case 3:" label has nothing to do with it.
    The presence of a labeled statement does make it possible to jump over
    the initialization of an object with automatic storage duration. That
    would causes problems if an attempt were made to read the uninitialized
    value of such an object. However, it's the declarations that precede the
    label that are dangerous. There's no special issues with the
    declarations that follow it. As a result, there's no particularly good
    reason for prohibiting a label on a declaration; I suspect the committee
    didn't even think about that issue when they decided to allow mixing of
    declarations and statements.
     
    James Kuyper, Sep 26, 2013
    #44
  5. yoodavid

    Phil Carmody Guest

    One of you appears to be talking about one of the two things there
    and the other appears to be talking about the other of the two things
    there. Perhaps if you used terms like "the former" and "the latter"
    then there might be less confusion as to what you're talking about,
    and there'd be less violent agreement.

    Phil
     
    Phil Carmody, Sep 26, 2013
    #45
  6. yoodavid

    Phil Carmody Guest

    I once had my manager reassure me that my yearly -20 kloc
    "productivity" (in a 500 kloc "module" - hah!) wouldn't
    be a problem in my yearly review. I was reassured my his
    manager a while later that it indeed wouldn't be a problem.
    A little while later, I was told not to do it again by both
    of them, as they found it hard to explain to the manager a
    layer above them.

    Lesson: If you're going to remove sprawling buggy code, at
    least replace it with clean compact code plus some additional
    function that plots a mandelbrot set, and a Conway's life
    simulation, so that the metrics don't show a massive debt.

    I'm pleased to say I wasn't payed by "productivity",
    but fear that I was in an environment where others were.
    Stupid, but matching the evidence.

    Surprised anything worked...
    Phil
     
    Phil Carmody, Sep 26, 2013
    #46
  7. yoodavid

    Phil Carmody Guest

    I remember several counter examples to that, as Keith called him
    out on it. However, by that stage he was already nesting down in
    my killfile, and this just confirmed that he had no interest in
    communicating on this medium the way that we've been used
    to for the last few decades. I'm sure he has a rad tattoo on
    his nasal septum, and called his first child Yoo'neeque too.

    Whatever.

    Ain't nobody got time for that shit.

    Phil
     
    Phil Carmody, Sep 26, 2013
    #47
  8. Some people find that the latter style obscures the code, especially if
    you declare many variables at once, and especially if some of your
    initializations have side effects. In addition, early initialization
    hides certain logic bugs by replacing a "use before initialization",
    which most compilers will catch, with a "use after initialization but
    before assignment of a meaningful value", which they won't.

    DES
     
    Dag-Erling Smørgrav, Oct 3, 2013
    #48
  9. yoodavid

    James Kuyper Guest

    For the sake of readability (and ease of maintenance) I usually put each
    variable's definition on a different line, whether or not they were
    initialized. I also normally line up the variable names. With those
    changes, the distinction you make pretty thoroughly disappears:

    int a = 4;
    int b = -23;
    int c = __RESERVED_IDENTIFIER;
    float f = 0.0F;
    float *d = NULL;
    I normally just do a text search backwards from the point of use. I
    don't find that particularly mind-numbing, even in code like your second
    version.
    There are strong differences of opinion on this matter - otherwise,
    support for that feature would not have been added to both C++ and C99,
    both evolving from C90.

    The strongest argument I've seen given for your point of view is that
    declaring them elsewhere it makes it harder to find the variable's
    declarations. Personally, I find variables more easily when their
    definitions are closer to the point of use; but with a backwards text
    search, it's seldom very difficult to find a variable (unless you gave
    it a bad name - I never define any identifiers shorter than three
    characters, and I try to avoid defining identifiers that are subsets of
    other identifiers).

    It's also far easier to initialize them with a value that will actually
    be used. In some cases, that will allow you to declare them const.
     
    James Kuyper, Oct 3, 2013
    #49

  10. By "rules", I assume you are referring to syntactic constructs such as initializer lists?

    In C, what are the semantic differences between initialisation and assignment?

    - Anand

    PS: I've tried to format my post as best as I can. Sorry in advance if Google messes it up.
     
    Anand Hariharan, Oct 3, 2013
    #50
  11. Yes, but I meant all the rules -- semantic ones as well.
    For variables with simple scalar types, at block scope, in modern C, the
    rules are very similar. The only difference of note is that you can
    initialise a const scalar, but you can't assign to one.

    If the object is not a simple scalar, is at file scope, or you are using
    old ANSI C, the differences start to multiply. I wouldn't like to try
    to list them all.

    No, you seemed to have tamed the beast. Did you have to do lots of hand
    editing?
     
    Ben Bacarisse, Oct 4, 2013
    #51
  12. yoodavid

    Tim Rentsch Guest

    Quoting https://en.wikipedia.org/wiki/Object-oriented_programming -

    The Smalltalk language, which was developed at Xerox PARC
    (by Alan Kay and others) in the 1970s, introduced the term
    /object-oriented programming/ to represent the pervasive use
    of objects and messages as the basis for computation. [...]
    Smalltalk and with it OOP were introduced to a wider
    audience by the August 1981 issue of Byte Magazine.

    I think it is fair to say that these statements represent the
    generally accepted view in the Computer Science community.
     
    Tim Rentsch, Oct 22, 2013
    #52
  13. It seems Simula [0] wins for first object oriented computer language. Even
    the inventor of C++ Bjarne Stroustrup talks about Simula this way [1] [2]
    and influencing his worldview.

    If you prefer to fight "wikipedia wars" then this page [3] says Simula was
    the first OO language. This is no proof for me but [1] and [2] are.

    Olle

    [0] http://staff.um.edu.mt/jskl1/talk.html
    [1] http://www.stroustrup.com/hopl-almost-final.pdf
    [2] http://www.stroustrup.com/hopl2.pdf
    [3] https://en.wikipedia.org/wiki/Simula
     
    Olle Villesen, Oct 22, 2013
    #53
  14. yoodavid

    Tim Rentsch Guest

    That's an interesting reaction. Probably there is some truth
    to it for some people. But I don't think it's universally
    true, drawing an analogy with other significant programming
    paradigms -

    Being able to write a program in Scheme (or ML, or Haskell) is
    not the same as understanding functional programming.

    Being able to write a program in Prolog is not the same as
    understanding logic programming.

    Being able to write a program in C++ (or Objective C, or Eiffel,
    or Smalltalk) is not the same as understanding object-oriented
    programming.

    Similarly, some programmers never understand C as anything more
    than a glorified assembler, but such people -- even though they
    may be quite good at low level work -- don't have the same grasp
    as those who understand large-scale procedural programming.
     
    Tim Rentsch, Oct 22, 2013
    #54
  15. yoodavid

    Martin Shobe Guest

    I don't know about that. In the past, there was another view based off
    the SIMULA language (as pointed out elsethread). I suspect, if it's been
    settled at all, that it's currently an amalgamation of the two views.

    Martin Shobe
     
    Martin Shobe, Oct 22, 2013
    #55
  16. yoodavid

    Tim Rentsch Guest

    Lots of people make the mistake of thinking object-oriented
    programming is simply a set of language features. Often
    the thinking goes something like this:

    1. C++ is an object-oriented language.
    2. C++ has feature X (perhaps part of class definitions).
    3. Therefore, feature X is object-oriented.

    Obviously inferences like the above are bogus. The C language
    has functions, but that doesn't make C a functional programming
    language. If we took a functional language and added exception
    handling to it, even if the exception mechanisms affected
    functions in some way that doesn't mean exception handling
    becomes part of functional programming. The relevant question
    is not whether the paradigm of object-oriented programming can
    evolve, but whether something like destructors does anything
    to evolve it. They haven't.
    At the risk of appearing immodest, try this google search
    (including the quotes):

    "object-oriented programming will be in the 1980s"

    Is it now fair to ask what is your ground for your statements?
     
    Tim Rentsch, Oct 23, 2013
    #56
  17. yoodavid

    Öö Tiib Guest

    Encapsulation is /the/ fundamental feature (not feature like 'if-else' statement). Without
    destructors it is annoyingly complex (but possible) to encapsulate precious resources
    (like threads, file descriptors, sockets etc.) Have you tried? In language with
    exceptions?

    I did not say things like:
    Why you snip what I said and post such fallacious logic and then argue against it?
    A feature that makes it possible to have firm encapsulation is very handy for
    OOP. That I have already elaborated.
    Pointless to be too modest anyway. I have read that before and I agree. Lot of people do not see
    farther from features. Generally a language does not matter. Lack of features is often annoying
    inconvenience. That may make OOP hard or ugly but never impossible. You need trees for
    forest. Pine is tree. Therefore pine can be part of forest.
    You have snipped my elaboration and links. Do you here ask to repost them? Or do you want
    my publications? I publish nothing. I make software. I am practicing engineer not teacher. Posting
    to usenet just for amusement.
     
    Öö Tiib, Oct 23, 2013
    #57
  18. It fits when there is a useful concept of lifetime, but, to take one
    example, Smalltalk has garbage collection, and there is no concept of
    the lifetime of an object that is of any use to the programmer.

    In another post (it's a shame I can't reply to both at once) you mention
    the huge benefit of destructors in resource management (open file,
    dynamically allocated memory and so on). Where the language has the
    right concepts, this is true, but it does not imply an object-oriented
    language. One can image C+exceptions in which a variable can be tagged
    with code to be executed at the end of its lifetime:

    FILE *fp = NULL on byebye = { if (fp) fclose(fp); }

    We'd have destructors, but not OO. In other words, the two concepts are
    orthogonal. Destructors may not even make sense in an object-oriented
    language, and they may be present in one that is not OO.

    Obviously C++ relates the two by being object-oriented (in part) and by
    having destructors, but that does not mean there is any logical
    connection between the two concepts.
     
    Ben Bacarisse, Oct 23, 2013
    #58
  19. yoodavid

    Tim Rentsch Guest

    There is no question that Simula 67 has classes and inheritance,
    and also predates Smalltalk. Calling it the first object-oriented
    language, however, is historical revisionism - the term "object-
    oriented programming" didn't exist until Alan Kay coined it, and
    the standalone adjective "object-oriented" came along only after
    that. Moreover it misses a key point - whether a program is
    "object-oriented" is not determined by the presence or absence of
    certain language features, any more than functional programming is
    determined by whether or not a language has functions. Certainly
    it is possible to do object-oriented programming in Simula, but
    it's also possible in FORTRAN; I have done both.

    It's also true that some of the key ideas underlying OOP were
    present in earlier systems. Besides Simula, three earlier
    examples are cited that influenced Smalltalk, those being Euler,
    Sketchpad, and an early filesystem on a Burroughs computer. But
    it was Alan Kay who coined the term and first articulated what
    he meant by it, so when it comes to defining the term that seems
    fairly authoritative.
    I'm sure the people who edit wikipedia pages will think what
    they want. It's easy enough to see that this is more historical
    revisionism, if one is inclined to do so, by reading the early
    literature.
    I was doing object-oriented programming, as articulated by
    Alan Kay, before Stroustrup started work on what was later
    to be called C++. I see no reason to consider him an
    authority on the subject.
     
    Tim Rentsch, Oct 24, 2013
    #59
  20. I used an object-oriented graphics system (UG, or Unified Graphics,
    in case anyone else here used it) in the early 1970's. It had APIs
    in both Fortran and PL/I. Just about every call had a "Graphic
    Element" as its first argument, so, yes, I believe you can do
    OO programming in Fortran 66. (Some of the API routines might have
    been in assembler.)

    Even so, I am not convinced one can say that no language was
    necessarily "object oriented" before the term was invented to
    describe it.
    I have the "Handbook of Programming Languages" including vol. 1
    (Object-Oriented Languages).

    The hereditary graph on the OO side starts with Simula, but there
    is no Simula chapter. In the introduction:

    "SIMULA 67 was the first example of using classes of objects.
    The first truly object-oriented programming language was
    Smalltalk named in 1971."

    Seems to me one can use the "True Scotsman" analogy here.
    Simula was Object-Oriented, but not truly Object-Oriented.

    By the way, I remember TXR telling me about Simula on the PDP-10
    sometime around 1978, but me not being very interested in it.

    -- glen
     
    glen herrmannsfeldt, Oct 24, 2013
    #60
    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.