C 语言重拾【二】字符串
1 |
|
1 | #include <stdio.h> |
C 编程的基本策略是,用程序把源代码文件转换为可执行文件(其中包含可直接运行的机器语言代码)。
典型的 C 实现通过编译和链接两个步骤来完成这一过程。编译器把源代码转换成中间代码,链接器把中间代码和其他代码合并,生成可执行文件。C 使用这种分而治之的方法方便对程序进行模块化,可以独立编译单独的模块,稍后再用链接器合并已编译的模块。通过这种方式,如果只更改某个模块,不必因此重新编译其他模块。另外,链接器还将你编写的程序和预编译的库代码合并。
中间文件有多种形式。我们在这里描述的是最普遍的一种形式,即把源代码转专换为机器语言代码,并把结果放在目标代码文件(或简称目标文件)中(这里假设源代码只有一个文件)。虽然目标文件中包含机器语言代码,但是并不能直接运行该文件。因为目标文件中储存的是编译器翻译的源代码,这还不是一个完整的程序。
目标代码文件缺失启动代码(startup code)。启动代码充当着程序和操作系统之间的接口。例如,可以在 MS Windows
或 Linux
系统下运行 1BM PC 兼容机。这两种情况所使用的硬件相同,所以目标代码相同,但是 Windows
和 Linux
所需的启动代码不同,因为这些系统处理程序的方式不同。
如下,输入一个数组和一个目标变量:
input: [1, 3, 1, 3, 2, 2, 5, -1]
input: 4
要求找到此数组中所有两数之和等于目标变量的元素集合并返回,并且结果中不能有重复项。
我们都知道有的程序员能创造 10 倍的价值,那么我们是吗?
根据 20 世纪 60 年代进行的一份研究,对开发人员的各种方面(如代码简单性、程序大小、调试技巧、程序执行等)进行了比较。根据这项研究,普遍的共识是,一个优秀的开发人员和一个差劲的开发人员之间的差异可以达到20 倍之多,而中间值在大多数情况下是 10 倍。
这就是说,假设你已经苦干了多年,吸收了所有可能的技术,最终达到了令人垂涎的 10 倍高级开发人员级别。太棒了,恭喜!你应该得到名望和随之而来的尊重。现在你想攀登下一座山:成为一名优秀的技术经理。想想就觉得很美。
等等,让我们花点时间想想。
在许多方面,苹果的故事都是一些有趣的历史偶然事件将技术融合在一起,创造出比以前更好的东西:OS X 是 MacOS 与 NeXTSTEP 的结合。OC 是 Smalltalk 类面向对象编程与 C 的结合。iCloud 则是苹果移动服务与云平台的结合。
虽然苹果技术栈的许多方面都是如此,但是不得不说苹果技术中的进程通讯走的是“反人类”的道路。
由于不是根据每个节点上最优原则进行设计,苹果的进程间通信解决方案更显得混乱扎堆。结果是,大量重叠,不兼容的 IPC 技术在各个抽象层随处可见。(除了 GCD 还有剪贴板)
从低级内核抽象到高级,面向对象的 API,它们都有各自特殊的表现以及安全特性。但是基础层面来看,它们都是从不同上下文段传递或者获取数据的机制。
在 App 端,我们有一个 connection 对象。每次将数据发给 service 时,我们需要调用 remoteObjectProxyWithErrorHandler
方法来创建一个远程对象代理 (remote object proxy)。
而在service端,则多了一层。首先需要一个 listener,用来监听来自 App 的传入 connection。App 可以创建多个 connection,listener 会在 service 端建立相应的 connection 对象。每个 connection 对象都有唯一的 exported object,在 App 端,通过 remote object proxy 发送的消息就是给它的。
Building for iOS Simulator, but the embedded framework ‘xxx.framework’ was built for iOS + iOS Simulator.
升级 Xcode 后就悲剧了,以上报错苹果在 Xcode 11 中已经给出 warring,在 Xcode 12.3 版本后会直接 error。
来自苹果工程师的回复:
This framework isn’t built with a supported configuration – iOS and iOS Simulator code has never been supported in the same binary. The linker in Xcode 11 began identifying these incorrect configurations and issuing warnings, and Xcode 12 goes further in identifying these issues.
The only correct way to resolve this is to rebuild the framework as an XCFramework. If this is your framework, or owned by another group in your company, follow the information in the video and the Xcode Help article.
If this framework is from a vendor, then you need to work with the vendor to get an updated version of the framework built with supported configuration.
In the discussion of this thread, there is a build script that attempts to resolve this error. Scripts like that – anything that tries to manipulate the output with commands like lipo – still produces an unsupported configuration in the binary. XCFrameworks are the way to go.