"Expected unqualified-id" in #define statement - objective-c

I'm trying to simplify my code by using #define statements. This is because it contains a lot of repetitive "chunks" of code that cannot be repeated using the obvious alternative, functions, because in these chunks, variables need to be declared like you'd do in a #define statement, e.g. #define dostuff(name) int name##Variable;.
Code
#define createBody(name,type,xpos,ypos,userData,width,height) b2BodyDef name##BodyDef;\
name##BodyDef.type = type==#"dynamic"?b2_dynamicBody:b2_staticBody;\
name##BodyDef.position.Set(xpos,ypos);\
name##BodyDef.userData = userData;\
name=world->CreateBody(&name##BodyDef);\
b2PolygonShape name##shape;\
name##shape.SetAsBox(width/ptm_ratio/2,height/ptm_ratio/2);
... and applying that in the following:
createBody(block, #"dynamic", winSize.width*5/6/ptm_ratio, winSize.height*1/6/ptm_ratio, ((__bridge void*)blockspr), blockspr.contentSize.width, blockspr.contentSize.height)
// error appears there: ^
Now my point is that everything's working great, no errors, except a single one that's freaking me out:
Expected unqualified-id
which points at the first bracket in ((__bridge ..., as indicated. (That argument gets passed via the userData argument to createBody.)
I know this code is nowhere near simple, but since everything else is working, I believe that an answer must exist.
This is my first question on SO, so if there's anything unclear or insufficient, please let me know!

I'm trying to simplify my code by using #define statements.
This sounds an alarm in my mind.
Break this down into functions. You said you can't. I say you can.
Notice that your macro here:
createBody(name,type,xpos,ypos,userData,width,height);
It has exactly the same syntax as a C function. So you've already created a function, you only declared it as a macro. There's no reason why you couldn't rewrite it as a function (C or Objective-C doesn't matter). You do not need to give each body its own name, instead you could store them in a dictionary (careful though because Box2D takes ownership of the bodies).

Related

#NLConstraint with vectorized constraint JuMP/Julia

I am trying to solve a problem involving the equating of sums of exponentials.
This is how I would do it hardcoded:
#NLconstraint(m, exp(x[25])==exp(x[14])+exp(x[18]))
This works fine with the rest of the code. However, when I try to do it for an arbitrary set of equations like the above I get an error. Here's my code:
#NLconstraint(m,[k=1:length(LHSSum)],sum(exp.(LHSSum[k][i]) for i=1:length(LHSSum[k]))==sum(exp.(RHSSum[k][i]) for i=1:length(RHSSum[k])))
where LHSSum and RHSSum are arrays containing arrays of the elements that need to be exponentiated and then summed over. That is LHSSum[1]=[x[1],x[2],x[3],...,x[n]]. Where x[i] are variables of type JuMP.Variable. Note that length(LHSSum)=length(RHSSum).
The error returned is:
LoadError: exp is not defined for type Variable. Are you trying to build a nonlinear problem? Make sure you use #NLconstraint/#NLobjective.
So a simple solution would be to simply do all the exponentiating and summing outside of the #NLconstraint function, so the input would be a scalar. However, this too presents a problem since exp(x) is not defined since x is of type JuMP.variable, whereas exp expects something of type real. This is strange since I am able to calculate exponentials just fine when the function is called within an #NLconstraint(). I.e. when I code this line#NLconstraint(m,exp(x)==exp(z)+exp(y)) instead of the earlier line, no errors are thrown.
Another thing I thought to do would be a Taylor Series expansion, but this too presents a problem since it goes into #NLconstraint land for powers greater than 2, and then I get stuck with the same vectorization problem.
So I feel stuck, I feel like if JuMP would allow for the vectorized evaluation of #NLconstraint like it does for #constraint, this would not even be an issue. Another fix would be if JuMP implements it's own exp function to allow for the exponentiation of JuMP.Variable type. However, as it is I don't see a way to solve this problem in general using the JuMP framework. Do any of you have any solutions to this problem? Any clever workarounds that I am missing?
I'm confused why i isn't used in the expressions you wrote. Do you mean:
#NLconstraint(m, [k = 1:length(LHSSum)],
sum(exp(LHSSum[k][i]) for i in 1:length(LHSSum[k]))
==
sum(exp(RHSSum[k][i]) for i in 1:length(RHSSum[k])))

Declare a variable

I didn't touch Prolog since high-school, and even though I've tried to find the info, it didn't help. Below is the example that has to illustrate my problem:
%% everybody():- [dana, cody, bess, abby].
%% Everybody = [dana, cody, bess, abby].
likes(dana, cody).
hates(bess, dana).
hates(cody, abby).
hates(X, Y):- \+ likes(X, Y).
likes_somebody(_, []):- fail.
likes_somebody(X, [girl | others]):-
likes(X, girl) ; likes_somebody(X, others).
likes_everybody(_, []):- true.
likes_everybody(X, [girl | others]):-
likes(X, girl) , likes_everybody(X, others).
maplist(likes_somebody, [dana, cody, bess, abby], [dana, cody, bess, abby]).
How do I declare everybody to just be the list of girls? The commented lines are those which I've tried, but I've got bizarre error messages back.
This is the tutorial I followed more or less so far. I'm using GProlog, if it makes any difference. Sorry for such a basic question. GProlog's manual doesn't deal with language syntax, but I've certainly looked there. As an aside, I would be grateful for information on where to look for language documentation (as opposed to implementation documentation).
Every variable in Prolog must begin with an uppercase letter. So for starters, you want Everybody, not everybody.
Second problem, variables in Prolog are not assignables. So probably what you want to do is make a fact and use that instead:
everybody([dana, cody, bess, abby]).
Your bottom line of code is actually a fact definition and will attempt to overwrite maplist/3. What you probably want to do is put everything above that line into a file (say, called likes.pl) and then consult it ([likes].). Then you can run a query like this:
?- everybody(Everybody), maplist(likes_somebody, Everybody, Everybody).
This won't work, because likes_somebody/2 processes a list in the second argument. The predicate you have for likes_somebody/2 could be written:
likes_somebody(_, []).
but still won't mean much. It simply unifies anything with the empty list:
?- likes_somebody(chicken_tacos, []).
true.
You really need a predicate to tell you if someone is a girl, like this:
girl(dana).
girl(cody).
girl(bess).
girl(abby).
Then you could do what I think you're trying to do, which is something closer to this:
likes_somebody(X) :- girl(X).
Then the maplist construction would work like this:
everybody(Everybody), maplist(likes_somebody, Everybody).
Which would simply return true. You could simplify and eliminate everybody/1 by instead using findall(Girl, girl(X), Everybody) but it's getting weird.
You're trying to do list processing with likes_everybody/2, but it's broken because girl is literally girl, not a variable, and others is literally others, not a list of some kind that could be the tail of another list.
I think you still have some old ideas you need to cleanse. Read some more, write some more, and your code will start to make a lot more sense.

Is it possible to parse a mathematical expression by using #define?

I want to make a scientific calculator in which the user enters something like 3+4*(3-5)/23 and then the calculator can return the value.
Now I'm trying to find a way to parse a string of mathematical expression. I know that there are some built parsers and algorithms but I want to know whether it's possible by using #define method.
Basically, I want to use the #define to literally remove the # and " " in a string and make it look like an expression that can be evaluated. At this stage, I won't use unknown variables like x or 3*k or a*b/c. All will be numbers and operators like 3+4 and 32 that can be directly evaluated by the compiler. Here is what I want to write in #define:
#define eval#"(x)" x
In the above code, eval is just a signal of parsing and the #"x" is the actual string that need to parse and x is a mathematical expression. After the translation, only x will remain. For example, if I write
double result = eval#"(3+4)";
the compiler will read
double result = 3+4;
(according to my understanding of #define). However, the code does not work. I suspect that the quotation marks confuse the compiler and cause the code to break. So my question is: can anyone come up with a solution using #define?
This is not possible with the preprocessor, no string manipulation besides concatenation supported.
Why would you need the #"x" syntax anyways? You can just put the expression right there in the code.
People are right, you cannot do it in direct way, however if you very want macro:
#define eval(x) [[[NSExpression expressionWithFormat:x] expressionValueWithObject:nil context:nil] doubleValue]
double result = eval(#"3+4");
#define is an invocation of the C preprocessor, which is not capable of this kind of manipulation. It almost sounds like you're trying to define an Objective-C macro that would do the same kind of thing as a LISP macro, but that's not possible. Why don't you tell us what the original problem is that you're trying to solve... I think we can probably come up with an easier way to do what you're trying to do.

calling script_execute with a variable

I'm using GameMaker:Studio Pro and trying to execute a script stored in a variable as below:
script = close_dialog;
script_execute(script);
It doesn't work. It's obviously looking for a script named "script". Anyone know how I can accomplish this?
This question's quite old now, but in case anyone else ends up here via google (as I did), here's something I found that worked quite well and avoids the need for any extra data structures as reference:
scriptToCall = asset_get_index(scr_scriptName);
script_execute(scriptToCall);
The first line here creates the variable scriptToCall and then assigns to it Game Maker's internal ID number for the script you want to call. This allows script_execute to correctly find the script from the ID, which doesn't work if you try to pass it a string containing the script name.
I'm using this to define which scripts should be called in a particular situation from an included txt file, hence the need to convert a string into an addressable script ID!
You seem to have some confusion over how Game Maker works, so I will try to address this before I get around to the actual question.
GML is a rather simple-minded beast, it only knows two data types: strings and numbers. Everything else (objects, sprites, scripts, data structures, instances and so on) is represented with a number in your GML code.
For example, you might have an object called "Player" which has all kinds of fancy events, but to the code Player is just a constant number which you can (e.g.) print out with show_message(string(Player));
Now, the function script_execute(script) takes as argument the ID of the script that should be executed. That ID is just a normal number. script_execute will find the script with that ID in some internal table and then run the script.
In other words, instead of calling script_execute(close_dialog) you could just as well call script_execute(14) if you happened to know that the ID of close_dialog is 14 (although that is bad practice, since it make the code difficult to understand and brittle against ID changes).
Now it should be obvious that assigning the numeric value of close_dialog to a variable first and then calling script_execute on that variable is perfectly OK. In the end, script_execute only cares about the number that is passed, not about the name of the variable that this number comes from.
If you are thinking ahead a bit, you might wonder whether you need script_execute at all then, or if you could instead just do this:
script = close_dialog;
script();
In my opinion, it would be perfectly fine to allow this in the language, but it does not work - the function call operator actually does care about the name of the thing you try to call.
Now with that background out of the way, on to your actual question. If close_dialog is actually a script, your suggested code will work fine. If it is an extension function (or a built-in function -- I don't own Studio so what do I know) then it does not actually have an ID, and you can't call it with script_execute. In fact, you can't even assign close_dialog to a variable then because it does not have any value in GML -- all you can do with it then is call it. To work around this though, you could create a script (say, close_dialog_script which only calls close_dialog, which you can then use just as above.
Edit: Since it does not seem to work anyway, check whether you have a different resource by the name of close_dialog (perhaps a button sprite). This kind of conflict could mean that close_dialog gives you the ID of the sprite, not of the script, while calling the script directly would still work.
After much discussion on the forums, I ended up going with this method.
I wrote a script called script_id()
var sid;
sid = 6; //6 = scriptnotfound script :)
switch (argument0) {
case "load_room":
sid = 0;
break;
case "show_dialog":
sid = 1;
break;
case "close_dialog":
sid = 3;
break;
case "scrExample":
sid = 4;
break;
}
return sid;
So now I can call script_execute(script_id("close_dialog"));
I hate it, but it's better than keeping a spreadsheet... in my opinion.
There's also another way, with execute_string();
Should look like this:
execute_string(string(scriptName) + "();");

Objective-C, Expression result unused, from some old code?

I've getting the following warning Expression result unused
I've inherited the code from my predecessor and I've no idea how to fix this?
Obviously syntax has changed, any ideas ?
static float lowValue;
static float highValue;
- (void) calculateHighLow{
highValue; //here
lowValue; // and here
Simply delete those two lines, they have no purpose.
Obviously those two lines don't do anything so you can just remove them.
If they aren't being used anywhere you can just delete the lines, or you can simply just decide to deal with the warning (though not a good idea). You can also comment out the code, in case you figure out that might need them someday.