This question already has answers here:
Stringification of a macro value
(3 answers)
Closed 6 years ago.
If there is a macro that is a parameter to another macro, and that parameter is to be stringifyed in the macro definition, is it possible to stringify not the macro that is the parameter, but its original value? An example follows,
#define EXAMPLE "original"
#define CONCATENATE(X) "Concatenate Strings " #X
CONCATENATE(BYTE) //Results as "Concatenate Strings EXAMPLE"
//I need "Concatenate Strings original"
Is there a way for me to stringify original value of the macro that is given as the parameter?
The stringification operator suppresses macro argument expansion when producing tokens. To force it, you need to pass the argument through an intermediate macro.
For example, by making CONCATENATE a complete wrapper:
#define CONCATENATE_(X, Y) X #Y
#define CONCATENATE(X) CONCATENATE_("Concatenate Strings", X)
Related
This question already has answers here:
toList on Range with suffix notation causes type mismatch
(2 answers)
Closed 5 years ago.
I am learning postfix unary operators in Scala.
The following can not compile:
val result = 43 toString
println(result)
However if I add one empty line inbetween the two lines, the code compile and produces right output:
val result = 43 toString
println(result)
What is the difference between these two segments?
BTW, I did not add "import scala.language.postfixOps".
Perhaps the issue is clearer if we use some other operator instead of toString.
// This parses as `List(1,2,3,4) ++ List(4,5,6)`
List(1,2,3,4) ++
List(4,5,6)
Basically, in order to make the above work, while also allowing things like foo ? (a postfix operator), Scala needs to know when it is OK to stop expecting a second argument (and accept that the expression is a postfix operator).
Its solution is give up on finding a second argument if there is an interceding new line.
This question already has answers here:
Why is parenthesis optional only after sub declaration?
(4 answers)
Closed 7 years ago.
I built a simple subroutine, and I have a question about whether calling it requires parentheses.
#!/usr/bin/perl
sub echo {
print "#_ \n" ;
}
echo(#ARGV);
When I use
echo #ARGV
or
echo (#ARGV)
or (without a space)
echo(#ARGV)
they all work. Which one is correct?
echo #ARGV, echo (#ARGV), and echo(#ARGV) are technically all correct in your case, but using parentheses is sometimes necessary; beyond that, it's a matter of choice, and some people employ conventions around when to use what style.
Enclosing the entire argument list in parentheses ALWAYS works - whether spaces precede the opening parenthesis or not - echo (#ARGV) or echo(#ARGV) - and whether you're calling a built-in or user-defined function (subroutine):
As #xxfelixxx notes in a comment on the question, perldoc perlstyle recommends no spaces between the function name and ( - echo(#ARGV).
Enclosing the entire argument list in parentheses can be used to disambiguate:
print (1 + 2) + 4 prints only 3, because (1 + 2) is interpreted as the entire argument list (with + 4 added to the the expression value of the print call, the result of which is not output).
print((1 + 2) + 4) resolves the ambiguity and prints 7.
Alternatively, prefix the parenthesized first argument with + to achieve the same effect: print +(1 + 2) + 4 also prints 7.
Not using parentheses - echo #ARGV - works:
with built-in functions: always
with user-defined functions: ONLY if they are predeclared, which can be ensured in one of the following ways:
The function is defined in the same script before its invocation.
The function is forward-declared with sub <name>; before its invocation.
The function is imported from a module with use before its invocation (require is not enough).
This predeclaration requirement is is an unfortunate side effect of backward compatibility with the earliest Perl versions - see this answer.
In the absence of a predeclaration, the safest approach is to use parentheses (while &echo #ARGV works in principle, it bypasses any prototypes (a form of parameter typing) that the function may declare).
As for conventions:
Since using parentheses always works (even when not strictly needed) with user-defined functions, whereas they are never needed for built-in functions, some people recommend always using parentheses with user-defined functions, and never with built-in functions.
In source code that adheres to this convention, looking at any function call then tells you whether a built-on or user-defined function is being invoked.
The parens are optional. You need them in some situations to explicitly show which values are the arguments to the function, for example, when passing the result of a function call to another function:
myfunc(1, 2, otherfunc(3), "z");
Without parens around the 3, otherfunc will receive both 3 and "z" as arguments.
As xxfelixxx mentioned, it's best to use them all the time.
1. #define NUM 10
2. #define FOO NUM
3. #undef NUM
4. #define NUM 20
5.
6. FOO
When I only run the preprocessor, the output file contains 20.
However, from what I understand, the preprocessor simply does text replacement. So this is what I think is happening (which is obviously wrong but idky):
NUM is defined as 10.
Therefore, in line 2, NUM is replaced as 10. So now we have "#define FOO 10".
NUM is undefined.
NUM is redefined and now is 20.
FOO is replaced according to line 2, which was before line 4's redefinition, and is 10.
So I think the output should be 10 instead of 20. Can anything explain where it went wrong?
The text replacement is done where the macro is used, not where you wrote the #define. At the point you use FOO, it replaces FOO with NUM and NUM is currently defined to be 20.
In the interests of collecting all the relevant specifications from the standards, I extracted this information from a comment thread, and added C++ section numbers, based on draft N4527 (the normative text is identical in the two standards). The standard(s) are absolutely clear on the subject.
#define preprocessor directives do not undergo macro replacement.
(C11 §6.10¶7; C++ §16[cpp] ¶6): The preprocessing tokens within a preprocessing directive are not subject to macro expansion unless otherwise stated.
After a macro is replaced with its replacement text, the new text is rescanned. Preprocessor tokens in the replacement are expanded as macros if there is an active macro definition for the token at that point in the program.
(C11 §6.10.3¶9; C++ §16.3[cpp.replace] ¶9) A preprocessing directive of the form
# define identifier replacement-list new-line
defines an object-like macro that causes each subsequent instance of the macro name to be replaced by the replacement list of preprocessing tokens that constitute the remainder of the directive. The replacement list is then rescanned for more macro names as specified below.
A macro definition is active from the line following the #define until an #undef for the macro name, or the end of the file.
(C11 §6.10.3.5¶1; C++ §16.3.5[cpp.scope] ¶1) A macro definition lasts (independent of block structure) until a corresponding #undef directive is encountered or (if none is encountered) until the end of the preprocessing translation unit. Macro definitions have no significance after translation phase 4.
If we look at the program:
#define NUM 10
#define FOO NUM
#undef NUM
#define NUM 20
FOO
we see that the macro definition of NUM in line 1 lasts exactly to line 3. There is no replaceable text in those lines, so the definition is never used; consequently, the program is effectively the same as:
#define FOO NUM
#define NUM 20
FOO
In this program, at the third line, there is an active definition for FOO, with replacement list NUM, and for NUM, with replacement list 20. The FOO is replaced with its replacement list, making it NUM, and then that is once again scanned for macros, resulting in NUM being replaced with its replacement list 20. That replacement is again rescanned, but there are no defined macros, so the end result is that the token 20 is left for processing in translation phase 5.
In:
FOO
the preprocessor will replace it with NUM, then it will replace NUM with what it is currently defined as, which is 20.
Those initial four lines are equivalent to:
#define FOO NUM
#define NUM 20
The C11 standard says (and other versions of C, and C++, say similarly):
A preprocessing directive of the form # define identifier replacement-list new-line defines an object-like macro that causes each subsequent instance of the macro name to be replaced by the replacement list of preprocessing tokens that constitute the remainder of the directive. The replacement list is then rescanned for more macro names as specified below.
However it also says in another part (thanks to rici for pointing this out).
The preprocessing tokens within a preprocessing directive are not subject to macro expansion unless otherwise stated.
So a subsequent instance of the macro name which is found inside another #define directive is actually not replaced.
Your line #define FOO NUM defines that when the token FOO is later found (outside of another #define directive!), it will be replaced by the token NUM .
After a token is replaced, rescanning occurs, and if NUM is itself a macro, then NUM is replaced at that point. (And if whatever NUM expands to contains macros , then that gets expanded , and so on).
So your sequence of steps is actually:
NUM defined as 10
FOO defined as NUM
NUM undefined and re-defined as 20
FOO expands to NUM
(rescan) NUM expands to 20
This behaviour can be seen in another common preprocessor trick, to turn the defined value of a macro into a string:
#define STR(X) #X
#define STR_MACRO(X) STR(X)
#define NUM 10
puts( STR_MACRO(NUM) ); // output: 10
If we had written puts( STR(NUM) ) then the output would be NUM.
The output of 10 is possible because, as before, the second #define here does not actually expand out STR. So the sequence of steps in this code is:
STR(X) defined as #X
STR_MACRO(X) defined as STR(X)
NUM defined as 10
STR_MACRO and NUM are both expanded; the result is puts( STR(10) );
(Rescan result of last expansion) STR(10) is expanded to "10"
(Rescan result of last expansion) No further expansion possible.
This question already has an answer here:
Test if array is inside a list in lisp
(1 answer)
Closed 7 years ago.
I have a problem with removing strings from a list of string I use this
(remove "lol" '("lol" "lol2" "lol")
but it returns the same list. What's the problem here?
You're running into the problem of trying to determine equality. I believe remove uses eql as its default equality tester. Unfortunately, two strings are not eql unless they're actually the same object.
Try:
`(remove "lol" '("lol" "lol2" "lol") :test #'equal)
Alternatively, if you know you will be testing strings, you could pass string= as your test function.
You should close the ')'
So write : (remove "lol" '("lol" "lol2" "lol"))
This question already has answers here:
Meaning of // operator in perl
(5 answers)
Closed 9 years ago.
I was searching in a lot of Perl books but I can't find an answer. I have this code, what I suppose it does is assign param's ticket to $ticket iff it exists if not, assign 0.
my $ticket = $params->{ticket} // 0;
// means defined-or. $ticket is assigned $params->{ticket} if it is defined, 0 otherwise.
Although it has no direct equivalent in C, Perl's // operator is related to its C-style or. In fact, it's exactly the same as ||, except that it tests the left hand side's definedness instead of its truth. Thus, EXPR1 // EXPR2 returns the value of EXPR1 if it's defined, otherwise, the value of EXPR2 is returned.
It was added in 5.10.
In the code above, $params->{ticket} can still have garbage in it, so make sure the value conforms to the expected pattern before using it.
Perl documentation says:
"EXPR1 // EXPR2 returns the value of EXPR1 if it's defined, otherwise, the value of EXPR2 is returned."
It's similar to a logic or, but testing definedness.