I'm getting these 2 errors whilst archiving the project.
Macro name is missing
Macro names must be identifiers
Any ideas what's going on?
What it says on the tin.
The first is #define, if you have this on its own, what is it defining? You need an identifier/name after the #define, such as #define VARIABLE.
The second does provide some sort of name, but it's simply a number. Identifiers cannot start with a number (just like variable names can't). and hence isn't classed as an identifier.
I got the same errors when attempting to define preprocessor macros in Build Settings as follows
Preprocessor Macros
DEBUG=1 MY_MACRO = 1
So, the parser does not like spaces, i.e. MY_MACRO=1
You are using macro without giving name. You've to use #define with name as follows and have to give value for that macro
#define macroname macrovalue second one is you can't use numbers in macro but you are giving
#define 0 1
it should be like #define ZERO 1
you are using 0 as a NAME of a macro, a digit is no valid name for any variable, functions or macro. all identifiers must start with a letter(or _) :)
Related
Context:
Hex now supports dbt's semantic layer. For example, you can use macros in the SQL cells. I have got the integration setup and verified my dbt macros work as expected when manually inputing parameters of the macro.
Problem:
How do I pass Hex input parameters into the macros? In dbt, the variables are in reference, so you don't need to bracket the inputs since the macro is bracketed. I believe the issue is that I need to quote the argument, otherwise dbt can't find the variable. There is no clear way to do this with hex. Anyone figure this out?
As an example:
my input parameters: exp_name.
I have a dbt macro: do_something(x).
When calling this in dbt like {{do_something('my_argument')}} the macro works. However, when I call it in hex with the input parameter like {{do_something(exp_name)}}, dbt compiles it as missing variables and I no result is returned.
Any help is greatly appreciated!
I tried manually quoting the variables with f-strings and setting these within the Jinja context but that did not work either.
Can I add a separator character that is ignored by the compiler to something like the following:
#define LARGE_NUMBER 10000000000
to separate the zeroes for readability?
EDIT: forgot name declaration.
The short answer is no, because a define block simply replaces the defined word with the corresponding value (you wouldn't write long myLong = 10,000,000,000). As #Oliver mentioned, I usually just put a quick comment behind the #define statement to specify the value and units.
As a side note, your #define statement isn't declaring a name for the value. You would want something like this.
#define TEN_BILLION 10000000000 // Ten billion
Then, you would use it like so.
- (void)someMethod {
NSInteger myInteger = TEN_BILLION;
...
}
I wouldn't say this is a good idea, but you can use the concatenation token ## like this:
#define TEN_MILLION 10 ## 000 ## 000
int myNumber = TEN_MILLION;
First off, your #define is missing its name. It should be something like:
#define SOME_NAME 10000000000
A #define is essentially just a "search and replace" bit of text. When you compile your code, any reference to SOME_NAME will be replaced with 10000000000. So the value you enter must be valid in the context where it is used.
If you wrote the code:
long number = 10000000000;
Would you be able to use commas or other separator character there? No, you can't. Therefore, something like:
long number = SOME_NAME;
simply becomes:
long number = 10000000000;
Any attempt to put separators in SOME_NAME would fail because those separators wouldn't be valid in the context it is used.
How can I know if my variable name is actually
the name of an intrinsic procedure ?
Here is an example of program :
program test1
implicit none
integer :: i, dim
dim = 3
do i = 1, dim
write(*, *) "dimension", i
end do
end program test1
But then I discovered that dim is in fact a function :
program test2
implicit none
write(*, *) dim(3, 1)
end program test2
This is confusing. And gfortran doesn't complain even with
the -Wall flag.
How can I prevent that from happening again ?
To avoid this in the future you can check a list of keywords in FORTRAN. Maybe familiarize yourself with some more of them. Here is a mostly complete list of them. I am not familiar with any compiler flags that would help you however.
Edit, also see first comment on this answer
As far as I know, there are no such compiler flags on any Fortran compilers, because this is within the standard. Unless things have changed, Fortran has NO RESERVED WORDS. So it is perfectly permissible to have an INTEGER variable named REAL and a DOUBLE PRECISION variable named ENDDO.
I think you can edit your ~/.vimrc file and highlight all Keywords and intrinsic procedure to differ from other variables' name
I have seen DEBUGLOG(x,...) syntax. It supports DEBUGLOG(x,...) or DEBUGLOG(x...).
If we alter dots like DEBUGLOG(x,..), it gives an error. Can anyone explain this?
Thanks in advance..........
This is a "variadic" macro, meaning it takes multiple arguments. It's the macro equivalent of a C variadic function like printf. The ... means "and any other arguments beyond here are OK too".
http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
When the macro is invoked, all the
tokens in its argument list after the
last named argument (this macro has
none), including any commas, become
the variable argument. This sequence
of tokens replaces the identifier
VA_ARGS in the macro body wherever it appears.
(I'm not certain why "x..." works without a comma. That's not a form you'd usually see.)
Just a question of interest: Does anyone know why there's no block comment capability in VB .NET? (Unless there really is - but I've never yet come across it.)
It is a side-effect of the Visual Basic syntax, a new-line terminates a statement. That makes a multi-line comment pretty incompatible with the basic way the compiler parses the language. Not an issue in the curly brace languages, new-lines are just white space.
It has never been a real problem, Visual Basic has had strong IDE support for a very long time. Commenting out multiple lines is an IDE feature, Edit + Advanced + Comment Selection.
Totally abusing compiler directives here... but:
#If False Then
Comments
go
here
#End If
You don't get the benefits of proper code coloration (it doesn't show in green when using the default color scheme) and the implicit line-continuation system automatically indents lines in a paragraph starting at the second line. But the compiler will ignore the text.
As can be read in “Comments in Code“ there isn't any other way:
If your comment requires more than one line, use the comment symbol on each line, as the following example illustrates.
' This comment is too long to fit on a single line, so we break
' it into two lines. Some comments might need three or more lines.
Similarly, the help on the REM statement states:
Note:
You cannot continue a REM statement by using a line-continuation sequence (_). Once a comment begins, the compiler does not examine the characters for special meaning. For a multiple-line comment, use another REM statement or a comment symbol (') on each line.
Depending on how many lines are to be ignored, one can use compiler directives instead. It may not be technically equivalent to comments (you don't get the syntax coloring of comments, for example), but it gets the job done without commenting many lines individually. So you just add 3 more lines of code.
#Const COMMENT = "C"
'basically a false statement
#If COMMENT = "Y" Then
'code to be commented goes between #If and #End If
MsgBox('Commenting failed!')
#End If
This is assuming the purpose is for ignoring blocks of code instead of adding documentation (what "comments" are actually used for, but I also wouldn't mind using compiler directives for that).
The effort required however, makes this method inconvenient when there are just around 10 lines to comment.
Reference: http://msdn.microsoft.com/en-us/library/tx6yas69.aspx