debugging C++ in XCode

I've been frustrated by how XCode's debugger seems to be easily confused by C++. Also generally annoyed that it's hard to view the contents of an array by unfolding arrows. Things are moving along much more nicely now that I've started paying more attention to the command-line interface to GDB, the debugging tool beneath xcode's debugger gui.

For example, when trying to inspect a variable, I was getting this error: "current stack frame does not contain a variable named `self'. The problem was that GDB thought it was looking at ojective-c when in fact it was C++. The fix was to manually tell GDB via the console that it's looking at C++.

set language c++

The GDB command line interface is also really nice for examining buffers. When working with audio, you get deal with huge sets of data, tens of thousands of samples. There's no obvious way to examine that data via the debugger ui. Even harder, what if you want to examine a small chunk of it somewhere in the middle. With the GDB console, I can type this:

(gdb) x/64f sample.data_ + sampleReadPosition

Where sample.data_ is my audio data and sampleReadPosition is where I want to start looking. A few more things about this command: x is the main command which inspects data. /64 means repeat 64 times, and format as a float. So this command says: look at the memory pointed to by sample.data, jump forward by sampleReadPosition step, and format it as a float.

Here's the output.

0xbd9b458: 0.0132450331 0.0792260543 0.0219122898 0.0856349394

0xbd9b468: 0.0309457686 0.0916776061 0.0396130271 0.0969878212

0xbd9b478: 0.0487075411 0.101870783 0.0573747978 0.106387526

0xbd9b488: 0.0656758323 0.110171817 0.0739768669 0.113162637

0xbd9b498: 0.0818506405 0.115421005 0.0890530124 0.116946928

0xbd9b4a8: 0.0958281234 0.117313154 0.102237009 0.117313154

0xbd9b4b8: 0.107913449 0.116214484 0.112796411 0.114322335

0xbd9b4c8: 0.116946928 0.111270487 0.119998783 0.107547231

0xbd9b4d8: 0.122623369 0.102969453 0.1241493 0.0977202654

0xbd9b4e8: 0.124515519 0.0916776061 0.1241493 0.0845362693

0xbd9b4f8: 0.122989595 0.076967679 0.120731227 0.0686666444

0xbd9b508: 0.117313154 0.0596331693 0.11358989 0.0505386516

0xbd9b518: 0.108279675 0.0404065065 0.102603227 0.0302133244

0xbd9b528: 0.0961943418 0.0200201422 0.0886867866 0.00909451582

0xbd9b538: 0.0807519779 -0.00146488845 0.0724509433 -0.0124515519

0xbd9b548: 0.0634174645 -0.0230109561 0.0539567247 -0.0335703604

The GDB manual is here.

If you find yourself working outside the cocoa frameworks (and perhaps even if you don't), I highly recommend digging in to GDB.

LibPD with Thicket

Developing music software for iOS has been a thrill and a terrific frustration. I've been looking for weeks for an audio engine which could manage signal chains efficiently for me, has a license which won't force me to open-source my software, and can be configured in a c-flavor language. I've come up with basically nothing. My only option (and I'm very grateful for this option) seems to be libpd -- an embeddable version of pure data. This is great, except for the fact that PD designed as a graphical programming language, and to someone like me accustomed to writing code, strikes me as bizarre, wrong, difficult, painful. But I'm going to stick it out for a while and see if PD's beauty decides to present itself to me.

I'm not confident about my ability to write an efficient audio engine, but I am very confident about my ability to use code to express artistic and structural concepts. So I'll be using PD only for signal chain, keeping absolutely as much application logic as possible in code. This brings me to the question of which language to use. Of course, the iPHone's native language is objective-c. But I'm liking C++ a lot more. The syntax is simpler. And it allows me to write all of my code in the header files if I feel like it. I know this is considered bad form, but sometimes I like to take off my engineer's hat and put my artist hat on. With my artist hat, I'm allowed to look at a technique, and say "too slow, too many keystrokes". And that's how I'm feeling about Objective-C vs C++. So I'm tending to thing that for audio logic, C++ is the way to go.

Mixing languages on the iPhone is a pain in the ass. You can mix Objective-C and C++, but you have to jump through hoops in order to avoid compiling your entire application as Objective-C++. That can be necessary if you want to mix C and Objective-C in other parts of the application. I'm currently getting an inexplicable linker error in XCode: "libpd_bang(char const*)", referenced from:". This is maddening, especially to a relative newb. The complier doesn't complain, but the linker fails. I've come across a similar problem before, but I don't remember what the solution was. I'll post back here if I figure it out.

EDIT

I fount my previous linker error. It's described here:

http://stackoverflow.com/questions/4812183/xcode-is-not-even-trying-to-compile-some-of-my-mm-files-then-fails-while-link

This one is not the same however. The previous problem was that the file wasn't even being compile, because it wasn't added to the target. In this case, the file is being compiled. The function in error is even being called successfully from PDBase.m, but it's not being called successfully from other files.

EDIT

Ok. I think I've solved it. Using the "extern c" as recommended here helped:

http://iptrk.ionismus.de/post/94485387/mixing-ansi-c-and-c-in-a-xcode-3-x-project

EDIT

PD's patching graphical interface was driving me crazy. I've decided to to just become a better programmer and stick to low-level stuff. It's not that much more work in the end, and I get to keep my hands on the keys, rather than reaching for the mouse.