Intel Software Development Products for OSX

rgraham writes "Intel has released a number of development tools for OSX, including a C++ and Fortran compiler. I for one would be interested to see some benchmarks of code compiled using these tools and Apple's own Xcode."

Comments

Benchmarks already exist

[ChrisDolan]

Apple uses GCC behind Xcode, so just look for the already-existing comparions of GCC against Intel's compilers.

The reason why new Macs are so much faster?

[yabos]

I wonder if this is the main reason why OS X is so much faster on the Intel chip. I can see the Powerbook getting a good speedboost but 4-5x is a lot more than what you'd expect.

Re:The reason why new Macs are so much faster?

[jtshaw]

It isn't just the dual cores. The G4 while a well designed processor, has far too slow a memory bus to compete. The Core Duo's memory architecture is about 5x faster. That, coupled with the 2nd core and the more modern design make the Duo well faster. I would be willing to be on memory intensive tests even a single core version of the new Intel chip would trounce the G4.

That being said.. it would be interesting to see good benchmarks between the dual core G5 and the Core Duo. I realize that currently there is no verison of the G5 suitable for laptops, but I'm still curious as to which chip is the all out performance leadering...

Oh well.. I bought a MacBook Pro anyway. Now I just have to wait.

Re:Notice its C++ and not Objective-C

[mrsbrisby]

Its a shame that most of the new OS X dev work is done using Objective-C and not C++.

I don't know that it would be a shame.

Certainly, if C++ were the language of choice for Cocoa, it might make C++ users feel more encouraged to target Cocoa, but it wouldn't actually help them write code for Cocoa.

The C++ interfaces for different display and widget systems are as different as the systems themselves- QT uses a "moc" C++ compiler that isn't even really C++ for signals and slots support- but encourages programmers to avoid tampering with the event loop, while Win32 encourages direct access with it.

So maybe if "Cocoa++" were around, it might help QT programmers (as the "moc C++" was designed to add features that Objective-C has, but that C++ didn't (and still doesn't well...)), but it certainly wouldn't help Win32 programmers in the slightest- except in "feeling" like all they've got to learn is a new API instead of a new language.

However, it may be better to point out that unlike the vast gap between C and C++ that makes them so distinctly different languages, Objective-C is a strict superset of C, in the sense that all C code is also Objective-C code. Apple also provides Objective-C++ which is a strict superset of C++, in the sense that all C++ code is also Objective-C++ code.

Now, most proficient programmers have no problem picking up a new language in a matter of hours; and Objective-C is so completely straightforward that just diving in is bound to validate that.

However, there are less-proficient programmers, and they tend to produce, sub-standard quality software. Given how much Cocoa software is of such high quality, it does beg the question: Is it the lack of poor programmers working in Objective-C, or is it that Objective-C is just that wonderful to use?

Having a "Cocoa++" might answer that question definitively, but I simply cannot see how that would be a Good Thing.

Re:Notice its C++ and not Objective-C

[mrsbrisby]

That was ALWAYS true. "class" was always a C++ keyword, and not a C keyword.

That's the point. C++ is not compatible with C, whereas Objective-C IS compatible with C.

It's not like trying to get a C programmer to write C++ (something that's very difficult), because Objective-C isn't anywhere near as complicated as C++ and yet does it so much better.

It's just not very interesting because it's trivial to resolve such incompatibilities -- unless your compiler is really, really good at reporting deceptive error messages, I guess.

So what? The question is not whether a capable C++ programmer can dive into C code, but instead what the barrier is with C++ programmers and Objective-C.

I pointed out that Objective-C is a strict superset of C, and Objective-C++ is a strict superset of C++. That means that if the programmer feels much more comfortable expressing certain logic in C or C++, they are able to when using Objective-C/C++.

This however, isn't true in the other direction- C users aren't always able to express C-think logic in C++.

Something like this:

const int *a;
float *b, z;
z = ...;
b = &z;
a = (const int *)b;

Not valid C++ at all, no in C++ you need:

a = const_cast<const int *>(b);

This isn't surprising, or even new: C++ is not C. It's not a "better C", or a "newer C", it's got about as much in common with C as Java does.

But Objective-C is C, and Objective-C++ is C++.

Fine: C++ is your favorite language. You might even find it a fine language. That's okay, and I'm not making any effort to dispute that, or convert you or anyone else.

The question is: why do C++ users think the barrier into Objective-C is so high? Is it because they secretly realize they don't know C?

Well what about the barrier into Objective-C++?