Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel Software Development Products for OSX

Posted by Hemos on from the seeding-the-landscape dept.

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."

83 comments

  1. Benchmarks already exist by ChrisDolan · · Score: 4, Interesting

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

    1. Re:Benchmarks already exist by ciroknight · · Score: 2, Informative

      On the other hand, the numbers don't exist for OS X/x86 (publicly, yet). While you might get a general code performance idea, there are a lot of specific things that OS X does oddly that might cause one compiler to be "better" than another.

      --
      "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
  2. apple uses objective c / uses of fortan by acomj · · Score: 3, Insightful

    Fortan is big in the modeling world, still. Oddly enough for a language that is that old, gives clout in science and engineering worlds.

    The C++ is nice but since most osx programs are written on objective c, probably of little use.

    Those math libraries look like the ticket though. Everone likes highly optimized math libraries.

    1. Re:apple uses objective c / uses of fortan by yabos · · Score: 1

      I think the Folding@home program is done in Fortran. Since there's no good Fortran compiler for OS X it makes it really slow.

    2. Re:apple uses objective c / uses of fortan by Jormundgard · · Score: 1

      ifc (intel fortran compiler) is blazing fast on linux, so I hope the OS doesn't get too much in the way of the Mac version.

    3. Re:apple uses objective c / uses of fortan by TheRaven64 · · Score: 4, Informative

      FORTRAN has a vector data type, which makes it a lot easier to optimise certain types of code for AltiVec, SSE, etc. If you write the code in C, you have to translate it into scalar intrinsics, and the compiler has to work backwards to attempt to determine the vector operations you meant. In FORTRAN you provide the vector operations, and all the compiler has to worry about is aligning the data so it can be used by the vector unit. For algorithms that can be expressed in a vectorised form, this makes FORTRAN a much better language for writing fast code, which is why it is still used a lot.

      --
      I am TheRaven on Soylent News
    4. Re:apple uses objective c / uses of fortan by mrsbrisby · · Score: 1

      GCC also has a vector type.

    5. Re:apple uses objective c / uses of fortan by zhiwenchong · · Score: 1

      Eh? What's this then?
      IBM XL Fortran (PowerPC)

    6. Re:apple uses objective c / uses of fortan by mrsbrisby · · Score: 1

      The C++ is nice but since most osx programs are written on objective c, probably of little use.

      It is trivial to write a translating compiler- in fact Apple has (had?) one for Objective-C and Objective-C++ at one point. Objective-C is a strict superset of C, so if XCode does directly target Intel's new offering I suspect that we'll simply see the translator again, and yes, it will be of considerable use.

    7. Re:apple uses objective c / uses of fortan by TheRaven64 · · Score: 3, Informative

      The vector type introduced by GCC is vector-unit dependent. For an AltiVec target, for example, it is 128-bits. The only operations on it are those directly supported by the vector unit. You have to manually break your data into vectors of the correct size. In FORTRAN, you can operate on arbitrary sized vectors as if they were scalars. The compiler can easily break your large vector into blocks that will fit the vector unit and modify your scalar operations to correspond to individual or compound vector statements. It can also distribute your operations between the vector and scalar units on the CPU easily.

      --
      I am TheRaven on Soylent News
    8. Re:apple uses objective c / uses of fortan by crmartin · · Score: 1

      Not necessarly. GCC provides compilation of Objective C in the GCC package, but it's defined as a preprocessor language ... if you can compile C, you can compile Obj-C.

    9. Re:apple uses objective c / uses of fortan by Frumious+Wombat · · Score: 1

      You'll have to confirm this with the Folding@Home people, but the versions I saw previously were spitting out Gromacs http://www.gromacs.org/ messages, which is written in C++. Depending on what version they use will depend on whether the Gromacs team included the PPC optimizations.

      Incidentally, IBM's XL Fortran simply screams on G5s. I've compiled ab-initio codes (Quantum Chemistry) with it, and get speeds identical to Opterons running Linux, compiled with Pathscale or IFC (in em64T mode). IBM's fortran may be why my cluster gets rolled into PPC Linux, when I can afford memory upgrades, rather than remain under OS-X. I like OS-X for the ease of use and programming, but it's hard to beat XLF in the field.

      --
      the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
    10. Re:apple uses objective c / uses of fortan by mrsbrisby · · Score: 1

      The GCC manual says it synthesizes instructions using a narrower mode, and I suspect (although haven't checked, TBH) that it does the same thing with GCC FORTRAN.

      The following does indeed compile on GCC 4 (on Tiger and FC4):

      typedef int zz __attribute__ ((vector_size(64)));

      but what you say may have been true in GCC 3...

    11. Re:apple uses objective c / uses of fortan by wealthychef · · Score: 1
      You'll have to confirm this with the Folding@Home people, but the versions I saw previously were spitting out Gromacs http://www.gromacs.org/ messages, which is written in C++.

      Why can't the program have both C++ and Fortran modules in it? We do this all the time where I work.

      --
      Currently hooked on AMP
    12. Re:apple uses objective c / uses of fortan by joib · · Score: 1


        You'll have to confirm this with the Folding@Home people, but the versions I saw previously were spitting out Gromacs http://www.gromacs.org/ messages, which is written in C++.


      Nope. Gromacs is written in plain C, with alternative implementations for some inner loops in fortran and asm.

    13. Re:apple uses objective c / uses of fortan by Frumious+Wombat · · Score: 1

      Drat. That will teach me not to look in the source directory before posting. My bad.

      --
      the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
    14. Re:apple uses objective c / uses of fortan by CyricZ · · Score: 1

      No, the GCC implementation of Objective-C is not a preprocessor. It is a full-blown compiler, just like the GCC C, C++, Java, Fortran, and Ada compilers. The Stepstone implementation, which hasn't been widely used for ages, was a preprocessor.

      --
      Cyric Zndovzny at your service.
    15. Re:apple uses objective c / uses of fortan by crmartin · · Score: 1

      Right. GCC can compile Objective C but it was defined — by Stepstone, specifically — as a preprocessor language. Just as I said.

  3. The reason why new Macs are so much faster? by yabos · · Score: 3, Interesting

    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.

    1. Re:The reason why new Macs are so much faster? by wouterteepe · · Score: 2, Insightful

      The main reason why OS X is so much faster is that the powerbook so far used the G4 processor, which is actually a rather old processor. Given that the G4 is already out there for so long, the compilers for G4 are quite well optimized, I'd expect.

    2. Re:The reason why new Macs are so much faster? by JanneM · · Score: 1

      The "4-5" number comes in part from Apple running the same benchmark on both CPU:s - a benchmark optimized for multiple cores. No wonder the single core Power CPU didn't do a good job on that. It is faster, but not that much faster. A bit disingenious.

      --
      Trust the Computer. The Computer is your friend.
    3. Re:The reason why new Macs are so much faster? by jtrascap · · Score: 3, Insightful

      Actually, the biggest single hardware reason isn't the processor but the bus speed. For example, my 9-month old (snif!) PowerBook 15" running at 1.67 Mhz on a 167 MHz (10:1) bus. The competative 1.67Mhz model of new MacBookPros have a 667 MHz bus = a shade under 4x speed difference. Then you can add in the better Intel-optimized compilers, GCC libraries, etc, etc...

    4. Re:The reason why new Macs are so much faster? by jtshaw · · Score: 2, Interesting

      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.

    5. Re:The reason why new Macs are so much faster? by bhima · · Score: 1

      While agree with all of what you said, I feel the need to point out that Freescale has had a much better high end dual core e600 PowerPC CPU out for quite sometime.

      --
      Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
    6. Re:The reason why new Macs are so much faster? by Anonymous Coward · · Score: 0

      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.

      Mac OS X 10.4.4 is still compiled with GCC. Intel's compiler is for C++, while the bulk of Mac OS X is written in C and Objective C.

    7. Re:The reason why new Macs are so much faster? by squiggleslash · · Score: 1
      The Mac OS X kernel and device drivers are written in C++.

      I'm sure a lot of the userland is written in Objective C, but ultimately the OS is a collaboration between the three languages. A lot of it is almost certainly written in C++ - the Finder, for example, which is a Carbon app and unlikely to be written in Objective C as a result.

      --
      You are not alone. This is not normal. None of this is normal.
    8. Re:The reason why new Macs are so much faster? by james968 · · Score: 1

      There are several reasons:

      Powerbook G4 is an older processor in the speed wars. There is less of a difference in between the G5 and Intel based iMac, but still some. (It is closer to 2-3x faster).

      The Powerbook G4 is single core, the Macbook Pro is dual core.

      Bus speed is 667 Mhz 4x faster, as well as faster memory.

      One drawback is that most of the program out there 'Right now' are compiled for PPC only and would run under Rosetta, so the performance will not be as good. Code that is "Universal" should be able to take advantage the faster processor.

    9. Re:The reason why new Macs are so much faster? by Krach42 · · Score: 1

      Actually, the biggest single hardware reason isn't the processor but the bus speed.

      ACTUALLY, the biggest single difference is from single processor to dual processor. And G4->Intel Core Duo is going to be a good increase in the first place.

      Why is everyone all "OMG, the iMac Intel is it's 2~3x faster than the iMac G5, how'd they do that?" Seriously, the G5 in the iMac G5 isn't much slower than a single iMac Intel chip... you just get two of them instead of one.

      Now, imagine them replacing the PowerMacs saying "It's upto 1.5x faster than the previous models!" Yeah, no wonder they upgraded the iMac first.

      --

      I am unamerican, and proud of it!
  4. Only a beta, and not free by TomatoMan · · Score: 1

    This is only an announcement of "plans", and a sign-up for a "free trial" of a *beta* version of the tools. No obvious word on pricing (OSX's Developer Tools are free), or release dates.

    --
    -- http://frobnosticate.com
    1. Re:Only a beta, and not free by crmartin · · Score: 1

      The linux tools are free for personal use.

  5. Notice its C++ and not Objective-C by pissu_man · · Score: 1

    Its a shame that most of the new OS X dev work is done using Objective-C and not C++. Most of the OS X developers would not be able to take advantage of Intel's optimizations. I wonder whether Apple would bundle this compiler with XCode? Probably not.

    1. Re:Notice its C++ and not Objective-C by ignorant_newbie · · Score: 2, Insightful

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

      why is this a shame? They're using a language that actually makes sense, rather than one that's just a bunch of ideas cobbled together on top of C, and you think this is a shame? or is it just that you didn't have an Objective C class when you went to devry*, so you don't know anything about it?

      Yes, Intel's compiler is faster on intel hardware than gcc. this is true in every os that runs on intel hardware... but makes almost no difference in the real world, except for processor intensive apps ( mp3 ripping, dvd encoding, etc ). so, for 99 % of the code written for any os, it just makes more sense to use a portable compiler, and a good language.

      * before you flame me on this, they didn't have an objective c class when I went there either. It's not that you suck, just that devry does.

      --
      Sitting Walrus Blog
    2. Re:Notice its C++ and not Objective-C by pissu_man · · Score: 0, Flamebait

      The way that you described C++, tells me where you are coming from - you don't know enough to do so. And NO, I didn't go to the same tech school as you! Your definition of "real world" is a lot different to ours.

    3. Re:Notice its C++ and not Objective-C by ignorant_newbie · · Score: 1
      I wrote

      Yes, Intel's compiler is faster on intel hardware than gcc. this is true in every os that runs on intel hardware... but makes almost no difference in the real world, except for processor intensive apps ( mp3 ripping, dvd encoding, etc ). so, for 99 % of the code written for any os, it just makes more sense to use a portable compiler, and a good language.


      you responded

      Your definition of "real world" is a lot different to ours.


      Instead of relying on ad-hominem attacks, please try to actually address the question. What real world applications that a typical mac user is going to use ( other than those I've listed above ) are going to benefit from a heavily optimized compiler?



      what about the fact that I don't like c++ makes me unqualified to discuss the relative merits of it's design when compared with objective c? In your opinion, what is so bad about objective c ? please site actual projects where you've used the language, and where c++ would have been a superior choice

      --
      Sitting Walrus Blog
    4. Re:Notice its C++ and not Objective-C by Anonymous Coward · · Score: 0

      Nothing about your post betrays your qualifications to write C++, just your objectivity. Statements like "using a language that actually makes sense, rather than one that's just a bunch of ideas cobbled together on top of C" show you have an obvious bias toward Obj-C / against C++. Both are fine languages, and he wasn't bashing Obj-C, he was calling you out for living up to your /. handle.

    5. Re:Notice its C++ and not Objective-C by mrsbrisby · · Score: 4, Interesting

      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.

    6. Re:Notice its C++ and not Objective-C by Anonymous Coward · · Score: 0

      Dude, learn a real language before they ship your job to India. Perhaps some Hindi would help!

    7. Re:Notice its C++ and not Objective-C by LWATCDR · · Score: 1

      "why is this a shame? They're using a language that actually makes sense, rather than one that's just a bunch of ideas cobbled together on top of C, and you think this is a shame? or is it just that you didn't have an Objective C class when you went to devry*, so you don't know anything about it?"

      Because most development for Windows and for Linux is not done with Objective-C.
      It is done with C++ on Windows and with c and C++ under Linux.

      If you want to port your program from OS/X to a different program you are going to have to re-write it into c++. If you are going to only write code for OS/X then fine.
      I have yet to see Objective-C bindings for QT or GTK so for Linux it is a none starter.
      So it has nothing to do with a person not knowing it and everything to do with the practical limitations of the language.
      I wish that there where good Objective-C bindings for QT. My next large project is going to use QT so that it will run on Windows, OS/X, and Linux. Nice to know I will have the Intel compiler available.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    8. Re:Notice its C++ and not Objective-C by Kickasso · · Score: 1

      all C code is also Objective-C code

      So what? All good C code is also C++ code.

    9. Re:Notice its C++ and not Objective-C by Anonymous Coward · · Score: 2, Informative

      Yeah, Ok, forget the whole language A -vs language B war:

      C++ is better here:

      vector va, vb, vc;
      vector vd; // .. fill data here ...
      vd = va * vb + vc;

      vs Objective-C:

      FloatVector * va, vb, vc;
      IntVector * vd; // .. fill data here ...
      [vd autorelease];
      vd = [IntVector vectorWithFloatVector:[[va multiplyFloatVec:vb] addFloatVec:vc]];

      Objective-C (err Cocoa) is better here:

      id someObj, someString = ...
      if([someObj respondsToSelector:@selector(stringValue)])
            someString = [someObj stringValue];

      vs C++:

      BaseClass * someObj = ...
      string someString;
      if(HigherClass * hc = dynamic_cast(someObj))
              someString = hc->stringValue();

      else if(OtherHigherClass * hc = dynamic_cast(someObj))
              someString = hc->stringValue(); // ... potentially way more ...

      These are only two examples off of the top of my head, but clearly, comparing languages without specifying domain is pointless, because I can come up with tons of examples where one is better than another. Hell I can even make VB look good if I limit myself to one of it's strengths, and avoid it's weaknesses.

      I love Objective-C, I also love C++. I choose the more appropriate for the task.

    10. Re:Notice its C++ and not Objective-C by crmartin · · Score: 1

      Sadly, that's no longer true. For a trivial example, there are keywords in C++ that aren't keywords in C, which means that you can good C code and find out that it won't compile under C++.

    11. Re:Notice its C++ and not Objective-C by mad.frog · · Score: 1

      > They're using a language that actually makes sense,
      > rather than one that's just a bunch of ideas cobbled together on top of C

      "One man's theology is another man's belly laugh."

      Perhaps we should extend this to language wars: "One man's sensibly designed language is another man's mutant freak."

      You may really dig Obj-C, but personally, I look at it and get the heebie-jeebies. It has its moments, but I hate the syntax, and for me, I'll take C++'s rigid type system over it any day.

    12. Re:Notice its C++ and not Objective-C by hunterx11 · · Score: 5, Informative
      I have yet to see Objective-C bindings for QT or GTK so for Linux it is a none starter.

      GNUstep may not be anywhere nearly as mature as Qt or Gtk, but it's hardly a non-starter.

      --
      English is easier said than done.
    13. Re:Notice its C++ and not Objective-C by mad.frog · · Score: 1

      > Objective-C is a strict superset of C

      Yes, but what version of C?

      It's been a while since I coded in Objective-C, but last time I did, it didn't appear to implement C99 standards... e.g.,

              for (int i = 0; i 99; ++i) { ... }

      would not compile because it didn't recognize the inside-the-for-loop variable declaration.

    14. Re:Notice its C++ and not Objective-C by mrsbrisby · · Score: 1

      So what? All good C code is also C++ code.

      Subjective. This construct:

      typedef void* class;

      is valid C and Objective-C, but not C++.

      You might say "most C code", or "a lot of C code", or even "my C code" and get less argument, but by saying "good C code" you're saying that anyone who wants to use an obvious type name (like class) in C (like Bjarne did with C-with-classes) isn't producing good code.

      Now, I may tend to agree: I think the author of C++ has no idea what he's doing and couldn't good code (let alone "good C code") his way out of a paper bag.

      Nonetheless, the measure of goodness is still subjective.

    15. Re:Notice its C++ and not Objective-C by mrsbrisby · · Score: 2, Informative

      It's been a while since I coded in Objective-C, but last time I did, it didn't appear to implement C99 standards...

      Probably since before 1999, or at least before C99 support was added.

      int main() {
            for (int i = 0; i < 99; ++i);
            return 0;
      }

      Compiled just fine with: gcc -std=c99 -o moo moo.m

    16. Re:Notice its C++ and not Objective-C by Kickasso · · Score: 1

      That's trivially fixable with a few -D compiler options.

    17. Re:Notice its C++ and not Objective-C by Kickasso · · Score: 1

      I had to fix things like this in other people's C code to compile it with a C++ compiler. Believe me, it's trivial compared to what I had to do to compile other's people C++ code with a different C++ compiler.

    18. Re:Notice its C++ and not Objective-C by aminorex · · Score: 1

      That was ALWAYS true. "class" was always a C++ keyword, and not a C keyword.
      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.

      --
      -I like my women like I like my tea: green-
    19. Re:Notice its C++ and not Objective-C by ceoyoyo · · Score: 1

      I hated the syntax too, for a while. Then I broke down and actually used it and now it makes perfect sense. It's just different. These days I code mostly in Python, Objective-C and C and switching modes between them is pretty much automatic (although I do occasionally still write myobject.mymethod instead of [myobject mymethod] in ObjC).

    20. Re:Notice its C++ and not Objective-C by mrsbrisby · · Score: 2, Interesting

      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++?

    21. Re:Notice its C++ and not Objective-C by TheSunborn · · Score: 1

      And it will take 5 minuts to rename your struct from class, to something else. (You do have a gui with refactor support right?)

      An other problem, which is a bit more work to fix, is that you have to cast (void *) so

      int *data=malloc(sizeof(int)*100) is not valid c++

    22. Re:Notice its C++ and not Objective-C by LWATCDR · · Score: 1

      GNUstep is interesting but very few people use it compared to GTK or Qt. Even if you don't use Gnome odds are very good that you will still have GTK installed so you can use Gimp, Gaim, or Eclipse.org. I would bet that many Linux desktops don't have Gnustep installed but very few don't have GTK or QT.
      For an individual GNUStep +objectiveC could be a great solution but if you are planing on building software for the masses C++ still is the compiled OO development of choice for Windows and Linux

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    23. Re:Notice its C++ and not Objective-C by crmartin · · Score: 1

      yeah, and some other subtleties. #define for NULL was another annoying one, as I remember. (And one of the reasons behind needing templates, as I vaguely recall.) The point was that making C++ a proper superset of C was always a goal, but never completely achieved. The keyword one was the first one that came to mind, but I tend to write either straight C (kernel code) or Common Lisp now and couldn't think of a fancier one.

    24. Re:Notice its C++ and not Objective-C by Brandybuck · · Score: 1

      QT uses a "moc" C++ compiler that isn't even really C++

      Qt programs are 100% pure C++. "signal", "slot", and "emit" are macros. Plain ordinary C macros. But far far prettier macros than those monstrosities Microsoft has for MFC. What moc does is to use those macros to generate signal/slot code. As such, it's not much different from Qt Designer, which generates GUI code from XML.

      You don't need stuff like this with Objective-C, to be sure, but beware getting stuck in that FUD pit of thinking that Qt isn't true C++.

      Objective-C is a strict superset of C, in the sense that all C code is also Objective-C code.

      The same can be said of C++ as well. Except for some niggling details that only petty pedants care about, all C code is also C++ code.

      Now, most proficient programmers have no problem picking up a new language in a matter of hours

      They may have picked it up, but they won't master it! Every language has its odd little corners and slightly altered paradigms that need much more than a few hours to fully understand. I suspect Objective-C code written by C++ programmers who only spent "a matter of hours" getting to know the language wouldn't be that great.

      --
      Don't blame me, I didn't vote for either of them!
    25. Re:Notice its C++ and not Objective-C by Brandybuck · · Score: 1

      The question is: why do C++ users think the barrier into Objective-C is so high?

      The barrier is high because only Apple uses Objective-C. You're going to face all sorts of hurdles using ObjC with Windows, Unix or Linux. I really wish ObjC caught on outside of NeXT and Apple, because it is such a nice language, but the reality is that it didn't.

      Using Objective-C to write GUI code outside of Mac OSX is difficult, to list one particularly high barrier, simply because there are no suitable(*) Objective-C GUI libraries. You either have to descend to low level Win32 or X11 C libraries, which is a major pain, or use something like GTK+ with a frustratingly different object model.

      (*)GNUstep is a native Objective-C framework, because it's chock full of NeXT/OSX paradigms. Sure you can write your application easily with it, but it will annoy the hell out of most Windows and Unix users.

      If I were a writing for primarily a Mac audience, I would be using Objective-C. But since I'm writing for Mac, Windows and Unix, I'm sticking with C++ for now.

      --
      Don't blame me, I didn't vote for either of them!
    26. Re:Notice its C++ and not Objective-C by krischik · · Score: 1

      Shure, but replies are not about how easy a -D can sort the incompatiblities out but on how little the OP knows about programming languages - and the differences between them.

      Martin

    27. Re:Notice its C++ and not Objective-C by squiggleslash · · Score: 1

      I think the GP was responding to the claim that if you write something in Objective C for Mac, you're going to have to rewrite the entire thing in C++ if you want to port it. The fact that "very few people use (GNUstep) compared to GTK or QT" is irrelevent to that assertion. No, if you port from OS X, you do not have to rewrite in C++. You can stick to Objective C and use the GNUstep framework for the port.

      --
      You are not alone. This is not normal. None of this is normal.
    28. Re:Notice its C++ and not Objective-C by mrsbrisby · · Score: 1

      If I were a writing for primarily a Mac audience, I would be using Objective-C. But since I'm writing for Mac, Windows and Unix, I'm sticking with C++ for now.

      You misunderstand: Look at the other threads on this subject. Many C++ users are vehemently opposed to Cocoa because it's Objective-C. They can use Objective-C++, and Objective-C/C++ isn't a fundementally different language. I think they don't realize these two points, and the barrier I refer to is why they don't realize these two points.

      GNUstep is a native Objective-C framework, because it's chock full of NeXT/OSX paradigms. Sure you can write your application easily with it, but it will annoy the hell out of most Windows and Unix users.

      Part of the flexibility that is *Step comes from those paradigms. They're absolutely wonderful, and it's a real shame those systems either can't or don't exist on other systems.

      I find Windows users genuinely don't appear to mind GNUstep applications; Linux users certainly seem to however. Perhaps this is a problem...

    29. Re:Notice its C++ and not Objective-C by atgeirr · · Score: 1

      > Is it because they secretly realize they don't know C?

      I will answer this: Yes, we realize that we don't know C. No, we do not keep it secret. If you are used to modern C++ with vector, string, *_cast, shared_ptr etc. it is not trivial to do things in pure C. I fear that I even will have to use malloc (*quakes in terror*) at some point if I use Objective-C. Also, in modern C++ everybody use the RAII idiom for all types of resources, while in Cocoa it seems to be standard to do manual reference counting - another difference that makes it more difficult.

      However I did try it, and discovered that it was not that hard after all! At least for simple programs I had no trouble. But for more complex things I would probably have to go the Objective-C++ route. C is just too much effort for me.

      Atgeirr

    30. Re:Notice its C++ and not Objective-C by TheUser0x58 · · Score: 1
      "all C code is also Objective-C code"

      not quite.

      int id;

      wont compile in Objective C, but its fine in C. might be trivial, but it can pose difficulties.

      --
      -- listen to interesting music, support independent radio... WPRB
  6. PLEASE: A vector-based switch statement?!?!?!? by mosel-saar-ruwer · · Score: 1

    FORTRAN has a vector data type, which makes it a lot easier to optimise certain types of code for AltiVec, SSE, etc. If you write the code in C, you have to translate it into scalar intrinsics, and the compiler has to work backwards to attempt to determine the vector operations you meant.

    Has ANYONE produced a language with vector-based switch statements?

    A pseudo-example might look like

    BooleanThingAMaBob theZerothBooleanThingAMaBob = new BooleanThingAMaBob(INSERT_BOOLEAN_VALUE_HERE);
    BooleanThingAMaBob theOnethBooleanThingAMaBob = new BooleanThingAMaBob(INSERT_BOOLEAN_VALUE_HERE);

    Vector theLogicVector = new Vector(theZerothBooleanThingAMaBob, theOnethBooleanThingAMaBob);

    switch(theLogicVector)
    {
    case [false, false]:
    blahBlah();
    break;

    case [false, true]:
    blahYada();
    break;

    case [true, false]:
    yadaBlah();
    break;

    case [true, true]:
    yadaYada();
    break;

    default:
    ickyIckyIckyFatangFatangReee();
    break;
    }

    I would do evil things to cute, charming, cuddly [& utterly innocent] little kittens if I thought it would give me this functionality in a language.

    1. Re:PLEASE: A vector-based switch statement?!?!?!? by woggo · · Score: 1

      Not to be snide, but if you have a bit-vector of truth values, can't you just use ints?

    2. Re:PLEASE: A vector-based switch statement?!?!?!? by TheRaven64 · · Score: 2, Informative
      Try Erlang. Not only does it have a binary (bit array) type, which is very useful for doing anything that involves talking to sockets, you can use pattern matching with it. This allows you to define a version of a function that is called when you invoke the function with an argument that matches the pattern, so you could (for example) have two versions of a function taking a bit-field, one of which is invoked when the third bit is 1, and the other when it is 0. You can do the same kind of pattern matching in switch statements.

      Oh, you also have process creation and message passing primitives in the language, allowing you to easily write very scalable code.

      --
      I am TheRaven on Soylent News
    3. Re:PLEASE: A vector-based switch statement?!?!?!? by Anonymous Coward · · Score: 0

      in OCaml, that would be something like


      match logicVector with
      | [false, false] -> blahBlah()
      | [false, true] -> blahYada()
      | [true, false] -> yadaBlah()
      | [true, true] -> yadaYada()
      | _ -> ickyIckyIckyFatangFatangReee()

      which seems even shorter than what you had hoped for.

      SML and haskell should behave similarly, and someone else noted that erlang does.

    4. Re:PLEASE: A vector-based switch statement?!?!?!? by aminorex · · Score: 1

      APL and Fortran both do this sort of thing well. Here is one way to do it in Fortran:

          elemental integer function myconditional(a,b)
              integer, intent(in) :: a, b
              select case (a+b)
              case(1, 2, 3, 5, 7, 11, 13)
                  return (a+b)^2
              case(4,9)
                  return a+b
              case(16:)
                  return 2*(a+b)
              case default
                  return a*b
              end select
          end function myconditional

          forall (i=1:n,j=1:m) c(i,j) = myconditional(a(i,j), b(j,i))

      Here's another way, closer to your model:

          boolean, intent(in) :: a(:), b(:)
          integer, intent(out) :: c(size(a,1))

          where (a)
              where (b)
                  c = elementalfunc(1:size(a,1))
              elsewhere
                  c = 1:size(a,1)
              end where
          elsewhere
              where (b)
                  c = int(a)+int(b)
              else
                  c = 0
              end where
          end where

      Fortran also has record types and pointers these days.

      Of course in APL it would be much much more concise, but compilers are lacking.

      Lisp does it well too -- especially scheme, but it's not as concise as APL. There are some amazing optimizing compilers for scheme, though. Look for Susskind's Stalin.
      Almost always outperforms OCAML, C, Fortran.

      --
      -I like my women like I like my tea: green-
    5. Re:PLEASE: A vector-based switch statement?!?!?!? by rsidd · · Score: 1
      switch(theLogicVector) { case [false, false]:

      Pretty much any functional language has this sort of thing. In Ocaml, for examples, you have "match" statements that can use tuples, lists, or whatever as arguments:

      let bool_and boolpair =
      match boolpair with
      (true, true) -> true
      | _ -> false
      ;;
      this defines a boolean "and" that takes a pair of bool's and returns "true" only if both are true. Not sure if this is what you meant... And by the way, ocaml compiles to pretty fast native code (comparable to C++) on most common architectures.
  7. Obviously... by mosel-saar-ruwer · · Score: 1

    Not to be snide, but if you have a bit-vector of truth values, can't you just use ints?

    Obviously, but now you're embedding "machine code" in an abstract software language.

    The purpose of a language is to abstract the "machine code" to the point that a maintainer of the code can glance at the code, and, without too much thought, realize more or less what it is that is transpiring within the code.

    PS: A priori apologies if "abstract" is forbidden to function as a transitive verb.

    1. Re:Obviously... by woggo · · Score: 1

      I absolutely agree with your claim that languages should abstract away machine-level details.

      However, representing bit-vectors as integers is an extremely common practice in C and other languages, and any competent programmer will recognize this idiom. (See for example the "flags" argument for the UNIX open(2) call.) With a little bit of (tasteful) preprocessor use, you can basically get the same sort of code as the example in your initial post. Finally, while you must put in some extra effort if data are to be shared between machines of different architectures, this practice is basically portable as well.

  8. THIS IS ... by Anonymous Coward · · Score: 0
    Intel Compiler C++ for Visual Studio and Linux!!!

    It always underperforms compared to GCC-4.x. But, it always outperforms the benchmarketing, hahahahaha.

  9. You can use Intel's compiler with Xcode by green+pizza · · Score: 1

    By default, Xcode uses gcc. In fact, Xcode itself is just a GUI development environment, you can use it with other compilers (such as IBM's G5 compiler). It's fairly simple to configure Xcode to use Intel's compilers if you find yourself in a situation where Intel's compilers would give you a boost. Where these "alternative" compilers are really helpful is with C++ and FORTRAN. Xcode supports C++ but I'm not sure about FORTRAN.

    And you can always compile from the command-line, either directly or with a makefile.

  10. Universal Binaries? by dadragon · · Score: 1

    Can it be used to make the Intel portion of Universal binaries along with something else to make the PowerPC code?

    --
    God save our Queen, and Heaven bless The Maple Leaf Forever!
    1. Re:Universal Binaries? by scrod · · Score: 1

      That's a very good question. I think it should even be possible to combine a PPC binary built with IBM's XLC PowerPC compiler for Mac OS X and Intel's x86 compiler using lipo! As long as they're Mach-O binaries I don't think there should be a problem.

  11. C99 Test. by krischik · · Score: 2, Insightful

    Thats a poor test. This particular feature has been with C++ for a while and most C vendors are also C++ vendors. All they had to do is copy it across to C. A good test whould be a C feature which is _NOT_ a C++ feature.

    BTW: The place where most so called C99 compiler fail are variant arrays - A feature even ALGOL 60 had (40 years ago) - and it's decendants like Ada and ISO-Pascal still have today. But C vendors can't get it right or worse don't even try.

    Martin

  12. restrict? by krischik · · Score: 1

    *good* C code would use "restrict" where appropiate but C++ does not know about the keyword "restrict".

    Just one more example where C != C++.

    Martin

    1. Re:restrict? by Kickasso · · Score: 1

      That's C98 I presume. I know nothing about it so perhaps it's true.

  13. so was C++ by krischik · · Score: 1

    True - but C++ was a preprocessor language when it started out as well.

    1. Re:so was C++ by crmartin · · Score: 1

      Uhm, so? All I was pointing out was that if you have a good C compiler, you can get to Objective C easily.

  14. C99 != C++ 2003 by krischik · · Score: 1

    Hello,

    Actually there are more then niggling details which seperate C99 and C++ 2003. C++ has new keywords which C++ won't understand. Also C99 has varing arrays which C++ has not got.

    Martin

    PS: I only care only of and compare the official ISO standarts and not any broken implementation. And older ISO standart have benn superseeded.

    PS2: I find it paticular sad that most C vendors are unable or unwilling to implement features which had been part of ALGOL 60, ISO Pascal and Ada 83.

    PS3: vector is no replacement for varing arrays since vector needs heap memory and while varing arrays can be created on the stack.

  15. Objective-C, Objective-C++ ... any more possible? by krischik · · Score: 1

    Hello,

    is that so? Is producing an Objective-C preprocessor realy that easy? If so: How about any other progamming language. There is Objective-C and Objective-C++ - could there be Objective-Ada or Objective-Fortran as well?

    I read a little about Objective-C (- I know I never become a real /.ter - I inform myself about the subject at hand instead of repeating FUD -). AFAIK or understand Objective-C lives from it's object orientated runtime environment. But could that not be accessed from any programming language?

    Martin

  16. Intel Beta by james968 · · Score: 1

    I signed up the beta, very shortly after it was announced. Today I got a message from Intel, thanking me and informing me the beta program was full b/c of the overwhelming response.

    (Despite the link saying I would get the download information immediately after signing up).

  17. Re:Objective-C, Objective-C++ ... any more possibl by crmartin · · Score: 1

    I don't know a tonne about the implementation -- back when Tom Love and Stepstone were pushing it, I was in grad school and far preferred C++, because it didn't cost money. But Objective C did depend on a runtime library to do things like, eg, garbage collection. Basically, if you look at Objective C, everything that had to be translated into C was indicated with @keyword structures, or between [square brackets].

    Oh, one other thing: I was wrong to agree that C++ is a preprocessor language in quite the same way, at least since (I think) cfront 1.1. Sometime around cfront 2.0, it became a compiler that compiled to C as the target language. The distinction there is that a "preprocessor" passes some code through unchanged, like ratfor and iftran did, while a C-targeted compiler parses the whole program into an abstract syntax representation and then generates code.

  18. Yes but... by tetabiate · · Score: 1

    are these products for free (for personal use at least) like the Linux versions?