Comma inside if statement in C

Discussion in 'C Programming' started by Adee, Feb 14, 2013.

  1. Adee

    Adee Guest

    Well yesterday I came across a strange behaviour of C program i.e.

    let suppose we have three integers
    int a=5, b=6, c=7;

    if(c>b , b>a)
    printf("C is greater %d",c);


    this if statment is working, I am surprised about it. Can anyone explain this feature to me. Thanks
     
    Adee, Feb 14, 2013
    #1
    1. Advertising

  2. Adee

    John Gordon Guest

    In <> Adee <> writes:

    > Well yesterday I came across a strange behaviour of C program i.e.


    > let suppose we have three integers
    > int a=5, b=6, c=7;


    > if(c>b , b>a)
    > printf("C is greater %d",c);



    > this if statment is working, I am surprised about it. Can anyone explain
    > this feature to me. Thanks


    When you have two or more expressions sepatated by commas, the rightmost
    expression value is used, and all the other values are discarded.

    So in this case, the expression 'c>b' is evaluated and the result is
    discarded, then the expression 'b>a' is evaluated and used for the if()
    statement.

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
     
    John Gordon, Feb 14, 2013
    #2
    1. Advertising

  3. Adee <> writes:

    > Well yesterday I came across a strange behaviour of C program i.e.
    >
    > let suppose we have three integers
    > int a=5, b=6, c=7;
    >
    > if(c>b , b>a)
    > printf("C is greater %d",c);
    >
    >
    > this if statment is working, I am surprised about it. Can anyone
    > explain this feature to me. Thanks


    In this context, the comma is an operator used for sequencing the
    evaluation of two expressions (the comma symbol has other meanings in
    other contexts). What happens is this: c>b is (pointlessly) evaluated
    and the result is "thrown away". The result of the whole expression --
    that of the condition being tested -- is simply the result of b>a. Did
    you test with other values of c?

    --
    Ben.
     
    Ben Bacarisse, Feb 14, 2013
    #3
  4. John Gordon <> writes:
    > In <> Adee <> writes:
    >> Well yesterday I came across a strange behaviour of C program i.e.

    >
    >> let suppose we have three integers
    >> int a=5, b=6, c=7;

    >
    >> if(c>b , b>a)
    >> printf("C is greater %d",c);

    >
    >
    >> this if statment is working, I am surprised about it. Can anyone explain
    >> this feature to me. Thanks

    >
    > When you have two or more expressions sepatated by commas, the rightmost
    > expression value is used, and all the other values are discarded.
    >
    > So in this case, the expression 'c>b' is evaluated and the result is
    > discarded, then the expression 'b>a' is evaluated and used for the if()
    > statement.


    That's true only when the comma is a comma *operator*. The comma symbol
    is also used in other contexts, e.g., to saparate function arguments.

    The syntax of an if statement specifies that the tokens between the
    parentheses are a single expression, so in

    if (c>b, b>a)

    that's a comma operator; `c>b` is evaluated, the result is discarded,
    then `b>a` evaluated and the result is used as the condition. (The
    compiler is likely to generate code that doesn't bother to evaluate
    `c>b`, since it has no side effects and its result is ignored). So the
    printf statement lies; the output of the program is not affected by
    whether C is greater than anything.

    On the other hand, if you write:

    some_func(c>b, b>a)

    you're passing two arguments to some_func; the first is the result of
    `c>b` and the second is the result of `b>a` (each of which is either 0
    or 1). That's a delimiter between arguments, *not* a comma operator.

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, Feb 14, 2013
    #4
  5. Adee

    Xavier Roche Guest

    Le 14/02/2013 20:10, Keith Thompson a écrit :
    > That's true only when the comma is a comma *operator*. The comma symbol
    > is also used in other contexts, e.g., to saparate function arguments.


    It is especially important with respect to the sequence point(s):
    some_func(a++, a++)
    will have an undefined behavior (comma is not a sequence point)

    some_func((a++, a++))
    will have a defined behavior (comma is a sequence point)
    (some_func takes one argument here)
     
    Xavier Roche, Feb 14, 2013
    #5
  6. Xavier Roche <> writes:
    > Le 14/02/2013 20:10, Keith Thompson a écrit :
    >> That's true only when the comma is a comma *operator*. The comma symbol
    >> is also used in other contexts, e.g., to saparate function arguments.

    >
    > It is especially important with respect to the sequence point(s):
    > some_func(a++, a++)
    > will have an undefined behavior (comma is not a sequence point)
    >
    > some_func((a++, a++))
    > will have a defined behavior (comma is a sequence point)
    > (some_func takes one argument here)


    Yes, but the latter is still poor style. IMHO it's better written as:

    some_func(a+1);
    a += 2;

    If you're writing a compiler, you have to get this stuff right. If
    you're writing code, clarity is important.

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, Feb 14, 2013
    #6
  7. Adee

    Xavier Roche Guest

    Le 14/02/2013 21:13, Keith Thompson a écrit :
    > Yes, but the latter is still poor style. IMHO it's better written as:


    Yes, of course. The only rather reasonable location of parenthesis is
    probably conditions ; ie.

    int success;
    if (foo_is_successful()
    && (bar_process(&success), success) == TRUE
    ) {
    ....

    which in many situations is simplifying the visual flow.
     
    Xavier Roche, Feb 14, 2013
    #7
  8. Xavier Roche <> writes:
    > Le 14/02/2013 21:13, Keith Thompson a écrit :
    >> Yes, but the latter is still poor style. IMHO it's better written as:

    >
    > Yes, of course. The only rather reasonable location of parenthesis is
    > probably conditions ; ie.
    >
    > int success;
    > if (foo_is_successful()
    > && (bar_process(&success), success) == TRUE
    > ) {
    > ...
    >
    > which in many situations is simplifying the visual flow.


    What I suggested was poor style was function arguments with side
    effects; it wasn't particularly about parentheses. I'm not sure your
    example is any better. (And the "== TRUE" is a really bad idea. If
    "success" is a condition, just use it as one.)

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, Feb 14, 2013
    #8
  9. pete <> writes:
    > Adee wrote:
    >> Well yesterday I came across a strange behaviour of C program i.e.
    >>
    >> let suppose we have three integers
    >> int a=5, b=6, c=7;
    >>
    >> if(c>b , b>a)
    >> printf("C is greater %d",c);
    >>
    >> this if statment is working, I am surprised about it.
    >> Can anyone explain this feature to me. Thanks

    >
    >
    > I think that the output of the printf statement
    > was most likely intended to indicate transitivity,
    > and therefore I also think that
    >
    > if(c>b && b>a)
    >
    > is what was most likely intended to be written.


    Perhaps, but printing "C is greater 7" is not the clearest way to
    express that condition. (Then again, it's not the clearest way to
    express anything else.)

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, Feb 15, 2013
    #9
  10. pete <> wrote:
    > Keith Thompson wrote:
    >> Xavier Roche <> writes:


    (snip)

    >> > some_func((a++, a++))
    >> > will have a defined behavior
    >> > (comma is a sequence point)
    >> > (some_func takes one argument here)


    (snip)
    >> some_func(a+1);
    >> a += 2;


    >> If you're writing a compiler, you have to get this stuff right. If
    >> you're writing code, clarity is important.


    > If (a) has file scope and
    > if (a) is also accessed within the some_func function,
    > then
    > a += 2;
    > some_func(a - 1);
    > would be the semantically equivalent form.


    There is also:

    a++;
    some_func(a);
    a++;

    which might be more readable in some contexts.

    In written formats like PDF, you have to keep track of how
    many bytes you have written up to certain points to put into
    the TOC at the end.

    -- glen
     
    glen herrmannsfeldt, Feb 15, 2013
    #10
  11. glen herrmannsfeldt <> writes:

    > pete <> wrote:
    >> Keith Thompson wrote:
    >>> Xavier Roche <> writes:

    >
    > (snip)
    >
    >>> > some_func((a++, a++))
    >>> > will have a defined behavior
    >>> > (comma is a sequence point)
    >>> > (some_func takes one argument here)

    >
    > (snip)
    >>> some_func(a+1);
    >>> a += 2;

    >
    >>> If you're writing a compiler, you have to get this stuff right. If
    >>> you're writing code, clarity is important.

    >
    >> If (a) has file scope and
    >> if (a) is also accessed within the some_func function,
    >> then
    >> a += 2;
    >> some_func(a - 1);
    >> would be the semantically equivalent form.

    >
    > There is also:
    >
    > a++;
    > some_func(a);
    > a++;
    >
    > which might be more readable in some contexts.


    Just in case it's been missed, pete's point was about the semantics, not
    the readability. All three re-writes have different meanings if, as
    pete stipulates, 'a' is used inside 'some_func'. His version has the
    same meaning (under these conditions) as the original.

    Of course, code that meets these conditions has problems that go beyond
    using (a++, a++) as a single function argument!

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Feb 15, 2013
    #11
  12. Ben Bacarisse <> wrote:

    (snip)
    >>>> > some_func((a++, a++))
    >>>> > will have a defined behavior
    >>>> > (comma is a sequence point)
    >>>> > (some_func takes one argument here)


    >> (snip)
    >>>> some_func(a+1);
    >>>> a += 2;


    (snip)
    >>> a += 2;
    >>> some_func(a - 1);
    >>> would be the semantically equivalent form.


    >> There is also:


    >> a++;
    >> some_func(a);
    >> a++;


    >> which might be more readable in some contexts.


    > Just in case it's been missed, pete's point was about the semantics, not
    > the readability. All three re-writes have different meanings if, as
    > pete stipulates, 'a' is used inside 'some_func'. His version has the
    > same meaning (under these conditions) as the original.


    Yes, I did miss that one. I had thought about replying after Keith,
    but then didn't do it. Keith commented about readability.

    > Of course, code that meets these conditions has problems that
    > go beyond using (a++, a++) as a single function argument!


    Yes, don't do that!

    As far as readability, if I was calling, say, 100 (different)
    functions with successively higher values of a, I might go with
    the a++ argument. If there was any question about readability,
    one comment should apply to all of them. Seems nicer than 100
    function calls and 100 a++ statements.

    -- glen
     
    glen herrmannsfeldt, Feb 15, 2013
    #12
  13. Adee

    Tim Rentsch Guest

    Ben Bacarisse <> writes:

    > glen herrmannsfeldt <> writes:
    >
    >> pete <> wrote:
    >>> Keith Thompson wrote:
    >>>> Xavier Roche <> writes:

    >>
    >> (snip)
    >>
    >>>> > some_func((a++, a++))
    >>>> > will have a defined behavior
    >>>> > (comma is a sequence point)
    >>>> > (some_func takes one argument here)

    >>
    >> (snip)
    >>>> some_func(a+1);
    >>>> a += 2;

    >>
    >>>> If you're writing a compiler, you have to get this stuff right.
    >>>> If you're writing code, clarity is important.

    >>
    >>> If (a) has file scope and
    >>> if (a) is also accessed within the some_func function,
    >>> then
    >>> a += 2;
    >>> some_func(a - 1);
    >>> would be the semantically equivalent form.

    >>
    >> There is also:
    >>
    >> a++;
    >> some_func(a);
    >> a++;
    >>
    >> which might be more readable in some contexts.

    >
    > Just in case it's been missed, pete's point was about the semantics,
    > not the readability. All three re-writes have different meanings
    > if, as pete stipulates, 'a' is used inside 'some_func'. His version
    > has the same meaning (under these conditions) as the original.
    > [snip]


    In fact none of the three transformations mentioned are guaranteed
    to be semantics preserving, pete's included. More information is
    needed.

    (And no, not because of something obscure like 'a' being volatile
    or using the C preprocessor.)
     
    Tim Rentsch, Feb 16, 2013
    #13
  14. pete <> writes:

    > Tim Rentsch wrote:
    >>
    >> Ben Bacarisse <> writes:
    >>
    >> > glen herrmannsfeldt <> writes:
    >> >
    >> >> pete <> wrote:
    >> >>> Keith Thompson wrote:
    >> >>>> Xavier Roche <> writes:
    >> >>
    >> >> (snip)
    >> >>
    >> >>>> > some_func((a++, a++))
    >> >>>> > will have a defined behavior
    >> >>>> > (comma is a sequence point)
    >> >>>> > (some_func takes one argument here)
    >> >>
    >> >> (snip)
    >> >>>> some_func(a+1);
    >> >>>> a += 2;
    >> >>
    >> >>>> If you're writing a compiler, you have to get this stuff right.
    >> >>>> If you're writing code, clarity is important.
    >> >>
    >> >>> If (a) has file scope and
    >> >>> if (a) is also accessed within the some_func function,
    >> >>> then
    >> >>> a += 2;
    >> >>> some_func(a - 1);
    >> >>> would be the semantically equivalent form.
    >> >>
    >> >> There is also:
    >> >>
    >> >> a++;
    >> >> some_func(a);
    >> >> a++;
    >> >>
    >> >> which might be more readable in some contexts.
    >> >
    >> > Just in case it's been missed, pete's point was about the semantics,
    >> > not the readability. All three re-writes have different meanings
    >> > if, as pete stipulates, 'a' is used inside 'some_func'. His version
    >> > has the same meaning (under these conditions) as the original.
    >> > [snip]

    >>
    >> In fact none of the three transformations mentioned are guaranteed
    >> to be semantics preserving, pete's included. More information is
    >> needed.
    >>
    >> (And no, not because of something obscure like 'a' being volatile
    >> or using the C preprocessor.)

    >
    > What did I miss?


    The peculiarities of floating point arithmetic.

    --
    Ben.
     
    Ben Bacarisse, Feb 16, 2013
    #14
  15. pete <> writes:

    > Ben Bacarisse wrote:
    >>
    >> pete <> writes:
    >>
    >> > Tim Rentsch wrote:
    >> >>
    >> >> Ben Bacarisse <> writes:
    >> >>
    >> >> > glen herrmannsfeldt <> writes:
    >> >> >
    >> >> >> pete <> wrote:
    >> >> >>> Keith Thompson wrote:
    >> >> >>>> Xavier Roche <> writes:
    >> >> >>
    >> >> >> (snip)
    >> >> >>
    >> >> >>>> > some_func((a++, a++))
    >> >> >>>> > will have a defined behavior
    >> >> >>>> > (comma is a sequence point)
    >> >> >>>> > (some_func takes one argument here)
    >> >> >>
    >> >> >> (snip)
    >> >> >>>> some_func(a+1);
    >> >> >>>> a += 2;
    >> >> >>
    >> >> >>>> If you're writing a compiler,
    >> >> >>>> you have to get this stuff right.
    >> >> >>>> If you're writing code, clarity is important.
    >> >> >>
    >> >> >>> If (a) has file scope and
    >> >> >>> if (a) is also accessed within the some_func function,
    >> >> >>> then
    >> >> >>> a += 2;
    >> >> >>> some_func(a - 1);
    >> >> >>> would be the semantically equivalent form.
    >> >> >>
    >> >> >> There is also:
    >> >> >>
    >> >> >> a++;
    >> >> >> some_func(a);
    >> >> >> a++;
    >> >> >>
    >> >> >> which might be more readable in some contexts.
    >> >> >
    >> >> > Just in case it's been missed,
    >> >> > pete's point was about the semantics,
    >> >> > not the readability. All three re-writes have different meanings
    >> >> > if, as pete stipulates, 'a' is used inside 'some_func'.
    >> >> > His version
    >> >> > has the same meaning (under these conditions) as the original.
    >> >> > [snip]
    >> >>
    >> >> In fact none of the three transformations mentioned are guaranteed
    >> >> to be semantics preserving, pete's included. More information is
    >> >> needed.
    >> >>
    >> >> (And no, not because of something obscure like 'a' being volatile
    >> >> or using the C preprocessor.)
    >> >
    >> > What did I miss?

    >>
    >> The peculiarities of floating point arithmetic.

    >
    > The post by Keith Thompson,
    > which introduced the some_func function to this thread,
    > showed (a) as being declared as type int in the original post.
    > The scope of (a) was not specifed in the original post.


    It's clear that Tim Rentsch is considered the code to be separated from
    the original declaration of 'a' (now long snipped) or there would have
    been no need to rule out the possibility of 'a' being declared volatile.

    However, my reply suggested that I knew what he was thinking of and
    of course I don't. I should have ended with a question mark, not a full
    stop. He will, no doubt, explain it all soon.

    --
    Ben.
     
    Ben Bacarisse, Feb 17, 2013
    #15
  16. Adee

    Tim Rentsch Guest

    Ben Bacarisse <> writes:

    > pete <> writes:
    >
    >> Ben Bacarisse wrote:
    >>>
    >>> pete <> writes:
    >>>
    >>> > Tim Rentsch wrote:
    >>> >>
    >>> >> Ben Bacarisse <> writes:
    >>> >>
    >>> >> > glen herrmannsfeldt <> writes:
    >>> >> >
    >>> >> >> pete <> wrote:
    >>> >> >>> Keith Thompson wrote:
    >>> >> >>>> Xavier Roche <> writes:
    >>> >> >>
    >>> >> >> (snip)
    >>> >> >>
    >>> >> >>>> > some_func((a++, a++))
    >>> >> >>>> > will have a defined behavior
    >>> >> >>>> > (comma is a sequence point)
    >>> >> >>>> > (some_func takes one argument here)
    >>> >> >>
    >>> >> >> (snip)
    >>> >> >>>> some_func(a+1);
    >>> >> >>>> a += 2;
    >>> >> >>
    >>> >> >>>> If you're writing a compiler,
    >>> >> >>>> you have to get this stuff right.
    >>> >> >>>> If you're writing code, clarity is important.
    >>> >> >>
    >>> >> >>> If (a) has file scope and
    >>> >> >>> if (a) is also accessed within the some_func function,
    >>> >> >>> then
    >>> >> >>> a += 2;
    >>> >> >>> some_func(a - 1);
    >>> >> >>> would be the semantically equivalent form.
    >>> >> >>
    >>> >> >> There is also:
    >>> >> >>
    >>> >> >> a++;
    >>> >> >> some_func(a);
    >>> >> >> a++;
    >>> >> >>
    >>> >> >> which might be more readable in some contexts.
    >>> >> >
    >>> >> > Just in case it's been missed,
    >>> >> > pete's point was about the semantics,
    >>> >> > not the readability. All three re-writes have different meanings
    >>> >> > if, as pete stipulates, 'a' is used inside 'some_func'.
    >>> >> > His version
    >>> >> > has the same meaning (under these conditions) as the original.
    >>> >> > [snip]
    >>> >>
    >>> >> In fact none of the three transformations mentioned are guaranteed
    >>> >> to be semantics preserving, pete's included. More information is
    >>> >> needed.
    >>> >>
    >>> >> (And no, not because of something obscure like 'a' being volatile
    >>> >> or using the C preprocessor.)
    >>> >
    >>> > What did I miss?
    >>>
    >>> The peculiarities of floating point arithmetic.

    >>
    >> The post by Keith Thompson,
    >> which introduced the some_func function to this thread,
    >> showed (a) as being declared as type int in the original post.
    >> The scope of (a) was not specifed in the original post.

    >
    > It's clear that Tim Rentsch is considered the code to be separated from
    > the original declaration of 'a' (now long snipped) or there would have
    > been no need to rule out the possibility of 'a' being declared volatile.


    Right. There wasn't any mention of int, or declaration of a, in
    Xavier Roche's post, which I took to be the head of the subthread
    (and consequently is as far back as I checked). Moreover, the
    mention of 'a' possibly being global seems to assume a different
    context than those earlier postings, which gave the impression
    (to me anyway) that 'a' was declared in block scope. (Or there
    may have been a nested declaration hiding the outer 'a'.)

    > However, my reply suggested that I knew what he was thinking of and
    > of course I don't. I should have ended with a question mark, not a full
    > stop. He will, no doubt, explain it all soon.


    Actually I didn't think of floating point types. If I had I
    might have mentioned them along with volatile etc -- a problem in
    theory, but unlikely to occur in practice.

    A more typical case, and one relatively likely to occur in actual
    code, is when 'a' has a type like unsigned char or unsigned
    short. If the value of a is about to wrap around, 'a++' is (in
    most implementations) not the same as '(a += 1)-1', because of
    integer type promotion rules.
     
    Tim Rentsch, Feb 17, 2013
    #16
  17. Adee

    Tim Rentsch Guest

    pete <> writes:

    > Tim Rentsch wrote:
    >>
    >>> [.. alternative was of expressing a call like foo( (a++,a++) ) ..]

    >>
    >> In fact none of the three transformations mentioned are guaranteed
    >> to be semantics preserving, pete's included. More information is
    >> needed.
    >>
    >> (And no, not because of something obscure like 'a' being volatile
    >> or using the C preprocessor.)

    >
    > What did I miss?


    Explanation given in response to Ben Bacarisse's post downthread.
     
    Tim Rentsch, Feb 17, 2013
    #17
  18. Adee

    Shao Miller Guest

    On 2/14/2013 13:41, Adee wrote:
    > Well yesterday I came across a strange behaviour of C program i.e.
    >
    > let suppose we have three integers
    > int a=5, b=6, c=7;
    >
    > if(c>b , b>a)
    > printf("C is greater %d",c);
    >
    >
    > this if statment is working, I am surprised about it. Can anyone explain this feature to me. Thanks
    >


    A comma operator is a binary operator, with a left and a right operand.
    The value of the result of the comma operator is the value of the
    right operand. So:

    (1, 0) == 0
    (0, 1) == 1
    (13, 42) == 42

    So:

    (c > b, b > a) == (b > a)

    Maybe you would be more interested in the logical operators, such as
    '&&' and '||'.

    (c > b && b > a) == 1

    in your code example, above.

    --
    - Shao Miller
    --
    "Thank you for the kind words; those are the kind of words I like to hear.

    Cheerily," -- Richard Harter
     
    Shao Miller, Feb 17, 2013
    #18
  19. Adee <> writes:
    > Well yesterday I came across a strange behaviour of C program i.e.
    >
    > let suppose we have three integers
    > int a=5, b=6, c=7;
    >
    > if(c>b , b>a)
    > printf("C is greater %d",c);
    >
    >
    > this if statment is working, I am surprised about it. Can anyone
    > explain this feature to me. Thanks


    Where did you come across this? Did you write the code yourself? What
    exactly did you expect it to do?

    C makes it very easy to make mistakes that radically alter the meaning
    of a piece of code without making it illegal.

    We can speculate that what you really wanted to write was:

    if (c > b && b > a)

    but we can't be sure of that if you don't tell us.

    We can tell you exactly what a given chunk of C code actually means,
    but that's only part of the picture. A programmer's task more
    commonly starts with something you want to do, and asks what code
    to write to accomplish it. If your goal is to learn the language
    rather than to solve random little puzzles, we can be far more
    helpful if you provide us with more context.

    For example, if my guess about what you were trying to do is correct,
    you might have asked:

    Given
    int a=5, b=6, c=7;
    I want to test whether the value of b is between the values of a
    and c. I was surprised to find that this:
    if (c > b, b > a)
    actually works. Can you explain why?

    We could have told you both why your code behaves the way it does, and
    what you should have written.

    But I'm still not sure what you were really trying to accomplish. Only
    you can tell us that.

    The more context you can give us, the better job we can do of both
    answering your direct question and giving you the knowledge that
    will let you answer the next question yourself.

    Also, the output of your printf call:
    printf("C is greater %d",c);
    will be:
    C is greater 7
    which is confusing (even ignoring that "c" and "C" are two different
    identifiers).

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, Feb 17, 2013
    #19
    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. Alexander Korsunsky

    break inside of case- statement inside of loop

    Alexander Korsunsky, Feb 25, 2007, in forum: C Programming
    Replies:
    25
    Views:
    1,105
    Richard Heathfield
    Feb 27, 2007
  2. Junior
    Replies:
    4
    Views:
    329
    Dennis Lee Bieber
    Oct 27, 2007
  3. Vincent Rivière

    Comma inside macro

    Vincent Rivière, Apr 13, 2008, in forum: C++
    Replies:
    2
    Views:
    1,431
    Vincent Rivière
    Apr 13, 2008
  4. Bret
    Replies:
    3
    Views:
    2,628
    Terry Reedy
    Jun 9, 2009
  5. Test
    Replies:
    40
    Views:
    643
    Tim Rentsch
    Dec 20, 2012
Loading...

Share This Page