typedef signed char        BOOL;

From this it is clear that BOOL is actually a signed char type. This has some implications when it comes to using the YES and NO values that are typically assigned to variables of "type" BOOL. If we look a little further down objc.h you will see the following:

1
2

#define YES             (BOOL)1
#define NO              (BOOL)0

So what is the problem with BOOL and YES? In a nutshell, the problem is that variables of type BOOL can contain values other than YES and NO. Comparing for NO is not an issue since NO == 0 == NO, but comparing for YES can be tricky, especially if you are relying on 3rd party code to play by the rules. Consider this:

1
2
3
4
5
6
7

BOOL b = 37;
if (b) {
    printf("b is YES!\n");
}
if (b != YES) {
    printf("b is not YES!\n");
}

The output from this would be as follows:

1
2

b is YES!
b is not YES!

The problem arises because direct comparison with YES will fail when the value of a BOOL type is a non-zero value other than 1.

Note that ObjC (assuming the default C99 setting is enabled) also supports the bool data type, which is an intrinsic boolean type and can only be set to true or false. A safe way to convert between BOOL and bool is as follows:

1
2
3
4

// from BOOL to bool
bool b = myBOOL ? true : false;
// and back
myBOOL = b ? YES : NO;

The moral of the story is to avoid direct comparisons between BOOL types and the YES constant.

There are two main elements of RTTI in C++, namely type identification, and type casting.

1. Type identification. The C++ keyword typeid is an operator used to obtain information about the run time type of an object. It is used as follows:

1
2
3
4
5
6
7
8
9
10
11
12

// typeid only works on polymorphic classes,
// that is, classes with at least one virtual method
 
class PolymorphicClass
{
public:
virtual void virtualMethod()
{
}
} polymorphicObject;
 
const std::type_info &info = typeid (polymorphicObject);

In this case, std::type_info is a type that will receive the RTTI information about our polymorphicObject – we’ll actually get a reference to a std::type_info back from the typeid operator. The std::type_info class can be used to obtain the actual name of the type of our polymorphicObject, as follows:

const char* name = info.name();

Which will yield a string representation of the class name, but not necessarily the actual class name. I believe the string returned is “implementation dependent” and as such may vary from compiler to compiler. We’ll see what we get on the iPhone shortly.

2. Dynamic type casting. The C++ operator dynamic_cast allows casting "down" a polymorphic inheritance tree (ie, casting from a base class to a derived class). It operates on pointer (and reference) types and the syntax is as follows:

pointer to object of target type = dynamic_cast(pointer expression);
reference to object of target type = dynamic_cast(reference expression);

To see this in action, consider the following class definitions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Class InterfaceClass
{
public:
    virtual GeneralMethod()
    {
    }
};
 
Class SpecializedClass : public InterfaceClass
{
public:
    virtual void GenerealMethod()
    {
    }
    virtual void SpecializedMethod()
    {
    }
};

Then, let’s say we have a base class pointer that actually points to a specialized class.

InterfaceClass* interface = new SpecializedClass();

There is no way to call the method SpecializedMethod() from this base class pointer directly; however, if we know the pointer is to a SpecializedClass, we can use the dynamic_cast operator thus:

SpecializedClass* specialized = dynamic_cast<SpecializedClass*>(interface);

There is much more to this topic than I have space to go into here, but we’ve at least covered some of the basics. The question remaining is, “will it work in the iPhone”? In fact, this works perfectly well, and I’ve wrapped the above into an example you can try. Using the same project as the previous articles, I made myself new files rtti.cpp and rtti.h and added them to the project. In this case, I am not going to make a class called “rtti” but these files will hold our RTTI test code.

Our header file rtti.h looks like this:

1
2
3
4
5
6
7
8

// rtti.h
#ifdef __cplusplus
extern "C" {
#endif
	void rttiTest();
#ifdef __cplusplus
}
#endif

And rtti.cpp looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

// rtti.cpp
 
#include "rtti.h"
#include <typeinfo>
#include <iostream>
 
using namespace std;
 
// test typeid
class PolymorphicClass
{
public:
	virtual void virtualMethod()
	{
	}
} polymorphicObject;
 
// test dynamic_cast
class InterfaceClass
{
public:
    virtual void GeneralMethod()
	{
	}
};
 
class SpecializedClass : public InterfaceClass
{
public:
    virtual void GenerealMethod()
	{
	}
    virtual void SpecializedMethod()
	{
		cout << "SpecializedMethod()" << endl;
	}
};
 
