Why don't toy use ( and ) instead of { and }?

This is a discussion on Why don't toy use ( and ) instead of { and }? within the C Programming forums, part of the General Programming Boards category; There is some cases where you need { and }, for example declarations of functions, structures, enumerators, etc. But in ...

  1. #1
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286

    Why don't use ( and ) instead of { and }?

    There is some cases where you need { and }, for example declarations of functions, structures, enumerators, etc. But in normal code, when you just want to go a scope deeper, and you don't need to declare any new variables that is suposed to disappear when you go out of scope, couldn't you use ( and ) instead of { and }, and commas instead of semicolons?
    Last edited by TriKri; 07-31-2006 at 08:09 PM.

  2. #2
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    You mean like this?
    Code:
    if(x) (
        y;
        z;
    )
    instead of
    Code:
    if(x) {
        y;
        z;
    }
    That doesn't work (as you'll see if you try to compile it.) It goes against the syntax of C.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  3. #3
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    We don't do that because that would be stupid.
    Code:
    int foo[] = ( ( 1 + 2 ), (3 + 3), ( x / ( y + z )  ) );
    What is sizeof( foo )? Now for the tricky part, what size did I mean for it to be?

    We could even make this more fun, by replacing int with struct baz.


    Quzah.
    Last edited by quzah; 07-31-2006 at 04:01 PM.
    Hope is the first step on the road to disappointment.

  4. #4
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,627
    Three! ... four? ... three elements. Uhm, and it might be 12 bytes long. Maybe. @.@
    TriKi would like lisp, but lisp is not C.

  5. #5
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Or is it one element?


    Quzah.
    Hope is the first step on the road to disappointment.

  6. #6
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,627
    It depends. If we're still compiling C and we didn't use macros to change stuff, then sure.

    Anyway the fact that it confuses me is reason enough not to do things the OP's way. I don't know the rules.

  7. #7
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    That was my point. That's why we don't use only ( ), because there is no way to know what I intended with that line of code. I could have meant one element, I could have meant three. No way to know. This is why we have { } and ( ), and don't just use one type.


    Quzah.
    Hope is the first step on the road to disappointment.

  8. #8
    Dump Truck Internet valis's Avatar
    Join Date
    Jul 2005
    Posts
    357
    Pick up ISO/IEC 9899:TC2 and go to page 304, it has the grammar, this will show you why you can't use () instead of {}.
    Just a decision on the committees part, but the reason is likely some of those mentioned above.

  9. #9
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Or just read this thread, because we've already covered it. :P


    Quzah.
    Hope is the first step on the road to disappointment.

  10. #10
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286
    I didn't mean allways, but in some cases, doesn't it work as good using parenthesis? In dwks' case I would rather write

    Code:
    if(x) (
        y,
        z
    );
    I believe. I mean, if you write macros, using () to incapsel many statements instead of {} will also give a return value, the return value of the last statement, won't it? I mean then maybe it can be better sometimes to write () when writing macros instead of {}?

  11. #11
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    You don't use ( ) to encapsulate many statements. You use { }. Macros are nothing more than compile time text subsitution. They're not functions, and they don't return anything.


    Quzah.
    Hope is the first step on the road to disappointment.

  12. #12
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286
    Quote Originally Posted by quzah
    You don't use ( ) to encapsulate many statements. You use { }. Macros are nothing more than compile time text subsitution. They're not functions, and they don't return anything.


    Quzah.
    Why not? It is possible, right?

  13. #13
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,162
    using () to incapsel many statements instead of {} will also give a return value, the return value of the last statement, won't it?
    No. The following are identical in C:
    Code:
    a = b = c;
    a = (b = c);
    The parentheses don't force something to return a value.
    If you understand what you're doing, you're not learning anything.

  14. #14
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286
    Quote Originally Posted by itsme86
    No. The following are identical in C:
    Code:
    a = b = c;
    a = (b = c);
    The parentheses don't force something to return a value.
    What do you mean? In your case it returned a value!

  15. #15
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    TriKri: I am still wondering whether you are a troll or not. Why don't you provide some samples of what you are asking instead of asking vague questions and preying on the replies?
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21