作为一个有抱负的苹果开发者，如果在进入Objective-C之前最好先学习C，最终可以获得Cocoa框架，那么我想获得社区的意见？
我的直觉说学习C，这将给我一个很好的基础。
Being an aspiring Apple developer, I want to get the opinions of the community if it is better to learn C first before moving into Objective-C and ultimately the Cocoa Framework?
My gut says learn C, which will give me a good foundation.
最满意答案
我先学C。 我学习C（并在C中做了很多），然后再转到Obj-C。 我有很多同事，从来不是真正的C程序员，他们从Obj-C开始，只需要了解C就可以了。
我现在看到他们如何在Obj-C中完全解决问题，有时会导致非常笨拙的解决方案。 通常我会用纯C代码替换一些Obj-C代码（毕竟你可以混合使用它们，所以Obj-C方法的内容可以是纯C代码）。 没有任何意图侮辱任何Obj-C程序员，有一些在Obj-C中非常优雅的解决方案，这些解决方案通过对象 （OOP编程可以使复杂的程序更可爱，函数式编程;多态性例如是一个辉煌的功能）...我真的很喜欢Obj-C（比C ++更多！我讨厌C ++语法，一些语言特性是简单的过度杀戮，导致坏的开发模式IMHO）; 然而，当我有时重写同事的Obj-C代码（我真的只是这样做，如果我认为这是绝对必要的），结果代码通常减小50％，只需要25％的内存使用之前和运行时速度快约400％。
我想在这里说些什么：每种语言都有其利弊。 C具有利弊，Obj-C也是如此。 然而，Obj-C的真正伟大的功能（这就是为什么我甚至比Java更喜欢它）是你可以随意跳回到C，然后再回来。 为什么这是一个很好的功能？ 因为就像Obj-C修复了纯C的许多缺点，纯C可以修复Obj-C的一些缺点。 如果你把它们组合在一起，你会收到一个非常强大的团队。
如果你只学习Obj-C，不知道C或只知道它的基础知识，从未尝试过如何优雅地解决一些常见的问题，实际上只学到了一半的Obj-C。 C是Obj-C的基本部分。 随时随地使用C的能力是其基本特征。
一个典型的例子是我们使用的一些代码，它们必须在base64中编码数据，但是我们不能使用一个外部库（没有OpenSSL lib）。 我们使用了一个base64编码器，完全用Cocoa类编写。 它工作正常，但是当我们编码200 MB的二进制数据时，它花了一个永恒，内存开销是不能接受的。 我用一个小巧，超紧凑的base64编码器替代了一个完全作为一个C函数（我将函数体复制到方法体中，方法将NSData作为输入并返回NSString作为输出，但在函数内部的所有内容都是C）。 C编码器更加紧凑，它以纯粹的可可编码器以8倍速度击败，内存开销也少得多。 数据的编码/解码，用位和类似的低级任务玩弄只是C的强点
另一个例子是一些UI代码，绘制了很多图。 为了存储绘制图形所需的数据，我们使用了NSArray。 实际上是NSMutableArray的，因为图形是动画的。 结果：非常慢的图形动画。 我们用正常的C数组替换所有的NSArray，使用结构体的对象（在所有的图形坐标信息都不需要对象之后），使用简单的循环进行枚举器访问，并开始使用memcopy在数组之间移动数据，而不是从一个数组到数组另一个，索引索引。 结果：加速因素4.图形动画平滑，甚至在旧的PPC系统上。
C的弱点是，每一个更复杂的程序从长远来看变得丑陋。 保持C应用程序可读性，可扩展性和可管理性需要程序员的大量纪律。 许多项目失败了，因为这个纪律缺失了。 Obj-C可以轻松地使用类，继承，协议等来构建应用程序。 也就是说，除非必要，否则我不会在方法的边界使用纯C功能。 我更喜欢将Objective-C应用程序中的所有代码保存在对象的方法中; 一切都破坏了OO应用程序的目的。 然而在这个方法中，我有时只使用纯C。
I would learn C first. I learned C (and did a lot in C) before moving to Obj-C. I have many colleagues who never were real C programmers, they started with Obj-C and learned only as much C as necessary.
Every now and then I see how they solve a problem entirely in Obj-C, sometimes resulting in a very clumsy solutions. Usually I then replace some Obj-C code with pure C code (after all you can mix them as much as you like, the content of an Obj-C method can be entirely, pure C code). Without any intention to insult any Obj-C programmer, there are solutions that are very elegant in Obj-C, these are solutions that just work (and look) a lot better thanks to objects (OOP programming can make complex programs much more lovely than functional programming; polymorphism for example is a brilliant feature)... and I really like Obj-C (much more than C++! I hate the C++ syntax and some language features are plain overkill and lead to bad development patterns IMHO); however, when I sometimes re-write Obj-C code of my colleagues (and I really only do so, if I think this is absolutely necessary), the resulting code is usually 50% smaller, needs only 25% of the memory it used before and is about 400% faster at runtime.
What I'm trying to say here: Every language has its pros and cons. C has pros and cons and so does Obj-C. However, the really great feature of Obj-C (that's why I even like it more than Java) is that you can jump to plain C at will and back again. Why this is such a great feature? Because just like Obj-C fixes many of the cons of pure C, pure C can fix some of the cons of Obj-C. If you mix them together you'll receive a very powerful team.
If you only learn Obj-C and have no idea of C or only know the very basics of it and never tried how elegantly it can solve some common problems, you actually learned only half of Obj-C. C is a fundamental part of Obj-C. The ability to use C at any time and everywhere is a fundamental feature of it.
A typical example was some code we used that had to encode data in base64, but we could not use an external library for that (no OpenSSL lib). We used a base64 encoder, entirely written using Cocoa classes. It was working okay, but when we made it encode 200 MB of binary data, it took an eternity and the memory overhead was unacceptable. I replaced it with a tiny, ultra compact base64 encoder written entirely as one C function (I copied the function body into the method body, method took NSData as input and returned NSString as output, however inside the function everything was C). The C encoder was so much more compact, it beat the pure Cocoa encoder by the factor 8 in speed and the memory overhead was also much less. Encoding/Decoding data, playing around with bits and similar low level tasks are just the strong points of C.
Another example was some UI code that drew a lot of graphs. For storing the data necessary to paint the graphs, we used NSArray's. Actually NSMutableArray's, since the graph was animated. Result: Very slow graph animation. We replaced all NSArray's with normal C arrays, objects with structs (after all graph coordinate information is nothing you must have in objects), enumerator access with simple for loops and started moving data between the arrays with memcopy instead of taking data from one array to the other one, index for index. The result: A speed up by the factor 4. The graph animated smoothly, even on older PPC systems.
The weakness of C is that every more complex program gets ugly in the long run. Keeping C applications readable, extensible and manageable demands a lot of discipline of a programmer. Many projects fail because this discipline is missing. Obj-C makes it easy for you to structure your application using classes, inheritance, protocols and so on. That said, I would not use pure C functionality across the borders of a method unless necessary. I prefer to keep all code in an Objective-C app within the method of an object; everything else defeats the purpose of an OO application. However within the method I sometimes use pure C exclusively.
更多推荐
发布评论