void rttiTest()
{
	const type_info &info = typeid (polymorphicObject);
 
	const char* name = info.name();
	cout << "typeid name of PolyMorphicClass is " << name << endl;
 
	InterfaceClass* interface = new SpecializedClass();
 
	// can't do this:
	// interface->SpecializedMethod();
 
	// but use dynamic_cast to down cast the pointer
	SpecializedClass* specialized = dynamic_cast<SpecializedClass*>(interface);	
 
	// and then this works fine:
	specialized->SpecializedMethod();
 
	// and for good measure print the names of pointee objects
	cout << "Run time type name of interface is " << typeid(*interface).name() << endl;
	cout << "Run time type name of specialized is " << typeid(*specialized).name() << endl;
}

Then I included rtti.h from main.m and added a called to the rttiTest() method at the top of main():

	rttiTest();

The console output when this is run on the iPhone is as follows:

typeid name of PolyMorphicClass is 16PolymorphicClass
SpecializedMethod()
Run time type name of interface is 16SpecializedClass
Run time type name of specialized is 16SpecializedClass

Notice the name given is “16PolymorphicClass”, which is pretty typical of the type of name you’ll see wen using typeid. It is useful for comparison purposes, if nothing else. I believe this is an artifact of the “mangling” that occurs to all C++ symbols during compilation. I’ve also added output to show the run time type names of the object pointed @ by interface and specialized, for good measure (they are the same, as you would expect).

To recap, we have shown through an extremely simple example that basic RTTI operations do in fact work on the iPhone. We saw that typeid gives us run time type info about an object, and that dynamic_cast correctly casts down a polymorphic class hierarchy.

In upcoming articles I will be moving on to examples of interaction between Objective C, Objective C++ and straight C++ code.

I would add as a footnote that dynamic_cast is potentially a performance hog and can often be avoided in favor of the alternate static_cast operator (which is resolved at compile time). Still, as a C++ language feature it is good to know that it is available.

Jumping right into some code, using the same Xcode project as in part 1, I added a new C++ class Exceptions (adding Exceptions.cpp and Exceptions.h to the project).

Exceptions.h looks like this:

1
2
3
4
5
6
7
8
9

#include <exception>
#include <iostream>
using namespace std;
 
class Exceptions
{
public:
	static void test(int whichException);
};

This is a very simple class with just one static member function used to exercise exception handling support. The only noteworthy thing here is that some of the C++ standard library features are used, namely the #includes of <iostream> (used here to output logging information to the console) and <exception> which is a base class intended to be sub-classed by applications. Additionally, we need to specify "using namespace std " to avoid specifying the "std:: " prefix on all standard C++ library classes.

Exceptions.cpp looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

#import "Exceptions.h"
#import "ExceptionsBridge.h"
 
void exceptionTest()
{
	Exceptions::test(1);
	Exceptions::test(2);
	Exceptions::test(3);
	Exceptions::test(4);
}
 
class MyException1 : public exception
{
	virtual const char* what() const throw()
	{
		return "MyException1 was thrown";
	}
} myException1;
 
class MyException2 : public exception
{
	virtual const char* what() const throw()
	{
		return "MyException2 was thrown";
	}
} myException2;
 
class MyException3 : public exception
{
	virtual const char* what() const throw()
	{
		return "MyException3 was thrown";
	}
} myException3;
 
class BadException : public exception
{
	virtual const char* what() const throw()
	{
		return "BadException was thrown";
	}
} badException;
 
void Exceptions::test(int whichException)
{
	try
	{
		switch(whichException) {
		case 1:
			throw myException1;
		case 2:
			throw myException2;
		case 3:
			throw myException3;
		default:
			throw badException;
		}
	}
	catch (exception& e)
	{
		cout << e.what() << endl;
	}
}

There are a number of things happening here. First, you’ll notice the #include of ExceptionsBridge.h , more on this later. We also derive 4 custom classes from the standard library "exception " base class, namely MyException1-3 and BadException . These are declared and instantiated in place using the declarators myException1-3 and badException respectively.

We also implement the static Exceptions::test() method, which simply takes an int parameter and uses it to decide which exception type to throw. The throws are wrapped in a try{} block, with a corresponding catch{exception&} statement, which catches a reference to the base exception class, so that all thrown exceptions are caught internally. The catch block also writes log output to cout which is a standard C++ library console output stream.

We also implement the C-style method exceptionTest() at global scope, the definition looks like this:

1
2
3
4
5
6
7

void exceptionTest()
{
	Exceptions::test(1);
	Exceptions::test(2);
	Exceptions::test(3);
	Exceptions::test(4);
}

The exceptionTest() method simply calls Exception::test() with various parameters and is not part of a class, so is callable from C language. In order to do this we use the ExceptionsBridge.h file which is included both from the C++ side (in Exceptions.cpp ) and from the Objective C side (in main.m , as we’ll see shortly).

