Re: What's new in C?

Discussion in 'C Programming' started by Jorgen Grahn, Nov 30, 2012.

  1. Jorgen Grahn

    Jorgen Grahn Guest

    On Thu, 2012-11-29, Cal Dershowitz wrote:
    > It's been forever since I posted as OP in c.l.c. When I was learning C
    > from Dan Pop, the authors of unleashed, Chris Torek, Keith and even
    > Chuck before he was wrong all the time, there was always the tension
    > between dos and linux platforms, Topic Zealotry: there is no topic but
    > the topic, but also there was good, topical and honest disagreements
    > about C itself.
    >
    > There seemed to be a significant numbers of individuals and companies
    > who were just going to keep on working with C90, while others and I went
    > toward C99.
    >
    > I'm wondering how it all turned out. While the C specification is
    > concise and small, the C family of users and applications is
    > monstrously-large.
    >
    > Did embedded systems eventually embrace newer C?


    For the one I'm working on: we're talking about going C99, but it
    never happens. And the Linux kernel seems stuck with C90 for some
    reason.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Nov 30, 2012
    #1
    1. Advertising

  2. Jorgen Grahn

    Jens Gustedt Guest

    Am 30.11.2012 21:50, schrieb Jorgen Grahn:

    > For the one I'm working on: we're talking about going C99, but it
    > never happens. And the Linux kernel seems stuck with C90 for some
    > reason.


    No, that is much too imprecise to be true. The linux kernel uses its
    own C dialect which is a pragmatic mixture of C89, C99 and gcc
    specific features. They have some C99 that they disallow in the
    kernel, some for good reasons, e.g I can easily be convinced that VLA
    are not such a good idea in an OS kernel. Whether or not to allow
    mixed declarations and statement (which Linus definitively doesn't
    want) is more a matter of taste and/or coding style.

    Jens
    Jens Gustedt, Nov 30, 2012
    #2
    1. Advertising

  3. Jorgen Grahn

    Jorgen Grahn Guest

    On Fri, 2012-11-30, Jens Gustedt wrote:
    > Am 30.11.2012 21:50, schrieb Jorgen Grahn:
    >
    >> For the one I'm working on: we're talking about going C99, but it
    >> never happens. And the Linux kernel seems stuck with C90 for some
    >> reason.

    >
    > No, that is much too imprecise to be true. The linux kernel uses its
    > own C dialect which is a pragmatic mixture of C89, C99 and gcc
    > specific features. They have some C99 that they disallow in the
    > kernel, some for good reasons, e.g I can easily be convinced that VLA
    > are not such a good idea in an OS kernel. Whether or not to allow
    > mixed declarations and statement (which Linus definitively doesn't
    > want) is more a matter of taste and/or coding style.


    True. It's the ban on mixed declarations which annoys me, and the
    feature which "defines" C99 for me personally. No big surprise that
    Linus is against it I guess ...

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Dec 5, 2012
    #3
  4. Jorgen Grahn

    gwowen Guest

    On Dec 5, 3:26 am, Jorgen Grahn <> wrote:

    > True. It's the ban on mixed declarations which annoys me, and the
    > feature which "defines" C99 for me personally.  No big surprise that
    > Linus is against it I guess ...


    And yet, something tells me that if mixed declarations were allowed,
    no-one would've ever written:

    static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
    {
    struct sock *sk = tun->sk;
    unsigned int mask = 0;

    if (!tun) return POLLERR;
    // oops, check gets compiled out, bad stuff happens...
    }

    Of course, there are C89 constructs that mitigate that error, but none
    as natural as declaring a variable at initialisation time.
    gwowen, Dec 6, 2012
    #4
  5. Jorgen Grahn

    Jorgen Grahn Guest

    On Thu, 2012-12-06, gwowen wrote:
    > On Dec 5, 3:26 am, Jorgen Grahn <> wrote:
    >
    >> True. It's the ban on mixed declarations which annoys me, and the
    >> feature which "defines" C99 for me personally.  No big surprise that
    >> Linus is against it I guess ...

    >
    > And yet, something tells me that if mixed declarations were allowed,
    > no-one would've ever written:
    >
    > static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
    > {
    > struct sock *sk = tun->sk;
    > unsigned int mask = 0;
    >
    > if (!tun) return POLLERR;
    > // oops, check gets compiled out, bad stuff happens...
    > }
    >
    > Of course, there are C89 constructs that mitigate that error, but none
    > as natural as declaring a variable at initialisation time.


    Ugh. Yeah, it would be interesting to read Linus' rationale for not
    allowing it. (Although based on earlier rants of his, I suspect it
    would just leave me puzzled and angry. His good sense shows in his
    designs, not so much in his writings.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Dec 8, 2012
    #5
  6. Jorgen Grahn

    BartC Guest

    "Jorgen Grahn" <> wrote in message
    news:...
    > On Thu, 2012-12-06, gwowen wrote:


    >> And yet, something tells me that if mixed declarations were allowed,
    >> no-one would've ever written:
    >>
    >> static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
    >> {
    >> struct sock *sk = tun->sk;
    >> unsigned int mask = 0;
    >>
    >> if (!tun) return POLLERR;
    >> // oops, check gets compiled out, bad stuff happens...
    >> }
    >>
    >> Of course, there are C89 constructs that mitigate that error, but none
    >> as natural as declaring a variable at initialisation time.

    >
    > Ugh. Yeah, it would be interesting to read Linus' rationale for not
    > allowing it.


    Maybe he thought that overall that were more minuses than pluses.

    (I can see so many things wrong with having mixed declarations, that I
    wouldn't know where to start. Let's say I can't see many pluses at all!)

    --
    Bartc
    BartC, Dec 8, 2012
    #6
  7. Jorgen Grahn

    Jorgen Grahn Guest

    On Sat, 2012-12-08, BartC wrote:
    >
    >
    > "Jorgen Grahn" <> wrote in message
    > news:...
    >> On Thu, 2012-12-06, gwowen wrote:

    >
    >>> And yet, something tells me that if mixed declarations were allowed,
    >>> no-one would've ever written:
    >>>
    >>> static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
    >>> {
    >>> struct sock *sk = tun->sk;
    >>> unsigned int mask = 0;
    >>>
    >>> if (!tun) return POLLERR;
    >>> // oops, check gets compiled out, bad stuff happens...
    >>> }
    >>>
    >>> Of course, there are C89 constructs that mitigate that error, but none
    >>> as natural as declaring a variable at initialisation time.

    >>
    >> Ugh. Yeah, it would be interesting to read Linus' rationale for not
    >> allowing it.

    >
    > Maybe he thought that overall that were more minuses than pluses.
    >
    > (I can see so many things wrong with having mixed declarations, that I
    > wouldn't know where to start. Let's say I can't see many pluses at all!)


    We are at different ends of the spectrum then. I can think of one
    semi-reason for banning them ("I want to pretend I have a compre-
    hensive list of what's on this function's stack, and an idea of how
    much stack it uses") but that's about it.

    (No, actually I've heard another one: "it becomes so painful to
    maintain for long functions that you're encouraged to split it into
    smaller functions". I don't buy such arguments.)

    If you really have more arguments, I'm interested and willing to
    listen.

    The argument *for* allowing it is simply:

    I can declare the variable exactly at the point where it's needed,
    meaning I can give it a guaranteed sane initial value, and frequently
    make it const.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Dec 8, 2012
    #7
  8. Jorgen Grahn

    Martin Shobe Guest

    Jorgen Grahn <> wrote in
    news::

    > On Sat, 2012-12-08, BartC wrote:
    >>
    >>
    >> "Jorgen Grahn" <> wrote in message
    >> news:...
    >>> On Thu, 2012-12-06, gwowen wrote:

    >>
    >>>> And yet, something tells me that if mixed declarations were
    >>>> allowed, no-one would've ever written:
    >>>>
    >>>> static unsigned int tun_chr_poll(struct file *file, poll_table *
    >>>> wait) {
    >>>> struct sock *sk = tun->sk;
    >>>> unsigned int mask = 0;
    >>>>
    >>>> if (!tun) return POLLERR;
    >>>> // oops, check gets compiled out, bad stuff happens...
    >>>> }
    >>>>
    >>>> Of course, there are C89 constructs that mitigate that error, but
    >>>> none as natural as declaring a variable at initialisation time.
    >>>
    >>> Ugh. Yeah, it would be interesting to read Linus' rationale for not
    >>> allowing it.

    >>
    >> Maybe he thought that overall that were more minuses than pluses.
    >>
    >> (I can see so many things wrong with having mixed declarations, that
    >> I wouldn't know where to start. Let's say I can't see many pluses at
    >> all!)

    >
    > We are at different ends of the spectrum then. I can think of one
    > semi-reason for banning them ("I want to pretend I have a compre-
    > hensive list of what's on this function's stack, and an idea of how
    > much stack it uses") but that's about it.
    >
    > (No, actually I've heard another one: "it becomes so painful to
    > maintain for long functions that you're encouraged to split it into
    > smaller functions". I don't buy such arguments.)


    That sounds like a reason to allow it to me.

    [snip]

    Martin Shobe
    Martin Shobe, Dec 8, 2012
    #8
  9. On Saturday, December 8, 2012 3:23:23 PM UTC, Jorgen Grahn wrote:
    > On Sat, 2012-12-08, BartC wrote:
    >
    > We are at different ends of the spectrum then. I can think of one
    > semi-reason for banning them ("I want to pretend I have a compre-
    > hensive list of what's on this function's stack, and an idea of how
    > much stack it uses") but that's about it.
    >
    > (No, actually I've heard another one: "it becomes so painful to
    > maintain for long functions that you're encouraged to split it into
    > smaller functions". I don't buy such arguments.)
    >

    A function is a unit, and variables have meaning within that unit.

    If N means "the number of employees", then it makes sense if N means that
    thoughout the whole function. If it means "the bitpattern that represents
    the Latin glyph N", again it should mean that in the whole function.

    So it's natural to have a glossary at the start of the function.

    unsigned char *N; /* bit pattern for N */
    double theta; /* anticlockwise angle */
    int x, y; /* top left Cartesian co-ordinates */

    --
    Visit Malcolm's website
    http://www.malcolmmclean.site11.com/www
    Malcolm McLean, Dec 8, 2012
    #9
  10. Jorgen Grahn

    BartC Guest

    "Jorgen Grahn" <> wrote in message
    news:...
    > On Sat, 2012-12-08, BartC wrote:


    >> "Jorgen Grahn" <> wrote in message


    >>> Ugh. Yeah, it would be interesting to read Linus' rationale for not
    >>> allowing it.

    >>
    >> Maybe he thought that overall that were more minuses than pluses.
    >>
    >> (I can see so many things wrong with having mixed declarations, that I
    >> wouldn't know where to start. Let's say I can't see many pluses at all!)

    >
    > We are at different ends of the spectrum then. I can think of one
    > semi-reason for banning them ("I want to pretend I have a compre-
    > hensive list of what's on this function's stack, and an idea of how
    > much stack it uses") but that's about it.


    > If you really have more arguments, I'm interested and willing to
    > listen.


    I've this discussed this here before I think. My arguments weren't received
    well then either!

    So, mixed declarations, AIUI, allow you to have unlimited, distinct versions
    of the same identifier within a function. They may or might not have the
    same type.

    For example, a 3-deep nested for-loop all using 'i' as the index variable!

    Searching for a declaration for an identifer, instead of looking at the top
    of the function, it means searching up line-by-line counting blocks, since
    it will now be hidden in a mass of code somewhere.

    If you've been editing and have introduced new identifiers, more care is
    needed to find the outermost block that contains all uses of that name (get
    it wrong by one block, and a later use could unintentionally shadow a global
    version of the name) for a location of the declaration.

    When editing involves deleting, inserting, moving or modifying lines that
    include the declaration of a name, you might have to find a new home for the
    declaration. Or maybe you insert another use of the name before the
    declaration. It makes maintenance harder.

    If it's ever necessary to refer to a name, outside of the program (in a
    phone call, email, etc) you might not be able to say variable A in function
    F, if there's more than one!

    From an implementation point of view, it creates extra difficulties. Instead
    of {...} simply meaning you have 2 statements instead of 1 in the that
    if-else branch, you now have to take care of allocating and deallocating any
    variables in that block, not only at the end, but in case of a goto or break
    too.

    (This need not be the case; an implementation may decide it's easier to just
    allocate all the distinct names as one block, on entry for the function.
    Such an implementation is sensible! Unless there are VLAs involved..)

    If a variable is initialised in a block, then it might be reinitialised if
    that block is reexecuted; you might only need it initialised once per
    function entry.

    Generally, it makes a function look untidy and cluttered, IMO, having the
    declarations scattered randomly through the code, makes maintenance more
    difficult (and sometimes trickier), and makes it harder to see at a glance
    all the names that are used. Declarations at the top makes it easier to
    group related names together, perhaps with a comment applied to the group.

    (Mixed declarations are like reading a play where the list of characters is
    scattered through the text instead of just before Act I!)

    Also, mixed declarations may not always be allowed.

    > The argument *for* allowing it is simply:
    >
    > I can declare the variable exactly at the point where it's needed,
    > meaning I can give it a guaranteed sane initial value, and frequently
    > make it const.


    Yes, it makes it easy to write. But harder to read and to maintain. Maybe I
    should just have said that...

    --
    Bartc
    BartC, Dec 8, 2012
    #10
  11. Jorgen Grahn

    Ian Collins Guest

    BartC wrote:
    > "Jorgen Grahn" <> wrote in message
    > news:...
    >> On Sat, 2012-12-08, BartC wrote:

    >
    >>> "Jorgen Grahn" <> wrote in message

    >
    >>>> Ugh. Yeah, it would be interesting to read Linus' rationale for not
    >>>> allowing it.
    >>>
    >>> Maybe he thought that overall that were more minuses than pluses.
    >>>
    >>> (I can see so many things wrong with having mixed declarations, that I
    >>> wouldn't know where to start. Let's say I can't see many pluses at all!)

    >>
    >> We are at different ends of the spectrum then. I can think of one
    >> semi-reason for banning them ("I want to pretend I have a compre-
    >> hensive list of what's on this function's stack, and an idea of how
    >> much stack it uses") but that's about it.

    >
    >> If you really have more arguments, I'm interested and willing to
    >> listen.

    >
    > I've this discussed this here before I think. My arguments weren't received
    > well then either!
    >
    > So, mixed declarations, AIUI, allow you to have unlimited, distinct versions
    > of the same identifier within a function. They may or might not have the
    > same type.
    >
    > For example, a 3-deep nested for-loop all using 'i' as the index variable!


    You can do that in C89.

    > Searching for a declaration for an identifer, instead of looking at the top
    > of the function, it means searching up line-by-line counting blocks, since
    > it will now be hidden in a mass of code somewhere.


    If a function is long enough for this to be a problem, you have bigger
    things to worry about than mixed declarations and code.

    --
    Ian Collins
    Ian Collins, Dec 8, 2012
    #11
  12. Jorgen Grahn

    Jorgen Grahn Guest

    On Sat, 2012-12-08, Malcolm McLean wrote:
    > On Saturday, December 8, 2012 3:23:23 PM UTC, Jorgen Grahn wrote:
    >> On Sat, 2012-12-08, BartC wrote:
    >>
    >> We are at different ends of the spectrum then. I can think of one
    >> semi-reason for banning them ("I want to pretend I have a compre-
    >> hensive list of what's on this function's stack, and an idea of how
    >> much stack it uses") but that's about it.
    >>
    >> (No, actually I've heard another one: "it becomes so painful to
    >> maintain for long functions that you're encouraged to split it into
    >> smaller functions". I don't buy such arguments.)
    >>

    > A function is a unit, and variables have meaning within that unit.
    >
    > If N means "the number of employees", then it makes sense if N means that
    > thoughout the whole function. If it means "the bitpattern that represents
    > the Latin glyph N", again it should mean that in the whole function.


    Sure. I think everyone agrees about that.

    > So it's natural to have a glossary at the start of the function.
    >
    > unsigned char *N; /* bit pattern for N */
    > double theta; /* anticlockwise angle */
    > int x, y; /* top left Cartesian co-ordinates */


    Your example also happens to be a good counterexample.

    The documentation for N, theta, x and y is incorrect the point of
    declaration. 'theta' might well be an angle further down into the
    function, but at this point it's just garbage.

    That's why I prefer 'theta' to show up at initialization time:

    const double theta = some_trigonometry_stuff(x, y);

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Dec 8, 2012
    #12
  13. "BartC" <> writes:
    > "Jorgen Grahn" <> wrote in message
    > news:...
    >> On Sat, 2012-12-08, BartC wrote:

    >
    >>> "Jorgen Grahn" <> wrote in message

    >
    >>>> Ugh. Yeah, it would be interesting to read Linus' rationale for not
    >>>> allowing it.
    >>>
    >>> Maybe he thought that overall that were more minuses than pluses.
    >>>
    >>> (I can see so many things wrong with having mixed declarations, that I
    >>> wouldn't know where to start. Let's say I can't see many pluses at all!)

    >>
    >> We are at different ends of the spectrum then. I can think of one
    >> semi-reason for banning them ("I want to pretend I have a compre-
    >> hensive list of what's on this function's stack, and an idea of how
    >> much stack it uses") but that's about it.

    >
    >> If you really have more arguments, I'm interested and willing to
    >> listen.

    >
    > I've this discussed this here before I think. My arguments weren't received
    > well then either!
    >
    > So, mixed declarations, AIUI, allow you to have unlimited, distinct versions
    > of the same identifier within a function. They may or might not have the
    > same type.


    No, they don't.

    > For example, a 3-deep nested for-loop all using 'i' as the index variable!


    You've been able to have declarations with the same name *in nested
    blocks* at least since C89, and I think K&R C allowed it too:

    void func(void) {
    int n;
    {
    double n;
    }
    }

    What C99 added (borrowed from C++) was the ability to mix declarations
    and statements in the same block, (whether that block happens to be the
    outermost block of a function or not) -- but you still can't have
    declarations with duplicate names in the same scope:

    void func(void) {
    int a;
    statement();
    int b; /* Illegal in C89/C90, legal in C99 */
    double a; /* Illegal in all versions of C */
    }

    [...]

    >> The argument *for* allowing it is simply:
    >>
    >> I can declare the variable exactly at the point where it's needed,
    >> meaning I can give it a guaranteed sane initial value, and frequently
    >> make it const.

    >
    > Yes, it makes it easy to write. But harder to read and to maintain. Maybe I
    > should just have said that...


    I agree it's easier to write; I don't agree that it makes it harder to
    read or maintain:

    void func(void) {
    int x = something;
    /* code that does some calculations affecting x */
    const int y = value_that_depends_on(x);
    /* code that uses y */
    }

    As Jorgen says, it means you can initialize y based on information
    that's not available at the top of the function.

    This is just an easier way to do what you could already do without this
    feature:

    void func(void) {
    int x = something;
    /* code that does some calculations affecting x */
    {
    const int y = value_that_depends_on(x);
    /* code that uses y */
    }
    }

    I *think* that any code that depends on mixed declarations and
    statements can be transformed to code without mixed declarations and
    statements, by adding opening and closing braces. (I could easily
    be mistaken on that point; does anyone have a counterexample?)
    The problem is that it can result in deeply nested blocks.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Dec 8, 2012
    #13
  14. Jorgen Grahn

    Jorgen Grahn Guest

    On Sat, 2012-12-08, BartC wrote:
    > "Jorgen Grahn" <> wrote in message
    > news:...
    >> On Sat, 2012-12-08, BartC wrote:

    >
    >>> "Jorgen Grahn" <> wrote in message

    >
    >>>> Ugh. Yeah, it would be interesting to read Linus' rationale for not
    >>>> allowing it.
    >>>
    >>> Maybe he thought that overall that were more minuses than pluses.
    >>>
    >>> (I can see so many things wrong with having mixed declarations, that I
    >>> wouldn't know where to start. Let's say I can't see many pluses at all!)

    >>
    >> We are at different ends of the spectrum then. I can think of one
    >> semi-reason for banning them ("I want to pretend I have a compre-
    >> hensive list of what's on this function's stack, and an idea of how
    >> much stack it uses") but that's about it.

    >
    >> If you really have more arguments, I'm interested and willing to
    >> listen.

    >
    > I've this discussed this here before I think. My arguments weren't received
    > well then either!


    Why the "either"? I have so far just requested to hear them.

    > So, mixed declarations, AIUI, allow you to have unlimited, distinct versions
    > of the same identifier within a function. They may or might not have the
    > same type.
    >
    > For example, a 3-deep nested for-loop all using 'i' as the index variable!


    My reaction to that is:
    (a) Why would I do something crazy like that?
    (b) What does that have to do with mixed declarations?
    It seems to me I can do that just as well (or badly) in C90:

    int foo(void) {
    for(int i=0; i<4; i++)
    for(int i=0; i<5; i++) ;
    return i;
    }

    int foo(void) {
    int i;
    for(i=0; i<4; i++) {
    int i;
    for(i=0; i<5; i++) ;
    }
    return i;
    }

    > Searching for a declaration for an identifer, instead of looking at the top
    > of the function, it means searching up line-by-line counting blocks, since
    > it will now be hidden in a mass of code somewhere.


    OK, I see now we are talking about different things. I was talking
    about the C99 feature disliked by Linus Torvalds, but you also don't
    like the K&R feature which lets you declare variables at the beginning
    of a block. To avoid confusion, I will not enter that second
    discussion.

    [snip]

    > From an implementation point of view, it creates extra difficulties. Instead
    > of {...} simply meaning you have 2 statements instead of 1 in the that
    > if-else branch, you now have to take care of allocating and deallocating any
    > variables in that block, not only at the end, but in case of a goto or break
    > too.


    It's a bit of a moot point though, isn't it? C compilers have AFAIK
    handled this since the early 1970s.

    >> The argument *for* allowing it is simply:
    >>
    >> I can declare the variable exactly at the point where it's needed,
    >> meaning I can give it a guaranteed sane initial value, and frequently
    >> make it const.

    >
    > Yes, it makes it easy to write. But harder to read and to maintain.


    That's the exact opposite of what I meant, though. I've done a lot of
    maintenance in my days, and I believe people who value ease of writing
    over ease of maintenance should simply be fired.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Dec 8, 2012
    #14
  15. Jorgen Grahn

    BartC Guest

    "Ian Collins" <> wrote in message
    news:...
    > BartC wrote:


    >> For example, a 3-deep nested for-loop all using 'i' as the index
    >> variable!

    >
    > You can do that in C89.


    Do you have an example? That is meaningful I mean.

    Although nothing is stopping you anyway from using the same index variable,
    because they are all the same variable, it's going to cause difficulties, so
    it doesn't happen.

    But with mixed declarations it will work, because all the 'i's are distinct.
    However, it's just confusing

    (What *is* a good idea, I think, is to just auto-declare for-loop variables
    anyway. Then the question of where to declare them is eliminated!)

    > If a function is long enough for this to be a problem, you have bigger
    > things to worry about than mixed declarations and code.


    And if a function is short, there's less to gain from localising all the
    declarations.

    --
    Bartc
    BartC, Dec 8, 2012
    #15
  16. Jorgen Grahn

    Ian Collins Guest

    BartC wrote:
    > "Ian Collins" <> wrote in message
    > news:...
    >> BartC wrote:

    >
    >>> For example, a 3-deep nested for-loop all using 'i' as the index
    >>> variable!

    >>
    >> You can do that in C89.

    >
    > Do you have an example? That is meaningful I mean.


    int main(void) {
    int i;

    for( i = 0; i < 10; ++i ) {
    int i;
    for( i = 0; i < 10; ++i ) {
    }
    }
    }

    > Although nothing is stopping you anyway from using the same index variable,
    > because they are all the same variable, it's going to cause difficulties, so
    > it doesn't happen.
    >
    > But with mixed declarations it will work, because all the 'i's are distinct.
    > However, it's just confusing
    >
    > (What *is* a good idea, I think, is to just auto-declare for-loop variables
    > anyway. Then the question of where to declare them is eliminated!)


    Isn't that what C99 added?

    >> If a function is long enough for this to be a problem, you have bigger
    >> things to worry about than mixed declarations and code.

    >
    > And if a function is short, there's less to gain from localising all the
    > declarations.


    My point was that one of the common reasons for not liking mixed
    declarations and code is it doesn't sit well with badly written code.

    --
    Ian Collins
    Ian Collins, Dec 8, 2012
    #16
  17. Jorgen Grahn

    BartC Guest

    "Jorgen Grahn" <> wrote in message
    news:...
    > On Sat, 2012-12-08, BartC wrote:


    >> I've this discussed this here before I think. My arguments weren't
    >> received
    >> well then either!

    >
    > Why the "either"? I have so far just requested to hear them.


    Sorry. I assumed the same people who argued for the feature then,
    would still have the same views.

    >> Searching for a declaration for an identifer, instead of looking at the
    >> top
    >> of the function, it means searching up line-by-line counting blocks,
    >> since
    >> it will now be hidden in a mass of code somewhere.

    >
    > OK, I see now we are talking about different things. I was talking
    > about the C99 feature disliked by Linus Torvalds, but you also don't
    > like the K&R feature which lets you declare variables at the beginning
    > of a block. To avoid confusion, I will not enter that second
    > discussion.


    You mean, declarations don't even need to be at the start of a block now?

    Then it's worse than I thought!

    In that case most of my arguments apply doubly.

    >> From an implementation point of view, it creates extra difficulties.


    > It's a bit of a moot point though, isn't it? C compilers have AFAIK
    > handled this since the early 1970s.


    Maybe. It was still unnecessary in my opinion. 99% of time you're using
    begin..end, {...} or whatever, simply because there is more than one
    statement, nothing more.

    --
    Bartc
    BartC, Dec 8, 2012
    #17
  18. "BartC" <> writes:
    > "Ian Collins" <> wrote in message
    > news:...
    >> BartC wrote:
    >>> For example, a 3-deep nested for-loop all using 'i' as the index
    >>> variable!

    >>
    >> You can do that in C89.

    >
    > Do you have an example? That is meaningful I mean.
    >
    > Although nothing is stopping you anyway from using the same index variable,
    > because they are all the same variable, it's going to cause difficulties, so
    > it doesn't happen.


    What do you mean by "they are all the same variable"?

    Using C99 syntax:

    for (int i = 0; i < 100; i ++) {
    for (int i = 0; i < 100; i ++) {
    // ...
    }
    }

    The outer and inner "i" are two distinct objects (that happen to
    have the same name). If you say they're the same variable, then
    you're using a very different definition of "variable" than I do.

    > But with mixed declarations it will work, because all the 'i's are distinct.
    > However, it's just confusing
    >
    > (What *is* a good idea, I think, is to just auto-declare for-loop variables
    > anyway. Then the question of where to declare them is eliminated!)


    By "auto-declare", are you referring to the new-in-C99 feature I just
    demonstrated? I wouldn't call that "auto-declaring" (unless you're
    referring to automatic storage duration, but I don't think that's what
    you mean). You still need a declaration; the language just permits it
    to be in the header of the for-loop.

    Note that if the body of the loop doesn't need to refer to the variable,
    once could argue that using the same name for both loop variables is
    sensible. (I'd still want to use distinct names.)

    Some languages do provide a syntax to execute a loop N times without
    creating a variable that gives you the current iteration number. C's
    for-loop provides capabilities far beyond a simple counted loop, so it
    wouldn't make too much sense to add such a special case. I suppose the
    language could have had something like:

    repeat(100) {
    /* ... */
    }

    but that's probably not sufficiently useful to make it a language
    feature.

    >> If a function is long enough for this to be a problem, you have bigger
    >> things to worry about than mixed declarations and code.

    >
    > And if a function is short, there's less to gain from localising all the
    > declarations.


    What you gain is the ability to initialize a variable using information
    that's not available at the top of the function (or block). Do you
    really not find that useful?

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Dec 8, 2012
    #18
  19. Jorgen Grahn

    BartC Guest

    "Ian Collins" <> wrote in message
    news:...
    > BartC wrote:
    >> "Ian Collins" <> wrote in message


    >>> You can do that in C89.

    >>
    >> Do you have an example? That is meaningful I mean.

    >
    > int main(void) {
    > int i;
    >
    > for( i = 0; i < 10; ++i ) {
    > int i;
    > for( i = 0; i < 10; ++i ) {
    > }
    > }
    > }
    >
    >> Although nothing is stopping you anyway from using the same index
    >> variable,
    >> because they are all the same variable, it's going to cause difficulties,
    >> so
    >> it doesn't happen.
    >>
    >> But with mixed declarations it will work, because all the 'i's are
    >> distinct.
    >> However, it's just confusing
    >>
    >> (What *is* a good idea, I think, is to just auto-declare for-loop
    >> variables
    >> anyway. Then the question of where to declare them is eliminated!)

    >
    > Isn't that what C99 added?


    It seems I misunderstood was being discussed. I thought it was declarations
    at the top vs. block declarations. Not block declarations vs. genuinely
    anywhere.

    Which I consider even more wrong.

    If, for example, you have to fill in the declarations in a newly written
    functions (if like me you leave such matters until the code is at a first
    draft); it means searching backwards for the first occurrence of each name,
    and paying attention to block structure, instead of just sticking them all
    at the top where they belong. And where they don't spoil the lines of the
    function with all these incongruous declarations.

    Then you have to edit the code and have to keep moving the declarations
    around ...

    But I suppose it's people's choice if they want to make life more difficult.

    --
    Bartc
    BartC, Dec 8, 2012
    #19
  20. Jorgen Grahn

    Ian Collins Guest

    BartC wrote:
    >
    > It seems I misunderstood was being discussed. I thought it was declarations
    > at the top vs. block declarations. Not block declarations vs. genuinely
    > anywhere.
    >
    > Which I consider even more wrong.
    >
    > If, for example, you have to fill in the declarations in a newly written
    > functions (if like me you leave such matters until the code is at a first
    > draft); it means searching backwards for the first occurrence of each name,
    > and paying attention to block structure, instead of just sticking them all
    > at the top where they belong. And where they don't spoil the lines of the
    > function with all these incongruous declarations.
    >
    > Then you have to edit the code and have to keep moving the declarations
    > around ...


    Which yet again emphasises my earlier point (that you conveniently
    snipped): one of the common reasons for not liking mixed declarations
    and code is it doesn't sit well with badly written code.

    --
    Ian Collins
    Ian Collins, Dec 8, 2012
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robb Smith
    Replies:
    2
    Views:
    558
    Saravana
    Jul 18, 2003
  2. =?Utf-8?B?UGF0cmljaw==?=

    Open new with new session

    =?Utf-8?B?UGF0cmljaw==?=, Dec 18, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    3,317
    tittlejoseph
    Sep 2, 2007
  3. Gawel
    Replies:
    1
    Views:
    386
    Alvin Bruney
    Dec 31, 2003
  4. =?Utf-8?B?QmVuamFtaW4=?=
    Replies:
    0
    Views:
    301
    =?Utf-8?B?QmVuamFtaW4=?=
    Feb 12, 2004
  5. Replies:
    2
    Views:
    437
    Thomas 'PointedEars' Lahn
    Mar 11, 2008
Loading...

Share This Page