I have a code which contains this statement:
# if defined (HEAT_FLUX) || (ICE)
CALL DATA_RUN_HFX
# endif
i want to know the meaning of || in fortran.
This "||" has nothing to do with Fortran. It is a conditional expression for the preprocessor, and as #Mr.Alien mentioned means OR.
So in plain language your preprocessor directive means:
call DATA_RUN_HFX if HEAT_FLUX is defined or ICE is true.
See the documentation for details.
This isn't Fortran, in fact -- it is preprocessor statement, so it is executed at compile time to only compile the call to DATA_RUN_HTX if HEAT_FLUX is defined or ICE is true. For another question on this point (in C) see #if defined (x) || (y) ; is this valid?.
Related
I have a Verilog define like this:
`define NUM_BANKS 4
and if want to use it in the following code:
if (`NUM_BANKS > 1)
do something ..
else
do something else ..
Lint tool is complaining that this expression is going to always be evaluated to true.
After the `define is applied, the if will always evaulate 4 > 1. The compiler is giving an error, since the if will always be irrelevant.
I'd recommend either replacing your `define with a parameter (if you're looking to have it be changed by a higher-level module or instantiation), or use the compiler directives (http://www.csee.umbc.edu/portal/help/VHDL/verilog/compiler.html for example)
`define HASBANKS
`ifdef (HASBANKS)
...
`else
...
`endif
Lint is correct, since in your expression, 4 > 1 is always true. So if this is what you want, there is no problem.
Neo
This question already has answers here:
order of evaluation of || and && in c
(5 answers)
Closed 9 years ago.
This question is been on my mind for a while so time to let it out and see what what you guys you have to say about it.
In C/C++ the operator precedence is defined by the C specification but as with everything there may be backdoors or unknown / not well known things that the compilers may employ under the name of 'optimization' which will mess up your application in the end.
Take this simple example :
bool CheckStringPtr(const char* textData)
{
return (!textData || textData[0]==(char)0);
}
In this case I test if the pointer is null then I check the first char is zero, essentially this is a test for a zero length string. Logically the 2 operations are exchangeable but if that would happen in some cases it would crash with since it's trying to read a non-existent memory address.
So the question is : is there anything that enforces the order of how operators/functions are executed, I know the safest way is to use 2 IFs below each other but this way should be the same assuming that the evaluation order of the operators never ever change.
So are compilers forced by the C/C++ specification to not change the order of evaluation or are they sometimes allowed to change the order, like it depends on compiler parameters, optimizations especially?
First note that precedence and evaluation order are two different (largely unrelated) concepts.
So are compilers forced by the C/C++ specification to not change the order of evaluation?
The compiler must produce behaviour that is consistent with the behaviour guaranteed by the C language standard. It is free to change e.g. the order of evaluation so long as the overall observed behaviour is unchanged.
Logically the 2 operations are exchangeable but if that would happen in some cases it would crash
|| and && are defined to have short-circuit semantics; they may not be interchanged.
The C and C++ standards explicitly support short-circuit evaluation, and thus require the left-hand operand of the &&, ||, or ? operator to be evaluated before the right-hand side.
Other "sequence points" include the comma operator (not to be confused with commas separating function arguments as in f(a, b)), the end of a statement (;), and between the evaluation of a function's arguments and the call to the function.
But for the most part, order of evaluation (not to be confused with precedence) is implementation defined. So, for example, don't depend on f to be called first in an expression like f(x) + g(y).
I converted some Fortran code to C. I was wondering if someone could help me solve the following problem:
warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
I know this warning is caused by syntax like this:
A || B && C
Which should be written as:
A || (B && C)
My compiler is able to compile the code since && has a higher priority than || so it just imagines the parentheses.
The problem is that this warning occurs about 30.000 times since I'm working on a large project.
Is there any tool that is able to insert the parenthesis around all the && automatically?
As others have said do it manually, also you can disable this warning using -Wno-parentheses, even though that's pretty dangerous
Turn off stupid warnings. A || B && C does not need parentheses, any more than A + B * C does. Unless you haven't bothered to learn how logical expressions work...
A header file I'm including from /usr/include/**/asm (rudely?) uses simple C expressions to express an offset from a base value, i.e.:
#define __NR_exit (__NR_SYSCALL_BASE+ 1)
Of course, when I #include this into my .S file the resulting preprocessor-produced asm says:
start.S|17| Error: garbage following instruction -- `ldr r7,=$(0+1)'
So, crazy as it sounds, I guess I want the C-preprocessor (or the assembler) to constexpr-evaluate the macro so it can actually be used, despite the C arithmetic + operator and parens in there -- what is the right way to go about doing this?
Please note that this isn't inline asm, but an "out of line" .S file.
Aw boo, it was just because there was an erroneous dollar sign. If you change it to:
ldr r7,=__NR_exit
it seems to compile just fine. I guess as supports basic arithmetic expressions in positions where it expects constants.
I'm programming a simple calculator in Bison & Flex , using C/C++ (The logic is done in Bison , and the C/C++ part is responsible for the data structures , e.g. STL and more) .
I have the following problem :
In my calculator the dollar sign $ means i++ and ++i (both prefix and postfix) , e.g. :
int y = 3;
-> $y = 4
-> y$ = 4
When the user hits : int_expression1 && int_expression2 , if int_expression1 is evaluated to 0 (i.e. false) , then I don't wan't bison to evaluate int_expression2 !
For example :
int a = 0 ;
int x = 2 ;
and the user hits : int z = a&&x$ ...
So , the variable a is evaluated to 0 , hence , I don't want to evaluate x , however it still grows by 1 ... here is the code of the bison/c++ :
%union
{
int int_value;
double double_value;
char* string_value;
}
%type <int_value> int_expr
%type <double_value> double_expr
%type <double_value> cmp_expr
int_expr:
| int_expr '&&' int_expr { /* And operation between two integers */
if ($1 == 0)
$$ = 0;
else // calc
$$ = $1 && $3;
}
How can I tell bison to not evaluate the second expression , if the first one was already evaluated to false (i.e. 0) ?
Converting extensive commentary into an answer:
How can I tell Bison to not evaluate the second expression if the first one was already evaluated to false?
It's your code that does the evaluation, not Bison; put the 'blame' where it belongs.
You need to detect that you're dealing with an && rule before the RHS is evaluated. The chances are that you need to insert some code after the && and before the second int_expr that suspends evaluation if the first int_expr evaluates to 0. You'll also need to modify all the other evaluation code to check for and obey a 'do not evaluate' flag.
Alternatively, you have the Bison do the parsing and create a program that you execute when the parse is complete, rather than evaluating as you parse. That is a much bigger set of changes.
Are you sure regarding putting some code before the second int_expr ? I can't seem to find a plausible way to do that. It's a nice trick, but I can't find a way to actually tell Bison not to evaluate the second int_expr, without ruining the entire evaluation.
You have to write your code so that it does not evaluate when it is not supposed to evaluate. The Bison syntax is:
| int_expr '&&' {...code 1...} int_expr {...code 2...}
'Code 1' will check on $1 and arrange to stop evaluating (set a global variable or something similar). 'Code 2' will conditionally evaluate $4 (4 because 'code 1' is now $3). All evaluation code must obey the dictates of 'code 1' — it must not evaluate if 'code 1' says 'do not evaluate'. Or you can do what I suggested and aselle suggested; parse and evaluate separately.
I second aselle's suggestion about The UNIX Programming Environment. There's a whole chapter in there about developing a calculator (they call it hoc for higher-order calculator) which is worth reading. Be aware, though, that the book was published in 1984, and pre-dates the C standard by a good margin. There are no prototypes in the C code, and (by modern standards) it takes a few liberties. I do have hoc6 (the last version of hoc they describe; also versions 1-3) in modern C — contact me if you want it (see my profile).
That's the problem: I can't stop evaluating in the middle of the rule, since I cannot use return (I can, but of no use; it causes the program to exit). | intExpr '&&' { if ($1 == 0) {/* turn off a flag */ } } intExpr { /* code */} After I exit $3 the $4 is being evaluated automatically.
You can stop evaluating in the middle of a rule, but you have to code your expression evaluation code block to take the possibility into account. And when I said 'stop evaluating', I meant 'stop doing the calculations', not 'stop the parser in its tracks'. The parsing must continue; your code that calculates values must only evaluate when evaluation is required, not when no evaluation is required. This might be an (ugh!) global flag, or you may have some other mechanism.
It's probably best to convert your parser into a code generator and execute the code after you've parsed it. This sort of complication is why that is a good strategy.
#JonathanLeffler: You're indeed the king ! This should be an answer !!!
Now it is an answer.
You almost assuredly want to generate some other representation before evaluating in your calculator. A parse tree or ast are classic methods, but a simple stack machine is also popular. There are many great examples of how to do this, but my favorite is
http://www.amazon.com/Unix-Programming-Environment-Prentice-Hall-Software/dp/013937681X
That shows how to take a simple direct evaluation tool like you have made in yacc (old bison) and take it all the way to a programming language that is almost as powerful as BASIC. All in very few pages. It's a very old book but well worth the read.
You can also look at SeExpr http://www.disneyanimation.com/technology/seexpr.html
which is a simple expression language calculator for scalars and 3 vectors. If you look at https://github.com/wdas/SeExpr/blob/master/src/SeExpr/SeExprNode.cpp
on line 313 you will see the && implementation of he eval() function:
void
SeExprAndNode::eval(SeVec3d& result) const
{
// operands and result must be scalar
SeVec3d a, b;
child(0)->eval(a);
if (!a[0]) {
result[0] = 0;
} else {
child(1)->eval(b);
result[0] = (b[0] != 0.0);
}
}
That file contains all objects that represent operations in the parse tree. These objects are generated as the code is parsed (these are the actions in yacc). Hope this helps.