After migrating from XCODE 4 to 4.2 i have quite a few problems with my applications, many of them due to my own bad code quality.
As an example i had for some reason done two calculations looking like:
xx = xx++
...which worked in XCODE 4 but not in 4.2 where the compiler jumped over and did not either process or warned about it. This took me a week to find&fix even if i tried to read-up on the differences between 4 and 4.2.
Changed it to:
xx++
..so it works now :-)
However, i still have problems so i wonder if someone could point me to where i can read about these type of "smaller but important" differences, which hopefully can help me track the other issues down.
Cheers
Welcome to the wonderful world of undefined behaviour. These sorts of changes are not often documented, because they only occur when you break your contract with the compiler.
See this question (it is related to C++, but there are a lot of common undefined behaviours between C++ and Objective-C) for some more examples.
Related
I starting to look into porting my application from Gtkmm 3.24 to Gtkmm 4.x (not sure which version yet). For now, I am only trying to understand what exactly is deprecated and how much work is needed for planning. One way to ease porting is to look into all deprecated usages in the Gtkmm 3.24 version and update them to the newer flavor before porting. I have found several macros that can help with that:
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
When I #define these, the compiler throws error when meeting deprecated stuff because they have been disabled. This is nice, once the code is leveled up, to make sure the code stays free of deprecated usages.
In my case, however, the code is still full of deprecations and the compiler stops compilation on the first deprecation it meets. This does not help me much in understanding where the deprecations lie and how much work is needed. I could go about and solve every error, one by one, until there is no more (this is ultimately what I will do) but I can't know ahead how much time this will take.
What I would really like are macros that throw warnings when meeting deprecation, but let the compiler go on about building. This way I could get a list of everything that is deprecated in my codebase and plan work appropriately. I have browsed the Gtkmm documentation and codebase but found nothing.
Do such macros exist and if so, what are they?
The solution was to use
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
like I did but to use the -k flag with make. From man make:
-k, --keep-going
Continue as much as possible after an error. While the target
that failed, and those that depend on it, cannot be remade, the
other dependencies of these targets can be processed all the same.
Source: Inkscape GTK+ 3 migration wiki page.
I was following this tutorial
http://blog.lukasjoswiak.com/gameplaykit-for-beginners-part-1/
and when I got to the end, I wanted to try to make the towers not completely impassable, but just have a higher cost.
so, I subclassed GKGridGraphNode and added a cost variable, overrode the costToNode function and tried to insert my cost variable into the equation.
I cannot seem to get it to work. The documentation on this is really doesn't explain having node cost beyond mentioning it in the subclassing notes. I was wondering if anyone has managed to do this?
I am probably going about it wrong, but even reading the Swift headers doesn't really give me any clues.
Thanks for the help
Update: Closed as duplicate
I had a similar question, and I used one of my Apple developer support tickets to try to get an answer.
Apple responded and told me it was a known issue, and that there was a potential fix in the iOS SDK 9.2 beta 2, released November 3, 2015. I verified that the tests in my test project pass in 9.2b2, and so I expect that version to resolve this issue.
While doing some analysis on the usage details for the SquishIt framework, I came across a link as mentioned below:
https://danielsaidi.wordpress.com/tag/squishit/
which describes that SquishIt is having some problems with getting to work with JavaScript closures.
I am currently using the latest version :0.9.3.0 of SquishIt.Mvc. Can anyone help me to know whether this version has still the issues while working with JavaScript closures.
I am not aware of any issues at this time (was not aware of any in 2010 either however). It seems like any issues with closures are probably really issues with the minification library used, or files incorrectly terminated. At some point in the last couple years I think we did start adding semicolons between concatenated files if not present to deal with the latter. If you do find any I would love to hear about them.
Semantic issue: 'mutable' cannot be applied to references
The above is only the latest in a series of errors I've received attempting to get the fuego-iphone project to compile. I'm not certain, but it could be related to the way I compiled boost. The project's README recommends using these instructions for compiling boost into a framework, but I had already done so with the more recent instructions here. Could this CLANG error be related to a boost version somehow?
I admit relative ignorance when it comes to C++.
If anyone has any brilliant suggestions for using the fuego library in general with xcode, I have tried quite a few different things, and am pretty much at wit's end. Thanks!
EDIT: Apologies for any ambiguity here, but I'm not asking about mutable references, so much as showing the latest symptom of this issue. The fuego mailing list has a relevant question about using boost 1.48, and checking now, it's clear that I've compiled 1.49, so I'll recompile an earlier version of boost and see if that fixes it somehow.
The mutable modifier means that a field can be changed from within a const method. But for reference fields, that doesn't make any sense, because references can never be changed in C++.
When ever I try to push my app to my ipad or ipod to test them I get this error...
alignment lost in merging tentative definition _resultbuffer.
What is it? Any idea how to fix it?
I'm going to take a wild guess here, apologies if I'm too far off the mark:
On the ARM processor alignment can be an issue, particularly if you're accessing a variables in an unaligned manner, I suspect this is what you're seeing:
Here's a couple links that might see you through this:
gcc type-attributes documentation (Yes, I know its compiling with clang, this still may help)
Basically the same thing from ARM's documentation
A pretty good write-up about ARM alignment and how to avoid problems
Most flavors of ARM will automatically 'fix' this by adjusting the alignment on the fly, however this is configurable. The down-side is it causes a CPU interrupt to handle it, so if you're doing this over and over it'll slow things down. I haven't run into this on iOS, so I can't say for sure what the behavior would be. Odds are its best just to fix it.