Objective-C Overtakes C++, But C Is Number One 594
mikejuk writes "Although the TIOBE Index has its shortcomings, the finding that Objective-C has overtaken C++ is reiterated in the open source Transparent Language Popularity Index. The reason is, of course, that Objective-C is the language you have to use to create iOS applications — and as iPads and iPhones have risen in popularity, so has Objective-C. If you look at the raw charts then you can see that C++ has been in decline since about 2005 and Objective-C has shot up to overtake it with amazing growth. But the two charts are on different scales: if you plot both on the same chart, you can see that rather than rocketing up, Objective-C has just crawled its way past, and it is as much to do with the decline of C++. It simply hasn't reached the popularity of C++ in its heyday before 2005. However the real story is that C, a raw machine independent assembler-like language, with no pretense to be object oriented or sophisticated, has beaten all three of the object oriented heavy weights — Java, C++ and Objective C. Yes C is number one (and a close second in the transparent index)."
Re:I guess you don't understand languages either (Score:5, Informative)
typedef struct { // And data goes here.
int (*open)(void *self, char *fspec);
int (*close)(void *self);
int (*read)(void *self, void *buff, size_t max_sz, size_t *p_act_sz);
int (*write)(void *self, void *buff, size_t max_sz, size_t *p_act_sz);
} tCommClass;
http://stackoverflow.com/questions/351733/can-you-write-object-oriented-code-in-c
Objective-C not required to create iOS Apps (Score:3, Informative)
"Objective-C is the language you have to use to create iOS applications"
There are plenty of games and other iOS applications that are written in C and C++.
Yes, there is a little bit of "glue" code required for interaction with Apple APIs, but the implication here is that you can't use another language write the majority of an iOS Application, which is wrong.
Re:I guess you don't understand languages either (Score:3, Informative)
you are aware that the first C++ compilers simply generated C code from the C++ then compiled to that.
Oh, and I've seen several OO languages written in C as well, that some senior engineer who "didn't trust C++" came up with. The only thing you don't get with these is enforcement of visibility with private/public, which isn't strictly required for OO. But polymorphism and the lot, yup, all that was there.
Re:see plus (Score:2, Informative)
BS!
I have written fast programs in both Java and C# that are maybe 10% slower than pedal to the metal C or C++. It really does depend on how you write the code. There are things that make Java and C# very slow. In fact I think one can argue that the current incarnation of C++ is a dog in terms of performance. With all of that template "goodness" you are just loping on stuff that Java and C# can do in an easier manner.
BTW for reference I write financial algorithms that include Monte Carlo simulations.
Re:Ever tried looking for jobs using C? (Score:5, Informative)
Mod parent up. "The popular search engines Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings." That's rather lame. Exactly how do they search for "C", anyway? Do Sesame Street episodes brought to you by the letter C count?
The decline in C++ is probably real. It's on the way out as an application-level programming language. Big, complex applications with serious performance requirements and elaborate internal data structures, like 3D CAD, benefit from being written in C++. But there's no reason to write a routine desktop business app in it any more. Just moving windows and menus around and talking to the database can be done far more easily by other means.
Re:I guess you don't understand languages either (Score:4, Informative)
An object-oriented language has lots of syntactic help for the purpose, but all languages compile to some type of runtime code structure. If you understand what code gives the object-oriented behavior you want, then you can write it in C.
And yes, the poster who said C was assembler-like likely has never seen an assembler language, I would guess. I do remember writing a C routine once which had an initialized array containing hex representations of machine code to do a particular highly specialized task, and then using some coding wizardry to get the locus of control into that array when needed. Ah, those were the days.
Re:I guess you don't understand languages either (Score:5, Informative)
Considering that C++ was originally implemented as a preprocessor for C, there's an existence proof that says you are wrong.
Re:I guess you don't understand languages either (Score:5, Informative)
doesn't need to be void, even. (I'm sure purists will complain about _t being reserved)
[header file] ...
typedef struct something_s something_t;
something_t *private stuff;
[C file] ...
struct something_s {
};
I use this sort of construct quite a lot.
Re:I guess you don't understand languages either (Score:4, Informative)
And yes, the poster who said C was assembler-like likely has never seen an assembler language,
C doesn't look like 6502 or 1802 or 10f220 assembly, but if you squint you can see some PDP-11 addressing modes in there. Because a primary dev box was a ....
Also I see aspects of BAL from MVS370 but maybe thats just dead brain cells flickering.
Re:fp (Score:5, Informative)
Oh, and by the way, you left color[0] and [1] undefined on both of your Buttons.
The C standard requires the compiler initialize all stack-allocated memory to zero. color[0] and color[1] are exactly as the OP specified. To be safe, they should indeed be initialized to zero. In professional practice, I always memset everything I allocate to 0 for the entire block of memory I have allocated, and then initialize individual members of structures to whatever their default value should be.
The C standard requires static variables to be initialized to zero by default. Stack variables that aren't explicitly initialized can be random garbage.
To verify that I'm correct, I just tested it:
Re:fp (Score:5, Informative)
The advantage of the object oriented paradigm is not primarily that it makes programming easier or faster. It is the better support of separation between different components, which makes it possible to contain the complexity of large projects with multiple software engineers.
Of course, there are other ways of handling large projects (for example, there are examples of large projects written in C that control complexity by conventions about the separation of data and modules). But the object oriented paradigm is a common choice for large software engineering projects.
You might miss this when learning from a text book, since you are often only given small code examples and toy object hierarchies. But that extra 'overhead' around the defining of object abstraction pays off as the complexity increases. For many problems, thinking in terms of objects rather than instruction sequences can make the problem easier to solve.
Starting off with C and moving to C++ is not necessarily a good process, as you will not begin to learn to think in terms of objects; it is a completely different way of problem solving. Even for experienced programmers, the transition from C to C++ can be a six month process, not because of the extra language features, but because it requires a change in approach. Many don't stick at it long enough to realize the benefits.
The trade-off over speed is not an issue at all; for example, C++ is not significantly slower than C. Speed is affected far more by other choices; data structures and algorithms, memory localization, parallelism, and so on.
And you would also be aware that there are other paradigms as well, such as functional programming. These paradigms are not just "different tools for the job". They can have a radical impact on problem solving methods.
Re:sorry (Score:5, Informative)
That'd be like saying letters are no longer required because we'll all be using words and sentences from now on.
That's what the Chinese did!
Kind of but not really. There are far, far more words in Chinese than there are Chinese characters and characters often don't stand on their own as words. Rather individual characters represent morphemes with a single (or small number of) sounds, which often have no real meaning on their own. These morphemes are then combined to form words. In that sense Chinese characters are like an alphabet, albeit with characters which represent complete syllables rather than individual sounds and which generally (but not always) have some sort of semantic meaning. Secondly if you look at the way characters are formed in Chinese, there is a set of basic characters which are used as phonetic units in constructing most of the other characters. Most of the other characters end up consisting of a basic character indicating the phonological sound and a radical to (very broadly) indicate the semantic meaning of the character. So in terms of both 1. how the characters are used and 2. how the characters are constructed Chinese characters still deal with sound and meaning at a sub-word level.