So I am passing a view into a method, and I want to find the properties of some values from a CGRect that is contained within the view.
- (void)blahblah:(someView*)view
int originX = view.myCGRect.origin.x;
int originY = view.myCGRect.origin.y;
int width = view.myCGRect.size.width;
int height = view.myCGRect.size.height;
would this be a better way of writing it?
- (void)blahblah:(someView*)view
CGRect sameCGRect = view.myCGRect;
int originX = sameCGRect.origin.x;
int originY = sameCGRect.origin.y;
int width = sameCGRect.size.width;
int height = sameCGRect.size.height;
Or is there an even more efficient way of doing this?
Also, I'm new to objective-C so could somebody explain if there even is a difference between these two implementations; and if so, what is it?
In reference to the older, previously accepted answer:
In this case the compiler would not be able to perform the subexpression elimination automatically. The reason is that view.myCGRect is actually a dynamically dispatched message.
Since the compiler does not know in advance which method will be called and what side effects it might have it cannot just drop the redundant calls because there might be a semantic difference.
The second code snippet will be more performant.
See Comments:
What you're talking about doing is manual "common subexpression elimination", where a common value (view.myCGRect in this case) is "hoisted" ahead of several references to it. This is especially effective for loops, when the common code is placed outside the loop. But for most (but not all) cases the compiler (or JITC for Java) will be able to recognize these CSEs and "hoist" them automatically. However, I still find that the code is often easier to follow (and maintain) if you do the manual operation.
Related
I'm currently working on a project that does not include GSAP (Greensock's JS Tweening library), but since it's super easy to create your own Custom Easing functions with it's visual editor - I was wondering if there is a way to break down the desired ease-function so that it can be reused in a CreateJS Tween?
Example:
var myEase = CustomEase.create("myCustomEase", [
{s:0,cp:0.413,e:0.672},{s:0.672,cp:0.931,e:1.036},
{s:1.036,cp:1.141,e:1.036},{s:1.036,cp:0.931,e:0.984},
{s:0.984,cp:1.03699,e:1.004},{s:1.004,cp:0.971,e:0.988},
{s:0.988,cp:1.00499,e:1}
]);
So that it turns it into something like:
var myEase = function(t, b, c, d) {
//Some magic algorithm performed on the 7 bezier/control points above...
}
(Here is what the graph would look like for this particular easing method.)
I took the time to port and optimize the original GSAP-based CustomEase class... but due to license restrictions / legal matters (basically a grizzly bear that I do not want to poke with a stick...), posting the ported code would violate it.
However, it's fair for my own use. Therefore, I believe it's only fair that I guide you and point you to the resources that made it possible.
The original code (not directly compatible with CreateJS) can be found here:
https://github.com/art0rz/gsap-customease/blob/master/CustomEase.js (looks like the author was also asked to take down the repo on github - sorry if the rest of this post makes no sense at all!)
Note that CreateJS's easing methods only takes a "time ratio" value (not time, start, end, duration like GSAP's easing method does). That time ratio is really all you need, given it goes from 0.0 (your start value) to 1.0 (your end value).
With a little bit of effort, you can discard those parameters from the ease() method and trim down the final returned expression.
Optimizations:
I took a few extra steps to optimize the above code.
1) In the constructor, you can store the segments.length value directly as this.length in a property of the CustomEase instance to cut down a bit on the amount of accessors / property lookups in the ease() method (where qty is set).
2) There's a few redundant calculations done per Segments that can be eliminated in the ease() method. For instance, the s.cp - s.s and s.e - s.s operations can be precalculated and stored in a couple of properties in each Segments (in its constructor).
3) Finally, I'm not sure why it was designed this way, but you can unwrap the function() {...}(); that are returning the constructors for each classes. Perhaps it was used to trap the scope of some variables, but I don't see why it couldn't have wrapped the entire thing instead of encapsulating each one separately.
Need more info? Leave a comment!
Im using cocos2d (iOS) and box2d to create a game.
I have come to the point where I need to change the contact filter mid simulation and wondering how to go about this.
I need to use maskbits and categorybits, which is fine, im just unsure how to apply them to a b2body mid game.
I'm thinking I may need to retrieve the original b2fixture or b2fixturedef of the b2body on initialization, alter the values accordingly then call a method to refresh - world.Refilter()?
Does this sound somewhat accurate?
Any advice is surely appreciated
Oliver.
b2Filter filter;
for ( b2Fixture* f = body->GetFixtureList(); f; f = f->GetNext() ) {
f->GetFilterData( &filter );
filter.categoryBits = ...;
filter.maskBits = ...;
filter.groupIndex = ...;
f->SetFilterData( &filter );
}
Obviously this would change the filter settings for all fixtures on a body - if you want to be more selective you will have to be able to tell which fixture is which somehow. Eg. if you know it's the only circle fixture you could just look at the type of the fixture to decide, otherwise you would have to make use of the fixture's user data I guess.
You can iterate over all bodies in the b2World. On each body you can iterate over it's fixture and change it's filter. To identify your bodies you can use userData.
The answer from iforce2d might be obsolete. I got the following code working properly with box2d v2.2.1, cocos2D v2.0.0 using Xcode v4.5.2 (here I assume I have a pointer to a b2Body named 'body' with only one fixture, i.e., I don't iterate over all fixtures on the body):
b2Fixture *fix = body->GetFixtureList();
b2Filter filter = fix->GetFilterData();
filter.groupIndex = -1*kPlayerGroupIndex;
fix->SetFilterData(filter);
In the above code I prevent 'body' from colliding with my player body which also has the same groupIndex value, i.e., -1*kPlayerGroupIndex, where kPlayerGroupIndex is a positive integer constant. Any bodies with this negative groupIndex never collide with one another. You could also update the categoryBits or maskBits accordingly to prevent collisions.
GetFilterData(&filter) and SetFilterData(&filter) returned errors for me given the version numbers I quoted above.
first post here so sorry for the length of it. I've been lurking and learning a lot so far but now I have to step in and ask a question. I have read numerous posts here as advised in the FAQs, but I couldn’t find exactly the answer I’m looking for.
Before anything else, let me just say that I'm a total beginner in programming (let alone Objective-C) so please excuse me for any misuse of the terminology. Same goes for any funny english as english not my native language.
I'm building an unit conversion application with a main window containing (among other stuff) two popUpButtons. I'm using indexOfSelectedItem from both popUpButtons in order to calculate a float value (I'm getting the indexes initially in the AwakeFromNib and later in the pop up buttons controller method, when the user change selection).
My problem consists of two parts: first, the code for calculation of that float is pretty massive as I'm comparing every combination of the two indexes of selected items. And second, I would need to have the calculated float value available immediately after launch as the user might want to perform a conversion before using any of the window popUpButtons (otherwise I would put the calculation code in a -(IBAction) method).
So, I'm trying with the following code for calculation of the float value:
#interface MyClass: NSObject
float calculatedFloat;
-(void)setCalculatedFloat:(float)calcFl;
-(float)calculatedFloat;
#implementation MyClass
-(void)setCalculatedFloat:(float)calcFl {
calcFl = 1.0; // I'm simplifying, this is where I'd like to perform calculation
}
-(float)calculatedFloat {
return calculatedFloat;
}
Now, for the first part of my problem, when I use the calculatedFloat in another method, say:
-(void)printIt {
NSLog(#"Calculated float equals: %.2f", calulatedFloat);
}
all I receive in Debugger is 0.00.
First question would be: if this is not working, how do I properly access this value from within another method?
For the second part of the problem, I'm using -(void)AwakeFromNib; to set up popUpButtons etc. right after the launch but I really wouldn't like to put all of the float calculation code in it only to repeat it somewhere else later.
So the second question would be: is this even possible what I'm trying to achieve? Further more, do I need to move this calculation code to another class? If so, how can I make that other class aware of the indexOfSelectedItem from a popUpButton?
Sorry for the lengthy post and possibly confusing and silly questions. I hope you didn't have to cringe your teeth too much while reading! :)
Thanks!
-(void)setCalculatedFloat:(float)calcFl {
calcFl = 1.0; // I'm simplifying, this is where I'd like to perform calculation
}
This doesn't show up when you print it later because you assigned to the variable holding the new value, not the variable for the value of the property. You need to assign to your calulatedFloat instance variable.
(You typo'ed that variable name, BTW.)
You should move the calculating into another method, and send yourself that message from awakeFromNib and from anywhere that needs to cause recalculation. That method should call setCalculatedFloat: with the calculated value—i.e., setCalculatedFloat: should be just a simple setter. Once you make that change, you could replace your custom accessors with a #synthesize statement and let the compiler write the accessors for you.
My problem consists of two parts: first, the code for calculation of that float is pretty massive as I'm comparing every combination of the two indexes of selected items.
You might see whether you can create custom objects to set as the menu items' representedObject properties, in order to cut out this massive comparison tree. It's hard to be more specific about this without knowing what your comparison tree does.
If a BOOL has a nice short name, it's easy enough to write:
myBOOL = !myBOOL;
But what if the BOOL has a long name?
objectWithLongishName.memberWithLongishName.submember.myBOOL = !(objectWithLongishName.memberWithLongishName.submember.myBOOL);
. . . does not look so pretty.
I'm wondering if there is an easy way to toggle the BOOL without entering its name twice?
Here's another:
MyBooleanYaddaYadda ^= YES;
This is kinda brittle - it will break on legacy C code that implies that any nonzero integer evaluates to true. But then again, so will Apple framework code - I encountered cases in Cocoa where a nonzero, non-one int, when passed as a BOOL, would not cause the same effect as passing a YES.
However, it does not rely on the bit pattern of YES - only on NO being 0. Which is pretty much a given, considering the way C interprets integers as logical values. Also, it does not assume the actual datatype of BOOL (which on Cocoa is signed char, by the way).
The bit pattern of YES on Cocoa is 1. But that's not a universal convention. On some platforms with no built-in boolean datatype, the integer constant that serves as a logical TRUE is -1 - all one bits. That's 0xFFFFFFFF if interpreted as unsigned. This coding has a vague advantage that bitwize NOT (the ~ operator in C ) is equivalent to logical NOT (the ! operator in C). That is, ~0xFFFFFFFF is 0, i. e. ~TRUE is FALSE. Doesn't work that way if TRUE is defined as 1.
#define NOT(b) (b) = !(b)
NOT(MyBooleanVariableWithAFreakishlyLongName);
Or, if it's Objective C++:
inline void NOT(BOOL &b)
{
b = !b;
}
No there isn't an obvious way in (Objective-)C to do what you describe (without using a preprocessor macro), but see Seva's answer for a possible (though potentially brittle) solution. More importantly, something like objectWithLongishName.memberWithLongishName.submember.myBOOL indicates a Law of Demeter violation; you should be providing submember directly to any code unit that needs to access submember.myBOOL.
Write a method for the submember class that toggles it for you?
- (void) toggleMyBOOL {
self.myBool = !self.myBool;
}
Then you can do:
[objectWithLongishName.memberWithLongishName.submember toggleMyBOOL];
Use XOR. In C, this is ^.
BOOL x = YES;
x ^= YES; // it's now NO
x ^= YES; // it's now YES
x ^= YES; // it's now NO
x ^= YES; // it's now YES
x ^= YES; // it's now NO
x ^= YES; // it's now YES
...
Edit: someone posted this already, apparently. I guess I should say I've never actually used this in code. :-)
You have a lovely set of answers focused on flipping a YES to a NO or vice-versa, but no answers that touched on what would appear to be an architectural issue in the code.
Well, some answers. I'm blind.
Namely, you have this:
objectWithLongishName.memberWithLongishName.submember.myBOOL =
!(objectWithLongishName.memberWithLongishName.submember.myBOOL);
That smells like a potential encapsulation violation. In particular (and assuming this is a model layer), it means that the connectivity of the sub-graph of objects is being overtly exposed -- flattened into, effectively -- the entry point of that path; whatever objectWithLongishName is must now have rather intimate knowledge of the innards of the objects along the rest of the path.
Typically, you don't reach deeply into the model layer along key paths to edit state outside of the Cocoa Bindings layer (and even that is a bit fragile).
Sometimes such long-ish paths do make sense. In such a case, I would leave the über-verbose form you have above as a visual indication that encapsulation is being purposefully shred.
float pi = 3.14;
float (^piSquare)(void) = ^(void){ return pi * pi; };
float (^piSquare2)(void) = ^(void){ return pi * pi; };
[piSquare isEqualTo: piSquare2]; // -> want it to behave like -isEqualToString...
To expand on Laurent's answer.
A Block is a combination of implementation and data. For two blocks to be equal, they would need to have both the exact same implementation and have captured the exact same data. Comparison, thus, requires comparing both the implementation and the data.
One might think comparing the implementation would be easy. It actually isn't because of the way the compiler's optimizer works.
While comparing simple data is fairly straightforward, blocks can capture objects-- including C++ objects (which might actually work someday)-- and comparison may or may not need to take that into account. A naive implementation would simply do a byte level comparison of the captured contents. However, one might also desire to test equality of objects using the object level comparators.
Then there is the issue of __block variables. A block, itself, doesn't actually have any metadata related to __block captured variables as it doesn't need it to fulfill the requirements of said variables. Thus, comparison couldn't compare __block values without significantly changing compiler codegen.
All of this is to say that, no, it isn't currently possible to compare blocks and to outline some of the reasons why. If you feel that this would be useful, file a bug via http://bugreport.apple.com/ and provide a use case.
Putting aside issues of compiler implementation and language design, what you're asking for is provably undecidable (unless you only care about detecting 100% identical programs). Deciding if two programs compute the same function is equivalent to solving the halting problem. This is a classic consequence of Rice's Theorem: Any "interesting" property of Turing machines is undecidable, where "interesting" just means that it's true for some machines and false for others.
Just for fun, here's the proof. Assume we can create a function to decide if two blocks are equivalent, called EQ(b1, b2). Now we'll use that function to solve the halting problem. We create a new function HALT(M, I) that tells us if Turing machine M will halt on input I like so:
BOOL HALT(M,I) {
return EQ(
^(int) {return 0;},
^(int) {M(I); return 0;}
);
}
If M(I) halts then the blocks are equivalent, so HALT(M,I) returns YES. If M(I) doesn't halt then the blocks are not equivalent, so HALT(M,I) returns NO. Note that we don't have to execute the blocks -- our hypothetical EQ function can compute their equivalence just by looking at them.
We have now solved the halting problem, which we know is not possible. Therefore, EQ cannot exist.
I don't think this is possible. Blocks can be roughly seen as advanced functions (with access to global or local variables). The same way you cannot compare functions' content, you cannot compare blocks' content.
All you can do is to compare their low-level implementation, but I doubt that the compiler will guarantee that two blocks with the same content share their implementation.