Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Best C compiler
- Thread starter iasc
- Start date
- Sort by reaction score
If you install the apple developer tools from your OS DVD, or download them from apple, this will install gcc. I can't say it's the best C compiler, i don't have much to compare it against, but it has become a pretty broad de facto standard. It should do all the C compilation you could ever want at this stage of the game.
-Lee
-Lee
If you are new to programming, or at least new to c, then you are going to want an IDE (Integrated Development Environment). That is a tool that wraps around the compiler and other tools to make developing a lot easier. Apple ships XCode as part of their developer tools, and this is an IDE. Now comes the bad news: learning an IDE can be a bit of work as they are complex tools (much like the compilers they wrap around). So just be prepared that this is going to take some leaning (get a good book), some time, and a bit of effort on your part.
I disagree with this. I think it's best to learn vi(m) and compile on the command line, perhaps learn the make utility. When he gets to an IDE, he won't be so hopelessly confused / clueless about what's actually going on.
Agreed. The time spent learning an IDE is totally wasted at this point, especially if it's XCode. I love XCode, but i don't always have the luxury of working on a mac. Learning to write code in a text editor (like vi(m)) and compile at the command line is vital.
To get started, save this in a file called helloWorld.c in a text editor. If vi(m) is too scary to use from the commandline (hint: it isn't. get a cheatsheat) then save it in a "programmer's text editor" like textmate or textwrangler (there are many others available for OS X).
Code:
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello, World!\n");
return 0;
}Once you have this saved, open up the terminal and navigate to the directory you saved helloWorld.c. Now type either:
make helloWorld
or
gcc -o helloWorld helloWorld.c
This will produce a program called helloWorld in the same directory. You can run it with:
./helloWorld
-Lee
I think both approaches are valid to be honest and depends on the person. I think it's important to learn command line skills and not being dependent on Xcode, but it's something that I've gone back and learned later.
You certainly don't need to be a master of Xcode to make your way through many beginner books, and I don't think there's anything wrong with "taking it on faith" that the compiler is working black magic to make your code compile, as long as people eventually go back later to learn what's really going on.
There's a pretty high barrier to entry when you're trying to learn to program on your own, and I think there's an inherent value in keeping the process moving quickly to build some positive reinforcement. Getting stuck and hitting roadblocks right when you're first starting out can be insanely frustrating if you don't have the knowledge to figure out what you're doing wrong. Learning the Unix command line, and then a somewhat unintuitive text editor like vi(m) or emacs seems like more hurdles to introduce early on. I mean unintuitive in the sense that it's not easily discoverable like todays apps are, and requires working through tutorials.
I do think there's a lot of value in the pilotError/Lee approach however. For some people, a bottom up strategy is essential to how they learn.
You certainly don't need to be a master of Xcode to make your way through many beginner books, and I don't think there's anything wrong with "taking it on faith" that the compiler is working black magic to make your code compile, as long as people eventually go back later to learn what's really going on.
There's a pretty high barrier to entry when you're trying to learn to program on your own, and I think there's an inherent value in keeping the process moving quickly to build some positive reinforcement. Getting stuck and hitting roadblocks right when you're first starting out can be insanely frustrating if you don't have the knowledge to figure out what you're doing wrong. Learning the Unix command line, and then a somewhat unintuitive text editor like vi(m) or emacs seems like more hurdles to introduce early on. I mean unintuitive in the sense that it's not easily discoverable like todays apps are, and requires working through tutorials.
I do think there's a lot of value in the pilotError/Lee approach however. For some people, a bottom up strategy is essential to how they learn.
Because you hate productivly editing text on any unix-alike? You learn what you need when you need it. To get started you need about 4 commands. I probably know 40. There are probably tons more that I don't know, but I'm glad I know they're there if I need them. Hating vi is like hating a hammer. If you would rather use a rock to drive nails, do it, but don't plot the destruction of all hammers.
-Lee
No, I hate programs that are insanely unintuitive relative to everything else I've ever learned on any platform, including Unix. Comparing vi to a hammer is not accurate. It would be more like requiring an infant to get a passenger license simply to ride in the back seat of a car. If you are intimately familiar with everything in Unix except vi, you will still have serious trouble quitting the program. Even pico tells you how to quit when the program first opens.
Okay, I haven't touched vi in years (maybe actually a decade). It appears vim shows you how to quit when it first opens. Therefore, vim is not vi. I have had no experience with vim. I hate vi, and I wish it would die a slow painful death. It appears that other people agree, since it has had to be VIMproved.
The best C compiler would be GCC*, the only really other comparable one is the Intel Compiler.
*According to The University Of Waikato.
---
I dont like Vi, but its the only decent CLI Text Editor. I always try to use a GUI one if possible when doing text editing.
But using GCC is as easy as picking your nose. Just on bigger programs, make becomes a whining annoying bastard apparently.
*According to The University Of Waikato.
---
I dont like Vi, but its the only decent CLI Text Editor. I always try to use a GUI one if possible when doing text editing.
But using GCC is as easy as picking your nose. Just on bigger programs, make becomes a whining annoying bastard apparently.
Clang is the new kid on the block when it comes to C compilers and does a damn fine job of both retaining GCC compatibility while also improving numerous other aspects of compilation. I've yet to see decent comparisons of generated code when compared with the Intel compiler though. LLVM is certainly a decent backend so I am hopeful that the generated code is well optimised.
You got it. I've tried other editors, but I always go back to vi because the other editors (particularly GUI ones) just slow me down without adding anything of value. VI is actually pretty easy to learn--although it used to be easier before O'Reilly decided to make their book larger by including every possible variant in it. You only need about eight commands to get started and the other twenty that you will find useful can be picked up as you go along. Many of the more esoteric commands are for working on multiple files using terminals without windows. These days multiple windows and cut and paste works just fine.
As for not working like anything else, well if you're programming you're likely using regexes and calling programs such as grep and sort which work like vi. You can also set up your shell to work like vi so whether you're inside or outside the editor things look and feel the same.
I *do* actually know quite a bit about regular expressions, but I've very rarely found any need to search with regular expressions while programming. Yes, I've used grep to search include directories and third-party source directories, but I've almost never needed an actual regular expression as part of the search. I can only think of one example from four years of full-time programming, and I doubt vi would have been helpful with that (sed or awk used recursively on a directory would have been the equivalent of what I did in Xcode).
I know different people have different ways of doing things. I've never been much of one for keyboard shortcuts. It's easier for me to visually remember where a command is rather than to remember what keyboard shortcut goes with the command. The visual memory happens automatically, all the time, and is easily retained, while shortcuts and commands must be painstakingly memorized and are easily forgotten. Despite the fact that I've used pico for a decade and a half, I still have to look at the bottom of the screen to remind myself how to search. I know exactly where it is on the screen, but I forget the command because I rarely need it (cut and uncut, I remember because I've used them enough).
Oh, and I have almost the same low opinion of "info" because every time I try to use it, I get frustrated that it doesn't work the way I think it's likely to work, and then I just go use google to find documentation.
My only real experience is with GCC so :/
IMO, GCC > Intel just because of the
If AMD Then
[degrade performance];
I honestly cant wait for the day X86 is slapped in intels face for something better.