Objective C++ and file extensions (.m, .mm, .cpp)

If you've ever wondered how to combine C++ and C in your Cocoa code for iPhone or Mac, it is as simple as renaming your files to have a .mm extension, rather than the default .m extension.

It is a shame that Apple don't enable this file extension by default in their code building wizards. It certainly makes the transition to Objective C for C++ programmers a lot easier!

Anyways, for those of you interested in porting your C++ code across to iPhone and Cocoa, without having to rename your files or create lots of .mm file wrappers; I discovered under Linux that -x objective-c++ can be used to tell the compiler to treat the file as an objective c++ file; irrespective of the file extension... as follows (wbere test.cpp actually contains Objective-C++ syntax, and would normally be called test.mm ...):


gcc-4 -x objective-c++ test.cpp -lgcc -lobjc -o a.exe -lc -lstdc++


There are two ways to use this in XCode:
- on file-by-file basis, right-click on any .cpp file in which you want to put some Objective-C and/or C++, and select Get Info. In the Build tab, set -x objective-c++ in the Additional Compiler Flags field.
- alternatively, for the entire project, in Project Settings under Build, under GCC 4.0 - Language, set Compile Sources As to Objective-C++.

As always; this is easy when you know how...!

Pete

CFSocketCreate on iPhone

If you're doing sockets programming on your iPhone (like I'm doing for Mixtikl's file sharing server code), don't panic when your call to CFSocketCreate fails to create an IPv6 TCP socket when passing PF_INET6.

Just accept the IPv4 socket that you will get when passing-in PF_INET, and all will be fine... :)

MacVim and XCode

XCode no longer automatically launches MacVim to edit my files. However, this actually forced me to find what I think is a better solution. :)

All you need to do is open-up MacVim and XCode; and drag any files you want to edit from the XCode project window file list, on to MacVim. The file you drag-across opens automatically in a new tab for editing under MacVim. Really easy!

Even more easily: if you are editing a file in XCode, and don't want the hassle of first searching for it in the project file list in order to drag it to XCode; simply right-click on the XCode editor window, select the option to Reveal in Finder, and then right-click on the file in the Finder window and select the option to edit with Vim.app ...

CGContextSelectFont - slow slow slow...

Wow, that was a shock. There I was profiling Mixtikl on the iPhone after tuning various things, and what do I find? CGContextSelectFont is hogging 30% of the CPU cycles!

This is nothing new apparently (see http://www.manton.org/2005/12/cgcontextselectfont.html - which dates from 2005!). Thanks Apple. :-(

The solution was this:
- when you grab a CGContextRef from UIView (or for example when I create my own singleton temporary one I use for off-line calculation of text display areas...), set the font just once on that CGContextRef by calling CGContextSelectFont with a temporary font size of e.g. 10; do this before you do any text drawing operations with the CGContextRef...!
- Whenever you need to draw text, call CGContextSetFontSize before you call CGContextShowText (or whatever...); do not call CGContextSelectFont as there is no need to set the font by name and size in most cases, just the font size. Calls to CGContextSetFontSize hardly take any time at all ... and your performance problems will disappear.

That makes a huge difference to performance, and is easy to do when you know how. :)

Tweaking Mixtikl on the iPhone

While Tim is fiddling-away with the new iPhone skin (there's no point in rushing him, he only ignores me anyways ... just joking Tim!), I've been spending my time tweaking the UI responsiveness of Mixtikl on the iPhone, and fixing some odd bugs left-over from the porting process.

User interface latency is really fabulous ... so much better than Windows Mobile.

Our pluggable font engine has paid dividends yet again, the effort to move text display across to iPhone was only the matter of a few hours work, as is usual for our trans-platform graphics architecture. It sometimes amazes me when things like this work so quickly, but I guess I shouldn't be surprised any more. :)

I have few other bits-and-bobs to sort out, but things are looking and sounding very good indeed...

Missing symbol with mangled name when loading a library under Linux? How to track it down.

Suffering from a missing with a mangled name when loading a library under Linux? Here is how you can track down what is missing.

I had a library failing to load...

The error output reported a "symbol lookup error" for a mangled name like _Zkasdfkadf83 ... which didn't help me much. :)

To figure-out what this is:


cd [the folder with your libraries in]
grep Zkasdfkadf83 *.so


... This tells you the library that the symbol is referred to from.
Assume this is fred.so

Then, do this. Note: the first version shows you the mangled names, the second version shows you the UNMANGLED (i.e. human readable) names... Other than that, they are identical.


nm -B fred.so > sym.mangled
nm -C fred.so > sym.unmangled


Edit both files.
Look for the missing symbol in the first file, make note of the line number.
Go to that line in the second file. That shows you the unmangled-name corresponding to the mangled name. It should now be crystal-clear what the missing symbol is!

HTH

Pete

The power of Vim

I don't often post on tools, but I thought I'd make a mention for some fabulous new software I discovered and installed today:
- ViEmu: a Vim editor plug-in for Microsoft Visual Studio, which integrates really well within Visual Studio and is a bargain IMO ... http://www.viemu.com/index.html
- MacVim ... http://code.google.com/p/macvim/ - a wonderful version of Vim for Mac, which works quite well with XCode. And it is free!

I've been a power Vim user for many years now, having first started using vi around 20 years or so back. The key for me is that whatever programming work I have done, on every single platform (apart from VMS - shudder!) I've been able to use one vi variant or other as an ultra-productive editor.

vi and Vim have been staples of mine on Windows for ages, mainly in the context of cygwin on Windows. I've been using gvim for Windows for a long time now, and it works quite well with Visual Studio; but the ViEmu/VS is such a great integrated solution that I simply wish I'd heard about it years ago - I hate to think how many hours of programming time it would have saved me. :)

On MacOS X, I naturally use vim from the terminal window (this has been built-in to all Macs for ages). But MacVim is a great implementation, and hooks-in an awful lot better to XCode. Again, I wish that I'd installed it a long time back. It is going to save me a huge amount of time going forward.

I should note that while there are some good points about both the editors in XCode and Visual Studio, they are both staggeringly less productive to use for every day editing than Vim. When you consider the amount of cross-platform coding I do, I simply can't afford to specialise in either of these two editors. I need one common editing paradigm that rocks for all platforms. So for me, great implementations of Vim on Windows and Mac, that integrate well with Visual Studio and XCode respectively, are tremendously important.

I also spent some time today learning about some features of Vim that I simply didn't know about, that are going to transform my editing life. Visual selection modes, anybody? :)

Finally, if you're a serious programmer and haven't tried Vim - go for it. Take the pain of 2 weeks learning curve, get touch-typing and begin to feel the force. :) Vim is free, and you can get it from http://www.vim.org/ for most platforms, or within Cygwin for Windows. It is also built-in to MacOS X and Linux.

Mixtikl on iPhone - dealing with chubby fingers

We're taking our time to get the iPhone version of Mixtikl "just right".

After playing around with Mixtikl on a real device, it became obvious that the general inaccuracy that you get with touch-only devices using chubby fingers :) meant that the Mixtikl skin needed to be "chunkier". This is as opposed to pointer-controllable devices like most Windows Mobile PDAs, where you can have a UI that supports smaller elements that can be selected accurately with a pointer device.

We've come up with a nice solution to this problem, and in the interim have been extending the underlying .partikl file format to take better advantage of local sample files (in Ogg and DLS format) used in the Tiklpaks. All will become clear when we release the next version of Mixtikl!

These changes are combined with other user-interface tweaks, which we think make a great deal of difference to the usability of Mixtikl across all our platforms.

We can't wait to release this new version ... but won't rush it. :)

Pete