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.)
Related
In julia you can write subscripts by \_ for variable names. I was wondering if there is anything similar for writing fractions in variable names. Something like \frac{}{} in LaTeX. I understand this may be harder as it takes two arguments. If there is none, I will use /. But in this case I would like to use some enclosures to make clear what is being differentiated. I assume () is not usable? [] or {} would be ok?
The subscripts or other non-latin names you see in Julia code are just normal unicodes the same as "regular" names. the LaTeX commands are only a function of Julia REPL to remember and input them.
As for unicode, in principle you can represent some simple fractions like ⁽²⁺ⁱ⁾⁄₍ₛ₊ₜ₎, using the ⁄ (U+2044 Fraction slash) symbol and subscripts and superscripts. The rendering depends on your font, but do not expect a verticle layout in any current fonts.
However, Julia recognizes ⁄ (U+2044 Fraction slash, not the / in your keyboard) as "invalid character" when used along during parsing. The same applies to \not, which can only be used in conjunction with some operators, so it's not an option too.
As for the brackets and the normal /, they are operators and are parsed differently. However, there is an (ugly) way to circumvent this: you can use macros to bypass the parsing and use strings as variable names. For example:
julia> macro n_str(name)
esc(Symbol(name))
end
#n_str (macro with 1 method)
julia> n"∂(2x + 3)/∂x" = 2
2
julia> 2n"∂(2x + 3)/∂x"
4
I'm trying to write a simple multi-line Alias that says several predefined strings of characters in mIRC. The problem is that the strings can contain:
{
}
|
which are all used in the scripting language to group sections of code/commands. So I was wondering if there was an escape character I could use.
In lack of that, is there a method, or alternative way to be able to "say" multiple lines of these strings, so that this:
alias test1 {
/msg # samplestring}contains_chars|
/msg # _that|break_continuity}{
}
Outputs this on typing /test1 on a channel:
<MyName> samplestring}contains_chars|
<MyName> _that|break_continuity}{
It doesn't have to use the /msg command specifically, either, as long as the output is the same.
So basically:
Is there an escape character of sorts I can use to differentiate code from a string in mIRC scripting?
Is there a way to tell a script to evaluate all characters in a string as a literal? Think " " quotes in languages like Java.
Is the above even possible using only mIRC scripting?
"In lack of that, is there a method, or alternative way to be able to "say" multiple lines of these strings, so that this:..."
I think you have to have to use msg # every time when you want to message a channel. Alterativelty you can use the /say command to message the active window.
Regarding the other 3 questions:
Yes, for example you can use $chr(123) instead of a {, $chr(125) instead of a } and $chr(124) instead of a | (pipe). For a full list of numbers you can go to http://www.atwebresults.com/ascii-codes.php?type=2. The code for a dot is 46 so $chr(46) will represent a dot.
I don't think there is any 'simple' way to do this. To print identifiers as plain text you have to add a ! after the $. For example '$!time' will return the plain text '$time' as $time will return the actual value of $time.
Yes.
Is there any differences in invoking variables with syntax ${var} and $(var)? For instance, in the way the variable will be expanded or anything?
There's no difference – they mean exactly the same (in GNU Make and in POSIX make).
I think that $(round brackets) look tidier, but that's just personal preference.
(Other answers point to the relevant sections of the GNU Make documentation, and note that you shouldn't mix the syntaxes within a single expression)
The Basics of Variable References section from the GNU make documentation state no differences:
To substitute a variable's value, write a dollar sign followed by the
name of the variable in parentheses or braces: either $(foo) or
${foo} is a valid reference to the variable foo.
As already correctly pointed out, there is no difference but be be wary not to mix the two kind of delimiters as it can lead to cryptic errors like in the GNU make example by unomadh.
From the GNU make manual on the Function Call Syntax (emphasis mine):
[…] If the arguments themselves contain other function calls or variable references, it is wisest to use the same kind of delimiters for all the references; write $(subst a,b,$(x)), not $(subst a,b,${x}). This is because it is clearer, and because only one type of delimiter is matched to find the end of the reference.
The ${} style lets you test the make rules in the shell, if you have the corresponding environment variables set, since that is compatible with bash.
Actually, it seems to be fairly different:
, = ,
list = a,b,c
$(info $(subst $(,),-,$(list))_EOL)
$(info $(subst ${,},-,$(list))_EOL)
outputs
a-b-c_EOL
md/init-profile.md:4: *** unterminated variable reference. Stop.
But so far I only found this difference when the variable name into ${...} contains itself a comma. I first thought ${...} was expanding the comma not as part as the value, but it turns out i'm not able to hack it this way. I still don't understand this... If anyone had an explanation, I'd be happy to know !
It makes a difference if the expression contains unbalanced brackets:
${info ${subst ),(,:-)}}
$(info $(subst ),(,:-)))
->
:-(
*** insufficient number of arguments (1) to function 'subst'. Stop.
For variable references, this makes a difference for functions, or for variable names that contain brackets (bad idea)
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 _) :)
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