I prefer the following style:
if ( a )
foo();
else // <- line break after else
if ( b )
bar();
However, clang-format seems to always want to glue 'else if' together on the same line. Is there a way to achieve what I want with clang-format?
Related
I'm trying to make a program that outputs the most used character in a file.
Why does the compiler give me an error when I try this:
for (char i = 97 ; i <=122 ; i ++) {
switch (x) {
case i :
break;
}
}
This code uses a switch to get the most used characters. The error is :
'i' cannot appear in a constant-expression
case labels need to be compile time constants, and you are trying to use variable i, so you get the rather descriptive error message.
If you need to test against variables, the direct replacement is if-else if-...-else ladder. Though your simple case has no "else" part, Additionally, break breaks out of the switch, so you can't use it to break out of a loop then (direct replacement would be to use goto but it's far better to rethink your logic in almost all cases).
So write your code like this:
for (char i = 97 ; i <=122 ; i ++) {
if (x == i) {
break; // did you mean to break the loop?
}
}
I usually work with C#, so please bear with me. Also, the code was written by someone else.
The code essentially outputs some information to a text file, and for some reason, at midnight, the file was only exported with carriage returns and line separators (ie. no actual data).
After debugging it, I noticed that the debugger breaks on a continue;, but then anything after that line in the FOR loop (in init2) is not being executed.
Due to the complexity of the code, I had to remove most of it. But I've included where all the FOR loops are. I just need to know what the CONTINUE is doing that skips where the "important stuff" is being output.
Any help is appreciated. Thanks.
for ( init1; condition; increment ) {
for ( init2; condition; increment ) {
CODE;
for ( init3; condition; increment ) {
CODE;
if (condition) {
CODE;
}
CODE;
}
if (condition) continue; //Always breaks here
CODE; //Never breaks here
if (condition) { //Never breaks here, so important stuff is not output to file.
for ( init4; condition; increment ) {
fprintf_s(fp, "Output important stuff");
}
fprintf_s(fp, "\n");
}
}
if (statement) { //This code runs and the following is printed.
fprintf_s(fp, "----------------------------------------------------------\n");
}
}
It seems like the problem is your condition inside the if statement. I'm not sure that we can provide you further help if we don't see the actual code.
This question already has answers here:
How to break out of a loop from inside a switch?
(20 answers)
Closed 9 years ago.
This isn't a specific problem that I actually am trying to implement, but it ocurred to me that I do not know how to do this, so I will give a simple example to illustrate:
Suppose we have a while loop containing a switch statement, for instance:
while(some_cond){
switch(some_var){
case 1:
foo();
break;
case 2:
bar();
break;
}
}
what would we do if we wanted to break out of the while loop in case 1, say?
We can't do break; break;, since the second will never happen.
We also can't do break *un*conditionally in the while loop, since this would happen in any case.
Do we have no choice but to if (some_var == 1) break; in the while loop, or else append && !flag) to the while condition, and set flag = 1?
Various options, in approximate order of tastefulness:
Move the loop into a separate function. Use return to stop looping.
Replace while(1) with while(looping) and set to false to stop looping. Use continue if you need to skip the rest of the current iteration.
Use goto to jump past the end of the loop. How bad can it be?
Surround the loop with a try block, and throw something to stop looping.
You can use goto (don't go too wild with goto though).
while ( ... ) {
switch( ... ) {
case ...:
goto exit_loop;
}
}
exit_loop: ;
Have your while use a variable modified within your loop.
bool shoulEnterLoop = true;
while(shoulEnterLoop ){
switch(some_var){
case 1:
if ( !foo() )
shoulEnterLoop = false;
break;
case 2:
bar();
break;
}
}
I was wondering if there is any way to add braces in nested If-else using Uncrustify. For example:
if( stat_error == -1 ){
if ( debug > 0 )
printf( "...ERROR ); //I would like to add braces around here.
exit( -1 );
} else {
I have seen this:
# Add or remove braces on single-line 'if' statement. Will not remove the braces if they contain an 'else'.
mod_full_brace_if = add # ignore/add/remove/force
But it doesn't seem to work for nested conditionals.
Is there any way to do it?
My experience with Uncrustify in your example :
Add or remove braces on single - line if statement. Will not remove the braces if they contain an else.
mod_full_brace_if = add
Make all if / elseif / else statements in a chain be braced or not. Overrides mod_full_brace_if.
If any must be braced, they are all braced. If all can be unbraced, then the braces are removed.
mod_full_brace_if_chain = false
And it worked for me.
you need to add a return statement should look like this
if( stat_error == -1 ){
if ( debug > 0 )
printf( "...ERROR ); //I would like to add braces around here.
exit( -1 );
} else{
Insert else statement
}
return statement here
}
I have the following code segment:
for ( SID_AND_ATTRIBUTES* it = ptg->Groups; end != it; ++it )
if ( EqualSid( it->Sid, pAdminSid ) )
break;
bIsAdmin = end != it;
Irritatingly, when step-by-step debugging in VS, the final line is executed with each of the for iterations. I was expecting the above code segment would behave identical to:
for ( SID_AND_ATTRIBUTES* it = ptg->Groups; end != it; ++it ) {
if ( EqualSid( it->Sid, pAdminSid ) )
break;
}
bIsAdmin = end != it;
Can somebody explain why this is not the case?
When there is "only one semicolon", there is no need for braces. Although I'm one of those people that like to put extra braces in my code, just in case. It never hurts, really...
As to the stepping behaviour, I've seen this too in both Visual Studio and Eclipse debuggers. I think it reflects the "end of the loop has to be on some line" - so if there is no ending brace, the last line within the loop contains the "is the loop finished" step. Annoying it is indeed.