is there a good argument for allowing them? if not, should they generate a syntax or parse error? (note: some function calls might have no effect but since it may be impossible to determine whether they do or not, they should probably be excluded from this category.)
examples of what I'm talking about are:
the last example also illustrates how a typo can cause bugs that are difficult to find.Code:j; ;;;;; for(;;);{}
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
The only one I can come up with right now is this.Originally Posted by Sebastiani
Here the null statement is just that on purpose. It produces a syntax error if it is omitted.Code:void foo(int value) { switch ( value ) { case 1: puts("Selection 1"); break; default: ; } printf("value = %d\n", value); }
Regarding this, a good compiler/linter ought to mention it:And this is has a useful purpose as well.Code:j;It could be waiting for an interrupt and then need some variables with block scope. Not that things couldn't be written differently.Code:for(;;);{}
Good indenting and commenting can help avoid issues with any of these.
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.*
Blank statements are sometimes necessary.
thanks for the input, guys. I'm working on a compiler in my spare time (a superset of C++) and I was considering omitting no-ops from the language. do you think it's warranted - or should I just leave well enough alone? any input would be appreciated.
>> The only one I can come up with right now is this.
true, but couldn't the default statement be left out altogether?
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Not 100% sure about this one but i could have sworn GCC will stop compiling the code after it hits a infinite loop.
ex:
The above when disassembled with gdb would be all the assembly until the for() everything afterwards does not exist? Am i misunderstanding the situation?Code:#include <stdio.h> int main() { for(;;); printf("hello\n"); return 0; }
Well I wouldn't ever see a need for
but maybe for something like thisCode:for(;;);
Code:for(int i = 0; i<MAX; cout<<array[i++]<<endl) ;
>> but maybe for something like this
or this:
it just seems to me that they serve no useful purpose, and that we'd be better off if they hadn't been incorporated into the language in the first place. I think I'll allow them, though - if only for the sake of portability. thanks again for the input, everyone.Code:for(int i = 0; i<MAX; cout<<array[i++]<<endl) continue;
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
If ANSI/C99 says it's allowed, you'd better make it allowed. Remember what went with Miracle C.
You could just throw a warning. It is a good middle ground at least you let the programmer know that something may be up.
Woop?
Apart from examples above where empty statements are useful (even though their need may be debatable), empty statements occur a lot in automatically generated code. They have no effect, and it is difficult in some programs (eg code generators that parse something else to generate code) to eliminate them.
I'd suggest not eliminating them altogether. Having a warning about their presence (preferably a warning that can be turned off, if desired) would be useful for picking up coding errors in hand-written code.
excellent suggestion. I think I'll go that route. thank you.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
That would do nothing because the action would never be executed.
As far as I can tell it should work. continue skips over the rest of the loop body, but not over the post-iteration expression.That would do nothing because the action would never be executed.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Do you propose support for a pre-processor as well?
Because things like this could easily result in empty statements with varying conditional compilation flags.
LOGMSG may or may not be a macro which may or may not expand to nothing.Code:if ( somecond ) { #ifdef TEST printf( "something happened\n" ); #endif LOGMSG("a message"); }
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
More importantly: Tell us about this language, Seb!
Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife.
- Mike McShaffry