The ExceptionsBridge.h file looks like this:

#ifdef __cplusplus
extern "C" {
#endif

void exceptionTest();

#ifdef __cplusplus
}
#endif

This is the secret sauce that provides a way for Objective-C code to communicate with C++ code. In order for the exceptionTest() method to be visible from Objective C code, we need to do two things: i) declare the method as extern "C" from the C++ side (this will provide an unmangled symbol export to make the method visible to Objective C), and ii) forward declare the method from the Objective C side (so that the compiler knows it is external and will be resolved at link time). This header accomplishes both by using the preprocessor to test the compiler defined symbol __cplusplus , which is only defined when compiling a C++ file. A bridging header like this could be used to bridge all touch points between Objective C and C++ code (though there are other ways to do this using Objective C++ features, which I plan to cover in a future article).

Then, to complete the picture, we add the following to main.m

#import "ExceptionsBridge.h" // this goes immediately above the main() method

And,

exceptionTest(); // make this the first thing the main() method does

Note, if you are following along at home, remove any code added to the main() method in the previous article.

OK, so that is all the code. To recap, here’s what we did:

C++ side:

• defined some custom C++ exception types derived from the standard lib exception base class
• created a simple C++ class with a static method that throws and catches the custom exception types
• logged output using the standard iostream classes
• wrapped all this in a C function exported to be visible to the Objective C side

Objective C side:

• imported the C wrapper function
• invoked the C wrapper function

When this is built and run, we see the following on the console:

MyException1 was thrown
MyException2 was thrown
MyException3 was thrown
BadException was thrown

This is completely as expected, each of our custom exception types was thrown and caught. This is good news, it means that, at least in simple tests such as these, C++ support on iPhone is shaping up to be pretty nice: in part 1 we saw that global constructors are supported and here in part 2 we see that exception handling is supported. Coming up in part 3 is RTTI support.

That being the case, I’ve rewritten the article and posted on my site here. The article pertains to some interesting static initialization ordering issues wrt C++ in general.

That being said, I did originate the article with examples running in Xcode, and I can report that the behavior I observed running the same code on the iPhone device was identical to that seen running on MSVC. This is really just a long-winded way of saying that once again, the iPhone demonstrates the “expected” behavior when running C++ code (even if the expected behavior is not what you might initially expect!).

Coming from a background of mobile development on other platforms, I was curious about how well C++ is supported on the iPhone. BREW, Symbian and Windows Mobile all have C++ support in one shape or another, and certainly there is a ton of C++ code out there, so my thought was this: will legacy C++ code from other platforms run on iPhone?

The first thing to realize is that under the Xcode hood, Apple is using GCC (the GNU Compiler Collection) compiler for the Obj-C compilation. This is important because the GCC Obj-C compiler is in a manner of speaking also the GCC C++ compiler, with a few different command line switches. So, it seems promising – perhaps C++ support will work. But, what about run time library support? The other major platforms using the GCC tools (BREW, Symbian) have various horrible (and arguably pointless given today’s hardware) restrictions on what you can do, with various C++ “language features” simply being dropped (with various justifications). Here’s a short list of the things you typically don’t get with other mobile C++ tool chains:

1. Global static objects. Static C++ objects are regarded as a no-no for various reasons on other platforms. Both BREW and Symbian want you to reference all global application data through a pointer to allocated application heap. You’ll typically see some sort of “Applet” structure, in which the developer can embed pointers to objects that must be allocated by the application at init time. Then, there is a process of passing the pointer to ths “applet” struct around to any object that needs it, or else there will be a method provided in the platform API which will return the address of the applet struct. There’s good and bad with C++ objects defined at global scope, ordering issues, and so on; however, they can be useful, for example with smart pointers, which have the advantage of cleaning up after themselves when defined @ global scope (whereas a regular pointer would not have its destructor called as we’ll see later). Will iPhone support this?

2. Exception handling. Citing code bloat, this feature is often not supported. You can make it work on BREW w/GCC if you are prepared to do runtime lib hacking, and Symbian (last I checked) has their own non-standard variant, but the standard C++ exception handling is typically missing. Does the iPhone support this? We’re not so worried about the code size on the iPhone – the 10MB OTA AppStore limit gives plenty of room for manuever.

3. RTTI – run time type identification. This is typically not supported, the reasons given being code bloat and lack of exception support (what to do if a cast fails?). Again, does iPhone support this?

It is also important to understand how C++ code interacts with other code written in C and Obj-C. After all, having C++ support is all well and good, but it has to be practically useful, calling back and forth, etc. That said, I am going leave that aspect for a future article, and focus here on pure C++ global static objects – does the iPhone support them at all? The short answer is that, yes, it does.

