# include <stdio.h>
# define ONE 1
# define TWO 2
# define ONE TWO
# define TWO ONE
int main ( void )
{
printf("ONE = %d, TWO = %d\n", ONE, TWO );
return 0;
}
what actually happens when we write this way? In the 4th line #define ONE TWO, does the pre processor replace it blindly as 1 2 immediately?
If you are using xcode 3 you could do a right click on the file and select PreProcess
You will get a huge file with this code near the end
int main ( void )
{
printf("ONE = %d, TWO = %d\n", ONE, TWO );
return 0;
}
Edit: I see it's useless in this case. For some reason the preprocess happens without error and warnings, but the code doesn't change. But if you write useful code you can look at the preprocessed code.
and if you try to compile it you get a bunch of warnings and errors.
test.c:4:1: warning: "ONE" redefined
test.c:2:1: warning: this is the location of the previous definition
test.c:5:1: warning: "TWO" redefined
test.c:3:1: warning: this is the location of the previous definition
test.c: In function ‘main’:
test.c:8: error: ‘ONE’ undeclared (first use in this function)
test.c:8: error: (Each undeclared identifier is reported only once
test.c:8: error: for each function it appears in.)
test.c:8: error: ‘TWO’ undeclared (first use in this function)
conflict of which macro will be called will be arised.....as ONE is 1 and ONE is TWO.... that is linking error.
In the 4th line #define ONE TWO, does the pre processor replace it blindly as 1 2 immediately?
No. The relevant form of the define directive in this case is:
#define identifier replacement-list new-line
... and there is no replacement happening on identifier. Also, the following applies:
An identifier currently defined as an object-like macro shall not be redefined by another #define preprocessing directive unless the second definition is an object-like macro definition and the two replacement lists are identical.
... which makes your redefinition illegal.
If you need to redefine a macro, you have to undefine it first using #undef.
Related
I am trying to write a basic cmake to check whether certain types exist or not.
I am having issues with calling check_type_size multiple times. If I used the same variable (the one that holds the size) multiple times, only the first time I call check_type_size it gets populated.
cmake_minimum_required(VERSION 3.8)
project(TEST LANGUAGES C;CXX)
INCLUDE (CheckTypeSize)
check_type_size("int" VAR_SIZE1)
message(${VAR_SIZE1})
check_type_size("void *" VAR_SIZE1)
message(${VAR_SIZE1})
message("VAR_SIZE1 was not updated after the second call.\n")
check_type_size("int" VAR_SIZE2)
message(${VAR_SIZE2})
check_type_size("void *" VAR_SIZE3)
message(${VAR_SIZE3})
message("We get the correct size if use different variable every time.")
add_executable(TEST "${TEST_SOURCE_DIR}/main.cpp")
This is what I get:
Check size of int
Check size of int - done
4
4
VAR_SIZE1 was not updated after the second call.
Check size of int
Check size of int - done
4
Check size of void *
Check size of void * - done
8
We get the correct size if use different variable every time.
Does any body know what is going on?
Variable created with check_type_size() call is actually a CACHE variable (this is described in the documentation for the macro. Once variable is set, its is not updated. [This is used for omit successful checks next time you run cmake.]
Different checks should use different variables.
I suspect this may be a bug in Rakudo, but I just started playing with Perl 6 today, so there's a good chance I'm just making a mistake. In this simple program, declaring a typed array inside a sub appears to make the Perl 6 compiler angry. Removing the type annotation on the array gets rid of the compiler error.
Here's a simple prime number finding program:
#!/usr/bin/env perl6
use v6;
sub primes(int $max) {
my int #vals = ^$max; # forcing a type on vals causes compiler error (bug?)
for 2..floor(sqrt($max)) -> $i {
next if not #vals[$i];
#vals[2*$i, 3*$i ... $max-1] = 0;
}
return ($_ if .Bool for #vals)[1..*];
}
say primes(1000);
On Rakudo Star 2016.07.1 (from the Fedora 24 repos), this program gives the following error:
[sultan#localhost p6test]$ perl6 primes.p6
Cannot unbox a type object
in sub primes at primes.p6 line 8
in block <unit> at primes.p6 line 13
If I remove the type annotation on the vals array, the program works correctly:
...
my #vals = ^$max; # I removed the int type
...
Am I making a mistake in my usage of Perl 6, or is this a bug in Rakudo?
There's a potential error in your code that's caught by type checking
The error message you got draws attention to line 8:
#vals[2*$i, 3*$i ... $max-1] = 0;
This line assigns the list of values on the right of the = to the list of elements on the left.
The first element in the list on the left, #vals[2*$i], gets a zero.
You didn't define any more values on the right so the rest of the elements on the left are assigned a Mu. Mus work nicely as placeholders for elements that do not have a specific type and do not have a specific value. Think of a Mu as being, among other things, like a Null, except that it's type safe.
You get the same scenario with this golfed version:
my #vals;
#vals[0,1] = 0; # assigns 0 to #vals[0], Mu to #vals[1]
As you've seen, everything works fine when you do not specify an explicit type constraint for the elements of the #vals array.
This is because the default type constraint for array elements is Mu. So assigning a Mu to an element is fine.
If you felt it tightened up your code you could explicitly assign zeroes:
#vals[2*$i, 3*$i ... $max-1] = 0 xx Inf;
This generates a (lazy) infinite list of zeroes on the RHS so that zero is assigned to each of the list of elements on the LHS.
With just this change your code will work even if you specify a type constraint for #vals.
If you don't introduce the xx Inf but do specify an element type constraint for #vals that isn't Mu, then your code will fail a type check if you attempt to assign a Mu to an element of #vals.
The type check failure will come in one of two flavors depending on whether you're using object types or native types.
If you specify an object type constraint (eg Int):
my Int #vals;
#vals[0,1] = 0;
then you get an error something like this:
Type check failed in assignment to #vals; expected Int but got Mu (Mu)
If you specify a native type constraint (eg int rather than Int):
my int #vals;
#vals[0,1] = 0;
then the compiler first tries to produce a suitable native value from the object value (this is called "unboxing") before attempting a type check. But there is no suitable native value corresponding to the object value (Mu). So the compiler complains that it can not even unbox the value. Finally, as hinted at at the start, while Mu works great as a type safe Null, that's just one facet of Mu. Another is that it's a "type object". So the error message is Cannot unbox a type object.
I am new to iOS development and I just want to know the meaning of macro in Objective-C?
I have found that "macro" is used with #define but still do not get its meaning.
http://www.saturngod.net/ios-macro-define-value-with-condition
Yes, Larme is right. Macros can be used in many languages, it's not a specialty of objective-c language.
Macros are preprocessor definitions. What this means is that before your code is compiled, the preprocessor scans your code and, amongst other things, substitutes the definition of your macro wherever it sees the name of your macro. It doesn’t do anything more clever than that.
Almost literal code substitution. e.g.-
Suppose you want a method to return the maximum of two numbers. You write a macro to do this simple task:
#define MAX(x, y) x > y ? x : y
Simple, right? You then use the macro in your code like this:
int a = 1, b = 2;
int result = 3 + MAX(a, b);
EDIT:
The problem is that the preprocessor substitutes the macro definition into the code before compilation, so this is the code the compiler sees:
int a = 1, b = 2;
int result = 3 + a > b ? a : b;
C order of operations requires the sum 3 + a be calculated before the ternary operator is applied. You intended to save the value of 3 + 2 in result, but instead you add 3 + 1 first, and test if the sum is greater than 2, which it is. Thus result equals 2, rather than the 5 you expected.
So you fix the problem by adding some parentheses and try again:
#define MAX(x, y) ((x) > (y) ? (x) : (y))
A macro is a fragment of code which has been given a name. Whenever the name is used, it is replaced by the contents of the macro. There are two kinds of macros. They differ mostly in what they look like when they are used. Object-like macros resemble data objects when used, function-like macros resemble function calls.
An object-like macro is a simple identifier which will be replaced by a code fragment. It is called object-like because it looks like a data object in code that uses it. They are most commonly used to give symbolic names to numeric constants.
You create macros with the ‘#define’ directive. ‘#define’ is followed by the name of the macro and then the token sequence it should be an abbreviation for, which is variously referred to as the macro's body, expansion or replacement list. For example,
#define BUFFER_SIZE 1024
defines a macro named BUFFER_SIZE as an abbreviation for the token 1024. If somewhere after this ‘#define’ directive there comes a Objective C statement of the form
foo = (char *) malloc (BUFFER_SIZE);
The Objective C compiler will see the same tokens as it would if you had written
foo = (char *) malloc (1024);
You can also define macros whose use looks like a function call. These are called function-like macros. To define a function-like macro, you use the same ‘#define’ directive, but you put a pair of parentheses immediately after the macro name.
Like:
#define isIphone([[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPhone)
#define GetImage(imageName) [UIImage imageWithContentsOfFile:[[NSBundle mainBundle] pathForResource:imageName ofType:#"png"]]
Macros are compile time constants. That means they will replaced with actual values in the compile time.
#define MIN_VALUE 3 // Definition
if(x > MIN_VALUE) // Usage
{
}
While compiling it actually looks like
if(x > 3) // During compilation
{
}
Wikipedia has the answer, under Macro.
Definition:
The term originated with macro-assemblers, where the idea is to make available to the programmer a sequence of computing instructions as a single program statement, making the programming task less tedious and less error-prone.
Usage:
Keyboard and mouse macros that are created using an application's built-in macro features are sometimes called application macros. They are created by carrying out the sequence once and letting the application record the actions. An underlying macro programming language, most commonly a Scripting language, with direct access to the features of the application may also exist.
The idea is to setup several fixed CGPoint values with macros, and read them in code flexibly (randomly or with provided integer value)
I have a header file defining several CGPoints value like this:
#define kSpawnPoint1 {550,20}
#define kSpawnPoint2 {550,80}
#define kSpawnPoint3 {200,175}
I'm generating a random integer in my code between 1 to 3, and plan to read the CGPoint value in the macro according to the integer value. But don't know how to do it. After learning other tutorials about preprocessors, I write my code like following.
#define kSpawnPoint1 {550,20}
#define kSpawnPoint2 {550,80}
#define kSpawnPoint3 {200,175}
#define kSpawnPoint(x) kSpawnPoint##x
in the m file:
int tempInt = 1;
CGPoint tempSpawnPoint = kSpawnPoint(temInt);
However it doesn't work.(with warning: undeclared identifier 'kSpawnPointspawnPoint') How can I make this right? And is it the right way to pre-define several CGPoint? I think I must use the preprocessor to achieve this considering future multi-screen resolution support would be easier to implement in macro too, and my kSpawnPoints would not be the same with different screen resolution.
Macros only operate on text, not the values of variables. When you write kSpawnPoint(an_int), the preprocessor takes the literal string "an_int" and then pastes it, so you end up with kSpawnPointan_int. Thus, you would have to put a literal number as the argument in order to end up with one of your points: kSpawnPoint(1) -> kSpawnPoint1 -> {550, 20}
To choose randomly among your macros, you will have to put them into a structure that will exist at runtime, like an array or a switch statement.
I am using Xilinx ISE 10.1 to run some verilog code. In the code I want to write the register values of 3 registers in a file, cipher.txt. The following is the code snippet:
if (clk_count==528) begin
f1 = $fopen("cipher.txt", "w");
$fwrite(f1, "clk: %d", clk_count[11:0]);
$fwrite(f1, "plain: %h", plain[31:0]);
$fwrite(f1, "cipher: %h", cipher[31:0]);
$fclose(f1);
end
At the end of execution, the contents of cipher.txt is found as:
clk: %dplain: %hcipher: %h
There is no other error encountered, but a warning comes up corresponding to the 3 fwrite's:
Parameter 3 is not constant in call of system task $fwrite.
Parameter 3 is not constant in call of system task $fwrite.
Parameter 3 is not constant in call of system task $fwrite.
The values of the registers clk_count and cipher change on every clock cycle (value of register plain remains constant throughout), and the values are written to cipher.txt when clk_count equals 528 (indicated by the if statement)
Can anybody provide some insight and/or help me get past this hurdle?
Thanks.
It appears that ISE expects the arguments to $fwrite to be constant. The warnings are referring to clk_count[11:0], plain[31:0], and cipher[31:0], which are not constant. By definition they are changing each cycle so they are not known at compile time. This also explains why they are not printing and you are seeing %d and %h in the output.
There is nothing to my knowledge in the Verilog spec that requires the arguments to $fwrite be constant. The same code works as expected with Cadence Incisive. My guess is that it's a limitation of ISE, so you may want to check with Xilinx.
Possible work-arounds:
1) Use $swrite to create a string with the proper formatting. Then write the string to the file.
2) Try using an intermediate variable in the calls to $fwrite. Maybe the part-selects are throwing it off. e.g.
integer foo;
foo = clk_count[11:0];
$fwrite(... , foo , ...);
Either of those might work, or not.
Out of curiosity, if you remove the part-selects, and try to print clk_count without the [11:0] , do you get the same warnings?