macOS advice for c++ programmer

[cmaier]

I'm about to buy my first Mac (well, the first that I intend to actually use. Long story), specifically to write code for it. I was an x86 microprocessor designer for a lot of years, and as part of that I became a proficient c++ coder (as well as C, assembly, etc.) and have written probably a million lines of the stuff, mostly for unix and linux.

I read a couple of o'reilly books on objective C and introductory cocoa, and I think I appreciate many of the differences between c++ and objective-c at this point, but I was wondering if any other long time c++ coders had made the switch and had any advice to offer. Pitfalls, things they learned the hard way, etc.

 

[Krevnik]

I read a couple of o'reilly books on objective C and introductory cocoa, and I think I appreciate many of the differences between c++ and objective-c at this point, but I was wondering if any other long time c++ coders had made the switch and had any advice to offer. Pitfalls, things they learned the hard way, etc.

Things I have learned the hard way:

• Learn to both trust and mistrust the framework. Trust it, as it will make your work go a /lot/ smoother. Mistrust it, because it will pop up inconvenient bugs when you least need it.
• Retain/Release feels more hackish than it really is. Get in the mindset of managing memory at the object level, and you will find your code a lot easier to audit for memory issues than C++.
• You /can/ go from a rapid prototype to a polished product with the same code base... (I have to remind myself to not get lax with coding styles on prototypes, since you never know when it will become a shipping product)
• Objective-C++ is the devil in disguise, mixing C++ objects with Obj-C objects is a road to confusion and unauditable code (I tried it once).
• Cross-platform development using Objective-C as the Mac UI layer is possible once you understand the rules.

 

[Soulstorm]

I agree with Krevnik as far as OBJC++ is concerned, but sometimes, there is no other way. An experienced programmer can overcome many difficulties on that matter. However, using OBJC++ is discouraged. Avoid when possible.

Objective C can never replace C++ or vise-versa. In terms of car manufacturing, C++ would be user for the engine compartment, where Objective C would be used for the interior of the car and the general behavior. The faster you understand the differences, the better.

Memory management can be a pain in the butt at first. Keep in mind that the general concept is borrowed from C++'s new and delete operators. A good understanding of pointers in C/C++ and memory management using those, will give you a better idea on how to handle ObjC objects, since all of them are created using pointers. Also note that Cocoa applications use autorelease pools so that you don't need to use them yourself, except in rare cases. That is not the case with Foundation Tools, where you will need to create your own pool and release it.

Be careful on the returned values and the warnings produced by the compiler. A warning in ObjC is equal to an error in C++. C++ is much more static, meaning that errors can easily be identified. ObjC is dynamically typed, and those errors are interpreted as warnings, but they will almost always produce a runtime error. You will find that the debugger will shortly become your best friend, and that Xcode, contrary to C++, will most of the times report the exact cause of the runtime error, before the debugger pops up.

The key to success for Cocoa is to learn the notions of KVC (key-value-coding) and learn how to use NSDictionaries and their mutable counterparts. This will introduce you to Cocoa bindings, and Core Data.

 

[Krevnik]

Memory management can be a pain in the butt at first. Keep in mind that the general concept is borrowed from C++'s new and delete operators. A good understanding of pointers in C/C++ and memory management using those, will give you a better idea on how to handle ObjC objects, since all of them are created using pointers.

I disagree with this comment a bit. Yes, they both use pointers, but ref-counting is much different than new/delete and malloc/free, and needs to be approached with a different mindset, or you get to have fun auditing for memory leaks later.

Be careful on the returned values and the warnings produced by the compiler. A warning in ObjC is equal to an error in C++. C++ is much more static, meaning that errors can easily be identified. ObjC is dynamically typed, and those errors are interpreted as warnings, but they will almost always produce a runtime error. You will find that the debugger will shortly become your best friend, and that Xcode, contrary to C++, will most of the times report the exact cause of the runtime error, before the debugger pops up.

This is a /good/ one. Code with warnings is usually bad code, and never 'patch' warnings with the standard C/C++ fixes, as that usually just masks the warning rather than actually fixes behavior.

 

[kainjow]

Objective-C++ is the devil in disguise, mixing C++ objects with Obj-C objects is a road to confusion and unauditable code (I tried it once).

I agree with Krevnik as far as OBJC++ is concerned, but sometimes, there is no other way. An experienced programmer can overcome many difficulties on that matter. However, using OBJC++ is discouraged. Avoid when possible.

Have you guys had bad experiences with Objective-C++?

I've used it in several projects, from a cross-platform OpenGL tetris clone to an Adium plugin to a physics-based interactive flowchart.

I've had zero problems with it, and actually love how well the languages are integrated.

 

[Catfish_Man]

Have you guys had bad experiences with Objective-C++?

I've used it in several projects, from a cross-platform OpenGL tetris clone to an Adium plugin to a physics-based interactive flowchart.