Note: typically you would not really have a bunch of “loose” global static objects like this – you’d probably want to make them static class members; however, for the purposes of this article I’m simply going to define some objects at file scope, for clarity.

Here’s what I did. I started with the generic iPhone “Window Based Application” Xcode template project. To this, I then started adding C++ classes.

1. CTRL-click on Other Sources, and select Add -> New File
2. In the Mac OSX category, click on C and C++ and then select the C++ File template.
3. I gave my class the name GlobalStatic.cpp and selected ‘also create GlobalStatic.h’

This gives us empty C++ header and implementation files, the contents of which I will detail below.

Next, I followed the same three steps and made myself another C++ class called Tests (Tests.cpp/h).

OK, so the GlobalStatic class looks like this:

1
2
3
4
5
6
7
8
9
10
11

// GlobalStatic.h
 
class GlobalStatic
{
public:
    GlobalStatic();
    GlobalStatic(int integerValue);
    ~GlobalStatic();
private:
    int integerValue;
};

This is a simple class with 2 constructor overloads, a destructor and an int instance var.

The implementation looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// GlobalStatic.cpp
 
#include <stdio.h>
#include "GlobalStatic.h"
 
// default constructor
GlobalStatic::GlobalStatic() : integerValue(0)
{
    printf("GlobalStatic()\n");
}
 
GlobalStatic::GlobalStatic(int integerValue)
{
    printf("GlobalStatic(%d)\n", integerValue);
    this->integerValue=integerValue;
}
 
// destructor
GlobalStatic::~GlobalStatic()
{
    printf("~GlobalStatic(%d)\n", integerValue);
}

I include the C runtime stdio.h file so I can call printf(), which outputs text to the debug console (in this case). Other than that, this is a very basic class who’s main raison d’etre is to call printf() to let us know when the ctor and dtor are called. OK, so far so good.

Note: the difference between #import and #include is basically that #import has “include guards” built in, whereas #include does not. Simply put, using #import will ensure that a header file is not included twice. I’ve used #import for Objective-C headers and #include for the C++ headers, but I’ve omitted include guards in the actual headers to keep things simple.

Now, for the purposes of this exercise the file Test.h remains empty. In Tests.cpp, I define a few global static objects, as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// Tests.cpp
 
#include "Tests.h"
#include "GlobalStatic.h";
 
// define a global static object with default constructor
GlobalStatic gs1;
 
// define spme global static objects with inieger constructor
GlobalStatic gs2(1);
GlobalStatic gs3(2);
 
// this object will be intialized but the dtor will not be called
GlobalStatic* gsp = new GlobalStatic(3);

Then, I added two lines of code to the main.m file:

#include <stdio.h> // add this right below the #import <UIKit/UIKit.h>

And then right at the top of the main() method I added:

printf("main()\n");

And that’s it. No compiler settings, nothing special, just adding the code to the project (though note that a fuller interaction between Obj-C and C++ will take a little more effort). So, what happens when you build and run this? Basically, the objects gs1, gs2 and gs3 and the pointer gsp will be created/allocated by the C++ runtime lib, and this will happen *before* the main entry to the program is called. In the debugger console (Run -> Console) you will see the following output:

GlobalStatic()
GlobalStatic(1)
GlobalStatic(2)
GlobalStatic(3)
main()

When you close down the application, the destructors for the objects gs1, gs2, and gs3 will be called, and you’ll see the following output on the console:

~GlobalStatic(2)
~GlobalStatic(1)
~GlobalStatic(0)


Note! The destructor for the object pointed at by gsp is not called! This is expected, and this could potentially be a resource leak (though, in this case the runtime wil likely clean up the memory at least). It’s important to remember this though – if the GlobalStatic class had been expected to set some state in its destructor (in a database, for example), then that would never happen for that object.

There are actually many subtle (and potentially disasterous) side effects associated with the use of C++ global statics. There are ordering issues that can occur if one such object refers to another and on and on. Refer the C++ FAQ lite for details of some of the horrors (http://www.parashift.com/c++-faq-lite/ctors.html ). So, I am not holding up this technique as a panacea or even something that is highly recommended – you need to know what you are doing and even then tread very carefully. However, as s benchmark for the level of C++ support in the runtime, this is pretty good.

I will cover exceptions, RTTI and more in future articles (time permitting!). What this article has hopefully shown is that there are viable alternatives to using Obj-C on the iPhone and that if you are familiar with using C++ on pretty much any other mobile platform, it may be that the iPhone will pleasantly surprise you with what it does do, rather than by what it does not .