More places for the semi-colen!

I realized that you can place a semi-colen after brackets.

Code:

---

struct my_struct
{
};
 
int main( void )
{
  while( void )
  {
        switch( void )
        {
        };
  }; 
};

---

And it has become a habit to put one after each function and loop and switch call. What about you guys?

No. Why would you want people that use proper syntax to wonder what statement is ending when they see a random, unnessasary semicolon?

What benefit do you see arising from this? I mean, why did you make it a habit?

Basically, since whitespace doesn't really matter, what you're doing is the same as

Code:

---

while(...) {
}
;

---

You just have the loop, and then you have an empty statement.

Actually the fact that you have to place a semicolon after a class/struct definition is mostly annoying C legacy.

So you think its such a good idea CA? Lets take your semi-colon after brackets idea and test it out

Code:

---

int main()
{
  if ( 1 == 0 )
  {
    cout<<"Blarg";
  };
  else
  {
    cout<<"Bleh";
  };
};

---

Yep that was a good idea.

Oh you are saying just loops and functions? ok

Code:

---

int main()
{
  bool startloop = true;
  int i = 0;
  if ( startloop )
    while (i < 10)
    {
      i++;
    };
  else
    cout<<"I'm not in the loop";
};

---

Moral of the story? Use them when you need them, don't just go sprinkling around your code.

>> Actually the fact that you have to place a semicolon after a class/struct definition is mostly annoying C legacy.

the fact that you have to use them at all is annoying - omitting them wouldn't create any ambiguities for the parser that I can think of...so why should they be required?

Yes it would. A new line character in the syntax does not mean it's a new line of code. I think the parser would get confused as to what was a new line and what wasn't.

>> A new line character in the syntax does not mean it's a new line of code.

I'm not saying the newline should serve as a delimiter for statements. the parser already knows that expressions are linked together with operators. if it encounters an expression where an operator is expected, it would simply treat it as a new statement. for instance:

Code:

---

j = i = foo() n = bar()

---

since 'n' is not an operator then it is the beginning of a new expression.

But what about circumstances like this:

Code:

---

j = i = foo() ++x

---

Is it foo()++ or ++x?

Code:

---

j = i = foo(); ++x;

---

Ah, it is ++x.

Code:

---

#include <stdio.h>

typedef struct {
  int x;
} foo;

int main(void) {
  foo j, k;

  k.x = 5;

  {
    struct {
      int x;
    };      /* Removing this semicolon changes output. */
    k;
    j.x = k.x;
  }

  printf("%d\n", j.x);
  return 0;
}

---

true, but I'd like to point out that both relied on the fact that the language allows statements having no effect. if that 'feature' of the language were removed (and I'd love to here an argument against that), then the intent would again be unambiguous. can you think of any examples excluding no-ops?

There needs to be some sort of statemenet delineator, otherwise there would be way too many ambiguities for the parser (even if you disallowed statements that did nothing).

For example:

Code:

---

int a = i; ++ p = &t;
int a = i ++; p = &t;

---

JScript manages without compulsory semicolons (although to avoid programmer errors it gives an error if you have two statements on one line without a seperating semicolon). So, yes, with a few minor changes to the language you could probably do without them in C.

EDIT: It seems that the application of ++ and -- in JScript, in the absence of semicolons, is somewhat complicated. You'd probably have to get rid of pre (or post) ++ and -- altogether.

Code:

---

// Post-increment on i
i  ++

j

// Pre-increment on j
i
++
j

---

>> ++p = &t;

if p is a pointer then the increment would have no effect. on the other hand, if p was an object that returned something with prefix ++ that could be attached to t then it would have an effect. so I stand corrected (it was a nice daydream anyway :D).

Here's a C snippet that changes meaning:

Code:

---

struct foo
{
  int a, b;
};

bar;

---

Here, bar is implicitely an int. If you omit the semicolon, bar is of type struct foo.