瓦肯举手礼

残影，不过不影响一般使用

DIVEIN10 测过也可以

第二个这种叫做 Shortcut Constructor Method

• What is the external interface for creating a new object when a Constructor Method is too wordy?

• Represent object creation as a message to one of the arguments to the Constructor Method. Add no more than three of these Shortcut Constructor Methods per system you develop.

摘自 "Smalltalk Best Practice Patterns"

这个也很凶残 http://graphics.stanford.edu/~seander/bithacks.html

或者学下苹果怎么隐藏 API 。。。
https://github.com/JaviSoto/iOS7-Runtime-Headers/commit/6ccf9c4526992fec0dc414d48e4a3f7446e9822f#commitcomment-4059894

Hopper 的反汇编效果不错，能生成伪代码，稍微好理解一些，不过离 Java 反汇编的效果还很远

Github 404 页面的设计师把它开源了 http://cameronmcefee.com/plax/

下个试试先

cello +1

刚在京东买了胶饵，这玩意真不便宜，明天给小强们进补，希望有效。。。

手动装好折腾，直接用bitnami的安装包了事

这是这么多语言的官网里面最漂亮的

可以跟一下Code School那个iOS开发系列，教程做的不错 http://www.codeschool.com/paths/ios

把project.pbxproj排序后再提交可以避免merge冲突，排序脚本在此：https://raw.github.com/WebKit/webkit/master/Tools/Scripts/sort-Xcode-project-file

@breeswish 是之前看过的文章

This enormous 64 bits worth of address space is divided up into two areas: The stack and the heap. The stack is an area set aside high in the address space (typically high, anyway; in practice it can be just about anywhere) for the use of subroutine calls and local variable storage. The stack always grows downward; as the amount of information on the stack increases, the address of the top of the stack decreases. On older systems with smaller memory models, it was possible for the stack to grow too far downward and collide with other areas, but while it's still technically possible for this to happen, other things would go wrong long before a heap collision (in particular, the stack would run off the edge of its allocated memory pages and cause a protection fault). The CPU has a few instructions specifically designed for manipulating the stack, though they often go unused in favor of more efficient methods in modern code. You can think of the stack as a moderately large chunk of memory allocated by the system at the launch of your program.

The heap effectively consists of every area of memory that is not the stack; memory from the heap is allocated at runtime by the system for the process' use. The heap contains the stack, in fact, though they are usually considered conceptually separate. All of your executable code is loaded into a section of the heap, as well as copies of any libraries your executable links to. Note: These are not actually copies, as it would be ridiculously inefficient to copy every library for every loaded process, but it's easier to just think of them as copies until you have a good grasp of virtual memory. Memory allocated by your process during its execution also comes from the heap.

http://www.mikeash.com/pyblog/friday-qa-2011-12-16-disassembling-the-assembly-part-1.html