A frequently asked question on Mac programming forums is "Can I write C++ programs on Mac OS X?". Yes, you can write C++ programs on Mac OS X
Install the Xcode Tools
The Xcode Tools contain everything you need to write Mac OS X applications, including C++ programs. Every copy of Mac OS X contains the Xcode Tools. If you have Mac OS X 10.4, there should be an item called Xcode Tools on the Mac OS X DVD. This item contains the installer. Older versions of Mac OS X that ship on multiple CDs contain either an Xcode Tools or Developer Tools CD.
Apple frequently updates the Xcode Tools so the version that shipped with your copy of Mac OS X is most likely not the most recent version. If you have a broadband Internet connection, I recommend going to Apple's developer page and signing up for a free ADC membership. After signing up for an ADC membership, you can download the most recent version of the Xcode Tools.
One common concern people have when installing the Xcode Tools is the size of the install. The easy install of the Xcode Tools is over 1.5 GB, which is overkill if all you want to do is learn C++. You can perform a custom install of the Xcode Tools to reduce the size of the install. If you are low on disk space, the easiest way to save space is to not install the developer documentation. The developer documentation takes about 1 GB of disk space, and you can view all the documentation online anyway.
Writing Standard C++ Programs
The people most likely to ask if they can write C++ programs on Mac OS X are Mac-using college students who are taking a class on C++ programming. C++ programming classes normally teach standard C++, which will run on most operating systems, including Mac OS X.
To write a standard C++ program with Xcode, you must create a C++ Tool project. C++ Tool projects are used to write command-line programs without a GUI, which makes programming easier. You can read an article on the Xcode Tools Sensei page that contains detailed instructions on creating and building a C++ Tool project.
Writing C++ GUI Programs
After learning C++ you may want to use your newfound knowledge to write Mac OS X GUI programs. You have three options for writing Mac GUI applications in C++. First, you can use Cocoa, writing your user interface code in Objective C and the rest of your code in C++. You must give your Objective C files the extension .mm, which tells Xcode to treat them as Objective C++ files. Objective C++ lets you mix C++ and Objective C code in the same source file.
Second, you can use Carbon, which is Apple's C API for writing GUI applications. If you choose to use Carbon, you may want to look into Nano, an open-source C++ framework built on top of Carbon.
Third, you can use a C++ cross-platform GUI framework like Qt or wxWidgets. I haven't used either of these frameworks, but you should check them out if you are interested in supporting Linux and Windows as well as Mac OS X.
Wednesday, January 31, 2007
Monday, January 15, 2007
TextWrangler and Interpreted Languages
TextWrangler is a free text editor for Mac OS X. It also happens to be a nice development environment for interpreted languages, especially for Perl, Python, and Ruby programming.
TextWrangler's Advantage over Xcode for Interpreted Languages
Xcode is designed for compiled languages like C++ and Java, not interpreted languages like Python and Ruby. You can create an external build system project in Xcode, but it is not very useful for interpreted languages because there is nothing to build for interpreted languages. You have to run the Terminal application and launch your program from the command line using your language's interpreter.
TextWrangler's shebang (#!) menu allows you to run Unix scripts from TextWrangler so you don't have to launch Terminal. TextWrangler has built-in support for Perl, Python, and Ruby, which means you can run and debug Perl, Python, and Ruby programs from TextWrangler. You can use TextWrangler to run programs in other interpreted languages, but you can't debug them using TextWrangler's Run in Debugger menu item.
Creating and Running a Program with TextWrangler
Writing and running code in interpreted languages is easy in TextWrangler. The following steps show you how to write a simple Ruby program with TextWrangler:
If you are using another interpreted language, the first line of code must specify the path to the interpreter.
The #! sequence is the start of a Unix script.
Using TextWrangler with Xcode
Although you don't need Xcode for small projects if you use TextWrangler, Xcode has its place for larger projects. You would use Xcode for project organization and version control and use TextWrangler to write the code and run the program. The Xcode Tools Tips page has a tip on using external editors with Xcode.
TextWrangler's Advantage over Xcode for Interpreted Languages
Xcode is designed for compiled languages like C++ and Java, not interpreted languages like Python and Ruby. You can create an external build system project in Xcode, but it is not very useful for interpreted languages because there is nothing to build for interpreted languages. You have to run the Terminal application and launch your program from the command line using your language's interpreter.
TextWrangler's shebang (#!) menu allows you to run Unix scripts from TextWrangler so you don't have to launch Terminal. TextWrangler has built-in support for Perl, Python, and Ruby, which means you can run and debug Perl, Python, and Ruby programs from TextWrangler. You can use TextWrangler to run programs in other interpreted languages, but you can't debug them using TextWrangler's Run in Debugger menu item.
Creating and Running a Program with TextWrangler
Writing and running code in interpreted languages is easy in TextWrangler. The following steps show you how to write a simple Ruby program with TextWrangler:
- Choose File > New Text Document.
- At the bottom of the document window are three pop-up menus. The left menu should say (none). Choose Ruby from the left pop-up menu. This tells TextWrangler that you are writing a Ruby program, which turns on Ruby syntax highlighting and enables the Run in Debugger menu item.
- Write your code. For a Hello World program, enter puts "Hello World".
- Choose #! > Run to run the program.
If you are using another interpreted language, the first line of code must specify the path to the interpreter.
#!/path/to/interpreterThe #! sequence is the start of a Unix script.
Using TextWrangler with Xcode
Although you don't need Xcode for small projects if you use TextWrangler, Xcode has its place for larger projects. You would use Xcode for project organization and version control and use TextWrangler to write the code and run the program. The Xcode Tools Tips page has a tip on using external editors with Xcode.
Monday, January 8, 2007
ZeroLink
I read many posts on Mac programming message boards about problems that end up being caused by ZeroLink. Responding to these posts gets tiresome after a while so I decided to write about ZeroLink. In this post I explain what ZeroLink does, the problems it causes, and how you can turn it off so it doesn't cause you problems.
What ZeroLink Does
Before I explain what ZeroLink does, I should explain how Xcode normally builds C, C++, and Objective C projects. When you tell Xcode to build your project, the compiler compiles each source code file, creating an object file for each source code file. After compiling each file the linker links each object file along with the libraries and frameworks you're using to create an executable file you can run.
As its name suggests, Xcode skips the linking stage when you build with ZeroLink. When you run your program built with ZeroLink, Xcode links object files when your program needs them.
What is the advantage of using ZeroLink? It makes building your project go faster. If your project has many source code files, ZeroLink can speed build times significantly. During development you're going to build your project many times so faster build times save you time.
ZeroLink's Dark Side
ZeroLink's build time savings have a cost. The cost is you can get bizarre program behavior, and the cause of this behavior can be difficult to find. There are two common problems ZeroLink causes. First, because ZeroLink skips the linking stage, you won't find any linker errors when you build your project. The error appears when you run the program in Xcode, and your program crashes.
Second, your program won't launch when you move the executable or try to run it on another Mac. Projects built with ZeroLink can be run only inside Xcode. Because ZeroLink doesn't do any linking, the executable file is just a shell. When you move the executable file and try to launch it, nothing happens because there's no code inside the executable file. The code is in the object files that haven't been linked.
The Cause of Confusion
ZeroLink-related problems occur most often for people new to Xcode, and it's not their fault. When you create a new Xcode project, Xcode sets the project's active build configuration (the configuration it will use when you build the project) to the debug configuration. The debug configuration initially enables ZeroLink. What this means is if you create an Xcode project, add code to the project, and build the project, you're building with ZeroLink, whether you intended to or not.
Most Xcode beginners do not intend to use ZeroLink and have no need for it. Unless you have a large project, the problems ZeroLink causes surpass the time saved by not linking. While ZeroLink has its place, most developers are better off not using it, and Apple would be better off turning off ZeroLink initially.
Turning off ZeroLink
Because Apple enables ZeroLink initially, it is up to you to turn it off. If you're running Xcode 2.2 or later, the easiest way to turn off ZeroLink is to choose Build > Allow ZeroLink. Make sure there is no check mark next to the menu item. No check mark means ZeroLink is turned off. When you turn off ZeroLink using this method, you can't use ZeroLink for any project. If you decide you want to use ZeroLink in the future, choose Build > Allow ZeroLink to give yourself the capability of turning ZeroLink on or off on a project by project basis.
If you're running an earlier version of Xcode, you must turn off the ZeroLink build setting for each project. The ZeroLink build setting is in the Linking build settings collection.
What ZeroLink Does
Before I explain what ZeroLink does, I should explain how Xcode normally builds C, C++, and Objective C projects. When you tell Xcode to build your project, the compiler compiles each source code file, creating an object file for each source code file. After compiling each file the linker links each object file along with the libraries and frameworks you're using to create an executable file you can run.
As its name suggests, Xcode skips the linking stage when you build with ZeroLink. When you run your program built with ZeroLink, Xcode links object files when your program needs them.
What is the advantage of using ZeroLink? It makes building your project go faster. If your project has many source code files, ZeroLink can speed build times significantly. During development you're going to build your project many times so faster build times save you time.
ZeroLink's Dark Side
ZeroLink's build time savings have a cost. The cost is you can get bizarre program behavior, and the cause of this behavior can be difficult to find. There are two common problems ZeroLink causes. First, because ZeroLink skips the linking stage, you won't find any linker errors when you build your project. The error appears when you run the program in Xcode, and your program crashes.
Second, your program won't launch when you move the executable or try to run it on another Mac. Projects built with ZeroLink can be run only inside Xcode. Because ZeroLink doesn't do any linking, the executable file is just a shell. When you move the executable file and try to launch it, nothing happens because there's no code inside the executable file. The code is in the object files that haven't been linked.
The Cause of Confusion
ZeroLink-related problems occur most often for people new to Xcode, and it's not their fault. When you create a new Xcode project, Xcode sets the project's active build configuration (the configuration it will use when you build the project) to the debug configuration. The debug configuration initially enables ZeroLink. What this means is if you create an Xcode project, add code to the project, and build the project, you're building with ZeroLink, whether you intended to or not.
Most Xcode beginners do not intend to use ZeroLink and have no need for it. Unless you have a large project, the problems ZeroLink causes surpass the time saved by not linking. While ZeroLink has its place, most developers are better off not using it, and Apple would be better off turning off ZeroLink initially.
Turning off ZeroLink
Because Apple enables ZeroLink initially, it is up to you to turn it off. If you're running Xcode 2.2 or later, the easiest way to turn off ZeroLink is to choose Build > Allow ZeroLink. Make sure there is no check mark next to the menu item. No check mark means ZeroLink is turned off. When you turn off ZeroLink using this method, you can't use ZeroLink for any project. If you decide you want to use ZeroLink in the future, choose Build > Allow ZeroLink to give yourself the capability of turning ZeroLink on or off on a project by project basis.
If you're running an earlier version of Xcode, you must turn off the ZeroLink build setting for each project. The ZeroLink build setting is in the Linking build settings collection.
Wednesday, January 3, 2007
Linking External Libraries and Frameworks in Xcode
As long as you stick with the Apple-supplied frameworks that reside in System/Library/Frameworks (Cocoa, Carbon, OpenGL, QuickTime, etc.), linking in Xcode is pretty simple. Add the framework to your project, and you're done.
Things get a little more complicated when you want to use other libraries and frameworks in your code. If you're new to Xcode, you may get a ton of undefined symbol linker errors when you build your project, with the undefined symbols being in the the libraries and frameworks you want to use. These errors mean the linker can't find the symbols. How can you eliminate these errors?
Add the Libraries and Frameworks to Your Project
It sounds obvious, but make sure you have added the external libraries and frameworks to your project. If you don't add them, your project will not link.
Add Search Paths
If you have added the libraries and frameworks to your project and you still get undefined symbol errors, the most likely cause is the linker can't find the libraries and frameworks. What you need to do is add search paths for the libraries and frameworks you're using.
Xcode has a Search Paths build settings collection. This collection lets you add search paths for libraries, frameworks, and header files. To add a search path, select the appropriate build setting and click the Edit button. A sheet will open. Click the + button in the sheet to add a search path, and click the OK button when you're done.
Linker Flags
Adding search paths eliminates most linker errors, but when it fails, you can add linker flags to the project. To add linker flags go to the Linking build settings collection. The Other Linker Flags build setting lets you manually add flags the linker will use when building your project.
If you still get linker errors, you're in for a long, frustrating search for a solution.
Things get a little more complicated when you want to use other libraries and frameworks in your code. If you're new to Xcode, you may get a ton of undefined symbol linker errors when you build your project, with the undefined symbols being in the the libraries and frameworks you want to use. These errors mean the linker can't find the symbols. How can you eliminate these errors?
Add the Libraries and Frameworks to Your Project
It sounds obvious, but make sure you have added the external libraries and frameworks to your project. If you don't add them, your project will not link.
Add Search Paths
If you have added the libraries and frameworks to your project and you still get undefined symbol errors, the most likely cause is the linker can't find the libraries and frameworks. What you need to do is add search paths for the libraries and frameworks you're using.
Xcode has a Search Paths build settings collection. This collection lets you add search paths for libraries, frameworks, and header files. To add a search path, select the appropriate build setting and click the Edit button. A sheet will open. Click the + button in the sheet to add a search path, and click the OK button when you're done.
Linker Flags
Adding search paths eliminates most linker errors, but when it fails, you can add linker flags to the project. To add linker flags go to the Linking build settings collection. The Other Linker Flags build setting lets you manually add flags the linker will use when building your project.
If you still get linker errors, you're in for a long, frustrating search for a solution.
Tuesday, January 2, 2007
Updated Tip on Changing the Compiler
I updated the tip on the Xcode Tools Tips page that deals with changing the compiler Xcode uses to build your project. The updated tip tells you to add the build settings GCC_VERSION_ppc and GCC_VERSION_i386 instead of changing rules for the target. There currently is no need for the GCC_VERSION_i386 setting because Xcode projects use gcc 4 as the default compiler and you can't build for Intel with anything earlier than gcc 4. But the setting will come in handy in the future when Xcode ships with a newer version of gcc.
There was nothing technically wrong with having a target rule that specified the compiler to use, but it was overkill when all you want to do is compile with an earlier version of gcc. Adding the GCC_VERSION_ppc build setting is more straightforward.
There was nothing technically wrong with having a target rule that specified the compiler to use, but it was overkill when all you want to do is compile with an earlier version of gcc. Adding the GCC_VERSION_ppc build setting is more straightforward.
Subscribe to:
Posts (Atom)