While in other statements like if ... else you can avoid braces if there is only one instruction in a block, you cannot do that with try ... catch blocks: the compiler doesn't buy it. For instance:
try
do_something_risky();
catch (...)
std::cerr << "Blast!" << std::endl;
With the code above, g++ simply says it expects a '{' before do_something_risky(). Why this difference of behavior between try ... catch and, say, if ... else ?
Thanks!
Straight from the C++ spec:
try-block:
try compound-statement handler-seq
As you can see, all try-blocks expect a compound-statement. By definition a compound statement is multiple statements wrapped in braces.
Have everything in a compound-statement ensures that a new scope is generated for the try-block. It also makes everything slightly easier to read in my opinion.
You can check it yourself on page 359 of the C++ Language Specification
Not sure why, but one benefit is that there is no dangling-catch issue. See dangling-else for an ambiguity that can arise when braces are optional.
The syntax of try-block is:
try compound-statement handler-sequence
where handler-sequence is a sequence of one or more handlers, which have the following syntax:
catch (type-specifier-seq declarator) compound-statement
catch (...) compound-statement
This is different from other statements like control statements (if, while, for, etc). The syntax for these are:
if (condition) statement-true else statement-false
while (condition) statement
for (init-statement; condition; iteration_expression) statement
etc.
Now, The question is why compound-statement is needed in the try-block instead of a single statement?
Think about this code:
int main()
{
// before try-statement.
try g(); catch (std::runtime_error e) handleError(e);
// after try-statement.
}
I know, catch by value is a bad practice (e.g. possible object slicing, etc), but I did it in order to prevent a discussion about the storage duration of the exception and make it easy to reason about.
Now think, about the storage duration and linkage of 'e'. What you expect, is that 'e' only can be referred just before the call to handleError function, but no after the call is completed. It should have automatic storage duration and no linkage in this "scope". This could probably done by implicitly define a local scope like in other statements, but make the exception-declaration looks like a function parameter was probably a better idea. So the block (compound-statement) is needed. Se bellow.
Now think about the try and the statement after that. There is no reason to use the keyword try there, and no reason to use a compound statement, but the syntax could become ambiguous and complicated.
This is what Stroustrup said about it in Exception Handling for C++:
It might be possible to simplify the
try { ... } catch (abc) { ... }
syntax by removing the apparently redundant try keyword,
removing the redundant parentheses, and by allowing a handler
to be attached to any statement and not just to a block. For
example, one might allow:
void f()
{
g(); catch (x1) { /* ... */ }
}
as an alternative to - 28 -
void f()
{
try { g(); } catch (x1) { /* ... */ }
}
The added notational convenience seems insignificant and may not
even be convenient. People seem to prefer syntactic constructs that
start with a prefix that alerts them to what is going on, and it may
be easier to generate good code when the try keyword is required.
And after a more detailed explanation:
Allowing exception handlers to be attached to blocks only and not to
simple statements simplifies syntax analysis (both for humans and
computers) where several exceptions are caught and where nested
exception handlers are considered (see Appendix E). For example,
assuming that we allowed handlers to be attached to any statement
we could write:
try try f(); catch (x) { ... } catch (y) { ... } catch (z) { ... }
The could be interpreted be in at least three ways:
try { try f(); catch (x) { ... } } catch (y) { ... } catch (z) { ... }
try { try f(); catch (x) { ... } catch (y) { ... } } catch (z) { ... }
try { try f(); catch (x) { ... } catch (y) { ... } catch (z) { ... } }
There seems to be no reason to allow these ambiguities even if there
is a trivial and systematic way for a parser to chose one
interpretation over another. Consequently, a { is required after a
try and a matching } before the first of the associated sequence of
catch clauses.
As Stroustrup said, without the braces, the statement could mean different things depending on the rule and you will probably need to put braces to clarify the intension. Can we make some that looks complicated with the if-statement like in Stroustrup's example? Of course we can, something like this for example:
if (c1) if (c2) f(); else if (c3) g(); else h();
This is actually equivalent to:
if (c1) { if (c2) f(); else { if (c3) g(); else h(); } }
But I think this is less problematic than the case of try-block. There is two syntax for the if-statament:
if (condition) statement-true
if (condition) statement-true else statement-false
because it make sense not to have a else action sometimes. But it make no sense a try-block without a catch-clause. The 'try' can be omitted but not practical, as Stroustrup said, but the catch-clause can not if you specified a try-block. Beside of this, there could be more than one catch related to the same try-block but only one is executed based in rules that depends on the exception type and order of the catch-clauses.
Now, what if the syntax of if-else is changed to:
if (condition) compound-statement-true else compound-statement-false
then, you must write if-else like this:
if (c1) { f(); } else { if (c2) { g(); } else { h(); } }
See that there is no 'elseif' keyword, no special syntax for 'else if'. I think that even the 'put braces always' defenders don't like to write like this, and write this instead:
if (c1) { f(); } else if (c2) { g(); } else { h(); }
I think that this is not a strong reason to define the syntax as above and introduce in the language a 'elseif' keyword or define a special syntax for 'else if'.
Read this link. Most of the reason appears to be about managing the scope and allocation of objects that need to be created and destroyed in case of real exceptions.
So, my guess is, the grammar writers of C++ are asking the authors of g++(or any standards complying C++ compiler) to prepare it for the worst possible cases, and g++ authors appear to have done so.
Why? A tradeoff between safety and backwards compatibility.
The lessons learnt from if...else showed that requiring braces eliminates errors. Now, the ISO C++ people have a strong preference for backwards compatibility with C, so they didn't change the C syntax for if...else. But new constructs require braces to demarcate controlled blocks, as they won't appear in old C code and therefore backwards compatibility is not a concern.
Well, first, that's how the grammar works.
Second, I would believe that the goal is to forcibly generate a new scope for the exception blocks(correct me if I'm wrong).
That's how they wanted to be. There is no justification, it's a law.
Not sure if you're using .NET but the CLR uses the braces as flags.
http://dotnet.sys-con.com/node/44398
From the article: "The SEH (structure exception handling) table consists of a set of clauses that describe the structure of the guarded code. The table has a set of binary flags that describe the type of exception handling clause: a Try Offset flag, which is the beginning of the guarded code block; a Try Length flag, which is the length of the guarded code; Handler Offset and Handler Length flags, which detail the beginning of the exception handler block and its length; and a Class Token or Filter Offset flag, depending on the type of Exception Handler that was defined. This information allows the CLR to determine what to do when an exception occurs. It maps out the beginning of the guarded code block, the code to execute for an exception, and special semantics related to filtering or other special circumstance."
I would assume that other frameworks do the same thing.
Mainly it's because
if (a)
int b = 10;
else
int b = 5;
b += 5;
Will fail because the if...else without {} is a syntax shortcut for this
if (a) {
int b = 10;
} else {
int b = 5;
}
b += 5;
which explicitly tells you that int b is in a different scope than the rest of the software.
If I'm not mistaken the following also fails
a ? int b = 10 : int b = 5;
b += 5;
Granted, your compiler might optimize that code for you... but it should technically fail because of the scopes in the if/else statement.
Whenever you see {} you're defining the scope of the software.
-Stephen
Related
C++17 has selection statements with initializer
status_code foo() {
if (status_code c = bar(); c != SUCCESS) {
return c;
}
// ...
}
I'd like to write a while-loop and a variable with a scope limited to the loop and initialized only once before the first iteration.
// fake example, doesn't compile, is doable in many ways
while (bool keep_trying = foo(); keep_trying) {
// do stuff
if (something)
keep_trying = false;
}
Is there anything for this in C++17 or maybe coming in C++2a?
P0305R1, the paper that introduced the if statement with initialization, explains this pretty well. From the Proposal section:
There are three statements in C++, if, for and while, which are all
variations on a theme. We propose to make the picture more complete by
adding a new form of if statement.
while (cond) E;
for (init; cond; inc) E;
if (cond) E;
if (cond) E; else F;
if (init; cond) E; (new!)
if (init; cond) E; else F; (new!)
(table simplified)
Note that while (cond) corresponds to for (init; cond; inc). Also, from the Discussion section:
It is often said that C++ is already complex enough, and any
additional complexity needs to be carefully justified. We believe that
the proposed extension is natural and unsurprising, and thus adds
minimal complexity, and perhaps even removes some of the existing
differences among the various control flow statements. There is
nothing about the local initialization that is specific to loop
statements, so having it only on the loop and not on the selection
statement seems arbitrary. Had the initializer form of the if
statement been in the language from the start, it would not have
seemed out of place. (At best one might have wondered why for is not
also spelled while, or vice versa.)
"While statement with initializer" = "For statement without updation"
And you have always had a for loop regardless of the version of the language.
In C and in javascript I enjoy the ability to write this kind of thing and have it just work.
while (a)
{
ctx: while(b)
{
while (c)
{
if(d) break ctx;
...
}
}
...
}
Perhaps I'm just confused about C++ versions but I get this kind of error in g++:
error: expected ‘;’ before ‘ctx’
break ctx;
error: ‘ctx’ was not declared in this scope
warning: label ‘ctx’ defined but not used [-Wunused-label]
ctx:
C++ appears to refuse letting me write this code.
C++ has added lambdas/closures that potentially would let me do this but I'm not quite sure how they would work in this case.
Using try throw catch is the closest construct I can think of that produces this behavior but the sloppiness of using an error system when none should be needed concerns me (Also they are slow I hear).
I'm tempted to just wrap it in extern C except I'm relying on c++ library's completely for the entire project so this also feels sloppy.
Is a try block or just rewriting my only options?
Neither C nor C++ have a labelled break statement (You're probably using a language extension, rather than standard C).
Instead, you can use goto to break out of a nested loop.
while (a)
{
while(b)
{
while (c)
{
if(d)
goto break_b;
}
}
break_b:
// ...
}
I was able to use goto to solve this... I though it was a banned construct in c++?
No. goto is not "banned" in C++.
This is a completely fine way to use goto. There doesn't exist an equivalent structured control statement.
lambdas/closures [...] potentially would let me do this but I'm not quite sure how they would work in this case.
If you are allergic to goto, then you can indeed use a lambda, but I don't see it providing any additional readability:
while (a)
{
[&](){
while(b)
{
while (c)
{
if(d)
return;
}
}
}();
// ...
}
Instead of a lambda, you can use a named function. But in that case you need to pass any variables (such as b, c and d) as arguments (assuming they're not globals).
Yet another way is an extra variable:
while (a)
{
bool break_b = false;
while(b)
{
while (c)
{
if(d) {
break_b = true;
break;
}
}
if (break_b)
break;
}
// ...
}
Of these three methods, I recommend goto, since it's the most readable. Except in the case the actual inner loop omitted from the example is very long, in which case a separate function might be better.
As has already been pointed out by others, goto would be a way to do exactly what you're asking for.
That being said, I would argue that, before asking the question of how to break out of a massively-complicated control flow structure, you should first ask yourself why there is a massively-complicated flow structure to begin with. What is going on in these loops? Should whatever is going on in each of these loops not better be moved into its own function? For example, instead of
while (a)
{
ctx: while (b)
{
while (c)
{
if (d) goto ctx;
…
}
}
…
}
why not
bool doC()
{
while (c)
{
if (d)
return false;
…
}
return true;
}
void doB()
{
while (b && doC());
}
and then
while (a)
{
doB();
…
}
Replacing the break with a goto here is not advisable. There can be issues wrt constructors and destructors not being called correctly. Whilst goto still exists in C++, it's really not something you want to use unless you really know what you're doing! A safer option would be to use a try-catch block. A better approach would be to re-factor your algorithm (currently it's O(N^3), which should really be ringing some alarm bells!)
while (a)
{
try
{
while(b)
{
while (c)
{
if(d) throw;
}
}
}
catch(...)
{
}
}
Today, i spent 4 hours debugging a little mistake:
while (++i < nb); //Notice this semicolon that i put by mistake
{
do_stuff();
}
I didn't know why the do_stuff didn't execute enough times.
When I saw my mistake, I wondered: Why the hell would someone enclose codes into braces in the middle of a function??
Can someone have an explanation? Is that the way C languages evolved ? (I know the BNF of C contains some weird things due to retro compatibility reasons)
And do you think pre incrementation in a loop is a bad thing, that I should write like above instead?
while (i < nb)
{
do_stuff();
i += 1;
}
Why the hell would someone enclose codes into braces in the middle of a function??
Thats not a strange think at all, but it introduces a scope, as in the following example:
void foo () {
int a;
{ // start a new scope
int b = 1;
std::cout << b << std::endl;
} // end of scope, i.e. b is out of scope now
std::cout << a << std::endl;
std::cout << b << std::endl; // error: unknown variable b !!
double b = 0.0; // just fine: declares a new variable
}
You can use it to localize the accessability of variables inside functions. In the example b is a temporary and by putting its declaration inside a local scope I avoid spamming the function scope with variable names.
You might want to put all the logic inside the while and omit body intentionally. Some compilers will warn you about that, ie. clang:
main.cpp:18:17: warning: while loop has empty body [-Wempty-body]
while (++i < nb); //Notice this semicolon that i put by mistake
^
main.cpp:18:17: note: put the semicolon on a separate line to silence this warning
Introducing of local scopes like:
{
SomeClass aa;
// some logic
}
is also not uncommon, you might want, in above someone might want aa destructor to be called before the closing braces - ie. it will release some resource.
I believe most common use is together with RAII:
{
std::lock_guard<std::mutex> lock(mutex);
// code inside block is under mutex lock
}
// here mutex is released
Local scopes make sense to limit the life time and scope of objects. They are vital to switch/case statements:
switch (i){
case 1:
std::string s;
case 2:
//does s exist or not? depends on the value of i
}
C++ says this is straight-up illegal. To fix this you introduce a local scope:
switch (i){
case 1:
{
std::string s;
}//the lifetime of s ends here
case 2:
//s is inaccessible
}
Now s is limited to its scope and you solved the problem of s being sometimes defined.
You can add as many local blocks as you want, for example this is fine:
int main(){{{{{{{{{{
}}}}}}}}}}
{<statement>*} (* means zero or more) are code blocks in C/C++ and are treated as a single statement.
Statements are things like if (<expression>) <statement> (note: this is a recursive statement).
Another statement could be <expression>;.
Also {} generates a new scope.
This is also the reason why you can give multiple statements in an if statement.
If it helps, you can think of them as inline functions, with access to the current scope. (Not a correct way to view it, but close enough)
Look at #tobi303's answer for an example.
When refactoring some code, I often encounter this :
bool highLevelFunc foo()
{
// ...
bool result = LesserLevelFunc();
if (!result) return false;
// ... Keep having fun if we didn't return
}
Is there any way to make this a little more sexy and less verbose ? Without any overhead or pitfall of course.
I can think of a macro
#define FORWARD_IF_FALSE(r) if (!r) return r;
bool highLevelFunc foo()
{
// ...
FORWARD_IF_FALSE(LesserLevelFunc());
// ...
}
Anything better, i.e without preprocessor macro?
To me, "readable" code is sexy. I find the original code more readable than your proposal, since the original uses standard C++ syntax and the latter uses a macro which I'd have to go and look up.
If you want to be more explicit, you could say if (result == false) (or better yet, if (false == result) to prevent a possible assignment-as-comparison bug) but understanding the ! operator is a fairly reasonable expectation in my opinion.
That said, there is no reason to assign the return value to a temporary variable; you could just as easily say:
if (!LesserLevelFunc()) return false;
This is quite readable to me.
EDIT: You could also consider using exceptions instead of return values to communicate failure. If LesserLevelFunc() threw an exception, you would not need to write any special code in highLevelFunc() to check for success. The exception would propagate up through the caller to the nearest matching catch block.
Because you might be continuing if LesserLevelFunc returns true, I suggest keeping it pretty close to how it is now:
if (!LesserLevelFunc())
return false;
First of all introducing the macro you are making the code unsafe. Moreover your macro is invalid.
The expression after the negation operator shall be enclosed in parentheses.
#define FORWARD_IF_FALSE(r) if (!( r ) ) return r;
Secondly the macro calls r twice. Sometimes two calls of a function is not equivalent to one call of the same function. For example the function can have some side effects or internal flags that are switched on/off in each call of the function.
So I would keep the code as is without introducing the macro because the macro does not equivalent to the symantic of the original code.
In C++ you can initialize a variable in an if statement, like so:
if (CThing* pThing = GetThing())
{
}
Why would one consider this bad or good style? What are the benefits and disadvantages?
Personally i like this style because it limits the scope of the pThing variable, so it can never be used accidentally when it is NULL. However, i don't like that you can't do this:
if (CThing* pThing = GetThing() && pThing->IsReallySomeThing())
{
}
If there's a way to make the above work, please post. But if that's just not possible, i'd still like to know why.
Question borrowed from here, similar topic but PHP.
The important thing is that a declaration in C++ is not an expression.
bool a = (CThing* pThing = GetThing()); // not legit!!
You can't do both a declaration and boolean logic in an if statement, C++ language spec specifically allows either an expression or a declaration.
if(A *a = new A)
{
// this is legit and a is scoped here
}
How can we know whether a is defined between one term and another in an expression?
if((A *a = new A) && a->test())
{
// was a really declared before a->test?
}
Bite the bullet and use an internal if. The scope rules are useful and your logic is explicit:
if (CThing* pThing = GetThing())
{
if(pThing->IsReallySomeThing())
{
}
}
About the advantages:
It's always recommended to define variables when you first need them, not a line before. This is for improved readability of your code, since one can tell what CThing is without scrolling and searching where it was defined.
Also reducing scope to a loop/if block, causes the variable to be unreferenced after the execution of the code block, which makes it a candidate for Garbage Collection (if the language supports this feature).
if (CThing* pThing = GetThing())
It is bad style, because inside the if you are not providing a boolean expression. You are providing a CThing*.
CThing* pThing = GetThing();
if (pThing != NULL)
This is good style.
You can have initialization statements inside if and switch since C++17.
Your code would now be:
if (CThing* pThing = GetThing(); pThing->IsReallySomeThing())
{
// use pThing here
}
// pThing is out of scope here
One reason I don't normally do that is because of the common bug from a missed '=' in a conditional test. I use lint with the error/warnings set to catch those. It will then yell about all assignments inside conditionals.
Just an FYI some of the older Microsoft C++ compliers(Visual Studios 6, and .NET 2003 I think) don't quite follow the scoping rule in some instances.
for(int i = 0; i > 20; i++) {
// some code
}
cout << i << endl;
I should be out of scope, but that was/is valid code. I believe it was played off as a feature, but in my opinion it's just non compliance. Not adhering to the standards is bad. Just as a web developer about IE and Firefox.
Can someone with VS check and see if that's still valid?
This shoulddoesn't work in C++ sinceeven though it supports short circuiting evaluation. MaybeDon't try the following:
if ((CThing* pThing = GetThing()) && (pThing->IsReallySomeThing()))
{
}
err.. see Wesley Tarle's answer
So many things. First of all, bare pointers. Please avoid them by all means. Use references, optional, unique_ptr, shared_ptr. As the last resort, write your own class that deals with pointer ownership and nothing else.
Use uniform initialization if you can require C++11 (C++14 preferred to avoid C++11 defects): - it avoids = vs == confusion and it's stricter at checking the arguments if there are any.
if (CThing thing {})
{
}
Make sure to implement operator bool to get predictable conversion from CThing to bool. However, keep in mind that other people reading the code would not see operator bool right away. Explicit method calls are generally more readable and reassuring. If you can require C++17, use initializer syntax.
if (CThing thing {}; thing.is_good())
{
}
If C++17 is not an option, use a declaration above if as others have suggested.
{
CThing thing {};
if (thing.is_good())
{
}
}
You can also enclose the assignment in an extra set of ( ) to prevent the warning message.
I see that as kind of dangerous. The code below is much safer and the enclosing braces will still limit the scope of pThing in the way you want.
I'm assuming GetThing() sometimes returns NULL which is why I put that funny clause in the if() statement. It prevents IsReallySomething() being called on a NULL pointer.
{
CThing *pThing = GetThing();
if(pThing ? pThing->IsReallySomeThing() : false)
{
// Do whatever
}
}
also notice that if you're writing C++ code you want to make the compiler warning about "=" in a conditional statement (that isn't part of a declaration) an error.
It's acceptable and good coding practice. However, people who don't come from a low-level coding background would probably disagree.