I've had zero problems with it, and actually love how well the languages are integrated.

The main issue I've seen is the incompatible exception models. Throwing C++ exceptions across ObjC code, or vice versa, is a Bad Idea® (for now...).

 

[Columbo X]

I've been oscillating between C++ and Objective-C over the past 6 years with various projects. Objective-C is based around some great concepts which I've borrowed and built into my C++ code (for example a common base class like NSObject with retain/release - so my C++ object management looks very much like Objective-C). This makes using the languages together in Objective-C++ easier. I do stick to the Objective-C rule that all objects are referenced types. This helps decouple the C++ but allows me to use C++-specific features like templates where necessary while allowing me to maintain more portable code.

The biggest issues I've had are with the Cocoa library itself - knowing when objects are autoreleased or not and making sure my code adheres to the conventions. In C++ I override malloc/free/new/delete to track memory allocations / deallocations but this can't so easily be done with the types in the Cocoa frameworks - roll on Objective-C 2.0!!

 

[lazydog]

Hi
For what it's worth here are my thoughts:-

I really like the ability to use Objective-C and C++ in the same project. I think this is different though from writing in Objective-C++ as a language in itself. What I mean by this is I don't attempt anything really difficult in Objective-C++. I keep the C++ parts of the project pure C++ and use Objective-C++ to bridge the gap between interface and backend. I guess this is different from using Objective-C++ throughout a project and leveraging as much as you can from the mix of the two languages.

b e n

 

[cmaier]

What are the major new things coming in Objective C 2.0 that I might want to watch out for? (What little familiarity I have gained with objective C is 1.x). I figure that when I start actually coding, I might as well go 2.0 since it's all new to me anyway.

For me, the main struggle has been syntax; the concepts are all concepts I've seen before, but all those []'s and @'s felt very alien until I started reading lots of code and translating it in my mind to C++ style.

One of you mentioned you stick to c++ for the hard bits of code; any reason for that? Do you rely heavily on templates or something? (While I used the STL extensively, and boost somewhat, I tended to avoid creating my own template stuff as I found that I would run into problems as we moved from gcc 2.9x to 3.x to 4.x, 32 bit to 64 bit, or linux to solaris, etc., and my code had to be cross-platform and run on lots of setups.) It looks to me like almost anything I can do with a class I can do in objective-C as well?

As far as the memory management stuff is concerned, I think I have that under control; between Palm programming and my own C++ code (where i often implemented reference counting, pooled allocation, and garbage collection), I think I'll get the hang of it (other than having to figure out when code I didn't write has incremented or decremented the refcounts).

KVC question: if I understand this correctly, it's like accessing a class member by its name (by string)? Sort of like pulling the value out of a symbol hash? The books I've read have indicated it's very important in Mac programming, but I'm not seeing why.

 

[kainjow]

What are the major new things coming in Objective C 2.0 that I might want to watch out for? (What little familiarity I have gained with objective C is 1.x). I figure that when I start actually coding, I might as well go 2.0 since it's all new to me anyway.

The main new features are garbage collection and properties, which will make writing accessors a lot easier.

 

[cmaier]

The main new features are garbage collection and properties, which will make writing accessors a lot easier.

From a purist perspective I find properties a little odd. If I understand it correctly, you access them with "." which is getting back to looking very C/C++'ish. I think I will avoid them; my experience in C++ has been whenever I allow direct access to a member variable (either by making it public or by providing an access function that just returns it by reference), I always end up wanting to replace it by a real access function that I can use to do other work (like keep track of who set the variable, etc.)

I'm all for garbage collection, however

 

[kainjow]

From a purist perspective I find properties a little odd. If I understand it correctly, you access them with "." which is getting back to looking very C/C++'ish. I think I will avoid them; my experience in C++ has been whenever I allow direct access to a member variable (either by making it public or by providing an access function that just returns it by reference), I always end up wanting to replace it by a real access function that I can use to do other work (like keep track of who set the variable, etc.)

I don't think I can go into specifics, but let me just say you'll be able to do what you want with properties. Once Leopard ships we can talk more

 

[cmaier]

I don't think I can go into specifics, but let me just say you'll be able to do what you want with properties. Once Leopard ships we can talk more

Ooo. Enigmatic Well, now I just have to decide which piece of software I'm going to write first.

I like the fast iterator stuff. I'm used to STL-style iterators, but I prefer the perl-style foreach stuff that 2.0 seems to add.

This should be fun

One quick question on xcode (or whatever the development environment is called). How easy is it to use a different text editor? I'm a vim addict - any attempt I've made over the past decade to use anything other than a vi-alike has resulted in disaster. On windows, i've found that IDE's generally either allow me to embed vim or to use an external vim window and whenever I save the file and switch back to the ide it detects that the file changed and updates it within the ide.