Apple released the December 2002 Developer tools update today, available for download for ADC Members. Among the list of updates is Project Builder 2.1 with “better CVS support”.
OS X December 2002 Developer Tools
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’m no fan of the Mac platform, but I have to admit that OSX has piqued my curiosity. Doesn’t 10.2 support the 3.1 GCC compiler?
Can C++ apps be compiled to run in OSX native apps? Or do they still require some cocoa wrappers?
I’m thinking of buying a Mac simply because it would be nice to have BSD and Photoshop on a single desktop! hm……
El Charrito,
well, once you’ve installed the Developer Tools, you’ve got GCC 3.1 and 2.95.
The –version String says ‘gcc (GCC) 3.1 20020420 (prerelease)
Hm, well that was before the Developer Tools Update.
Don’t know what you mean with ‘C++’ apps and the Cocoa wrapper. I build a lot OS software right from the Internet just by doing ./configure; make all; make install and all is fine. Some of them are C++ (I seem to remember that some parts of GnuPG were).
That almost everytime works fine. Terminal-based stuff always does.
Imagine running the GIMP and Photoshop on the same machine 8^)
– Thomas
“Imagine running the GIMP and Photoshop on the same machine 8^)”
There’s a Windows port of both…
Does anyone know if the Mac Dev tools support code completion yet (ms: IntelliSense)? This is one feature that i really like that I can’t seem to get working.
Daniel
CodeWarrior does…
Apple is using GCC 3.1; 3.1 and 3.2 are the same compiler… The only difference is that 3.2 changed ABI’s for the x86 systems; thus the version change.
Object C is only required for writting native GUI programs. COCOA is an Object C API. If you just want command line or your using the X11 system, you can just use C or C++.
While Carbon apps don’t get quite as much for free as Cocoa apps, they are fully ntive to Mac OS X, so yes, you can write very nice graphical applications for Mac OS X in C++, and compile them using ProjectBuilder.
If you’re new to Mac programming, you’re probably better off starting with Cocoa and Objective-C. Cocoa apps tend to feel more polished than their Carbon counterparts, due to the fact that the interface gains more goodies(like threading) for free.
The other option is to write Cocoa apps in Java, if Java’s your “thing”.
Object C is a very bad choice I think. Apple acts like they have the market dominance. There are so many C++ developers out there. I wish I can write C++ GUI applications for the Mac OS X, but Apple just makes my task harder.
Use the Carbon API – it’s C/C++.
Ralf.
Object C is a very bad choice I think
Well I’d like to heard a bit more detailed comment about that, apart from saying “bouhouhou another language”. In fact Objective C (not Object C) is a really cool language, EXTREMELY easy to learn and VERY powerful. Definitively a good language for GUI (dynamic binding, InterfaceBuilder, etc.).
I really can’t understand developers whining about learning another language.. sure it could be annoying, but as developers we ALLWAYS learn new languages, the big thing is to understand the basis of the programmation (procedural, OO, functional, etc.), the rest isn’t so dramatic (and long) to learn.
And in the case of Objective C, it IS a good language, worth the effort of learning it. And if you have some existing tools/program written in another language, just use Objective C for the GUI part, it’s not a big deal as you can mix Objective C, C and C++ , and as the developers tools (InterfaceBuilder mainly) will dramaticaly reduce the time spent for the GUI.
… I could add that the big time consumer thing with Mac OS X isn’t Objective C, it is the framework (Cocoa). Objective C is a matter of hours for a C++ programmer (or anyone with a clue on Object Oriented programming).
The frameworks are way more time consuming to learn (but they are so great that it’s too worth the effort — after learning them, applications are programmed really fast.)
InterfaceBuilder and ProjectBuilder will write quite a bit of the Objective-C code for you.
Here is the problem nico. You can come up with the best language in the world, but to make the language accepted among the developers there are many practical problems you have to tackle.
Developers do not stay in one platform. They move from job to job. With the current situation you have to target Mac OS X to invest your time to learn Objective C.
Learning new languages sound easy and usually it is easy, but there is a barier.
Also learning a language is one thing, using it as efficiently as you use the language that you already know is a different thing. This is the real reason why it is a bad choice. There are people who already know C++, C very well. Why use something that is not known.
As far as I know Objective C doesn’t offer something significantly better than the existing solutions. So why reinvent the wheel.
1) All GUI application frameworks are different on different platfroms. Linux has primarily GNOME and KDE, Windows has .NET, MFC, and Win32, MacOS X has Cocoa, Carbon, and Applescript Studio. So developers writing apps for multiple platforms have to deal with these differences, typically the choice is made to try and abstract as much of the application’s functionality away from the platform dependent GUI toolkits so that the program can have two main code trees, on that is the core cross-plaform code, and another that is the platform dependent code.
2) To target MacOS X you don’t have to learn ObjC. GUI apps can be built using MANY languages on MacOS X. Supported by Apple are, C++ (through Carbon), Java (through Cocoa), ObjC (through Cocoa), and Applescript (through Cocoa). In addition to that there are 3rd party methods being worked on and some available to make Cocoa accessable from other languages like Python, etc. And again as I said before all that this effects is the platform specific GUI code of an application.
3) Learning new languages of the same caste should be pretty trivial. In 2 hours I had to learn PHP for a part of a project at my new job. Did I want to learn PHP? No. Do I ever intend to use PHP in my own non-work related endevours? No. Was it foreign and a little odd? Yes. Was it hard to learn? No. The problem a lot of C developers have with ObjC, Java, Smalltalk, C#, etc. has more to do with a fundamental barrier to understanding Object Oriented programming than it does with a barrier to learning a new language.
4) Sure lots of people know C and C++, the problem is that those languages don’t offer enough support for certian feaures of dynamicism and flexibility to be able to access a framework like Cocoa.
5) Well it is VERY evident that you don’t really know that much about ObjC, and perhaps the “existing solutions”. With the lone exception of Smalltalk, and perhaps Ada, ObjC is still one of the only fully object oriented languages available for use in mainstream commercial application.
C++ is not an OO language, and the fact that it’s been perpetuated as such is a bit troublesome to me. C++ is C with some looser restrictions on code formating, a form of inheritence, and some data-hiding.
“I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.”
— Alan Kay
“C++ : an octopus made by nailing extra legs onto a dog”
This is the real reason why it is a bad choice. There are people who already know C++, C very well. Why use something that is not known.
Objective C is a superset of C, like C++ … it’s not really difficult to understand, there is only ONE syntax addition. And as I said, the language is very simple, so you quickly are as efficient as in C++ for example (it’s far more simple to understand than C++).
Basically, it’s a Object Oriented C, but with the SmallTalk approach rather than the Simula approach (C++). What people doesn’t really understand is that it will take long time to masterize a ToolKit, but understanding a new language is not a big deal; and this is the case with Cocoa : what’s long is to learn Cocoa, not Objective C (it’s matters of hours, if not less, seriously (if you know C and OOP)).
As far as I know Objective C doesn’t offer something significantly better than the existing solutions. So why reinvent the wheel.
Ah ok. Well this is where you’re wrong. Objective C is dynamic at runtime, and so quite different of others solutions. For GUI applications, dynamism is really a useful thing. Take for example Qt (C++), they simulated the dynamism with a preprocessor (moc) (that explain for a big part why Qt is a good GUI library in fact, because with dynamism you’re able to do things cleaner).
In Objective C, everything is dynamic, and it’s far, far more powerful.
I’m not sure Objective C is the best language out there, but I believe in “one tool for one work”, and for me, Objective C, elegant, simple but powerful, is the best language for building GUI application along with an OpenStep implementation. But for other works, others language are better (C++ could be a great choice for a backend for example).
I’ve read through a couple of books on Objective-C, including the book published by Apple, and I still can’t figure out what the appeal is. It’s called C, but doesn’t use the same memory management model, and I can’t create stack based objects. While I did learn that it isn’t necessary to name your parameters, those square brackets make a single line of code hard to interpret. What is the consequence of making a null-pointer reference, or passing a message to an object that can’t handle it? Can you enforce encapsulation with access modifiers? Questions like this made me wonder what the of Objective-C was.