Objective-C++ what goes where?

Member
Posts: 469
Joined: 2002.10
Post: #1
I finally got around to opening back up XCode to work on personal projects. This time around I thought I might make a small 3D engine.Wacko

Anyhow, I've been playing around with Objective-C++ and I'd like to get everyone's take on pros and cons of using what where. So far, I've tried to separate out classes as follows:
Vector, Matrix, Vertex, etc. as C++ structs.
View, Scene, Renderer, Models, etc as Objective-C classes.
And, I also have some weird Objective-C++ wrapper classes to get it all to talk nice.

My aim is to keep all the basic geometry fast and free of messaging and class overhead. Anything that fits into the MVC pieces of the app are Objective-C or Objective-C++ (basically no data/geometry). Now, this is my first real attempt to mix C++ and Objective-C and it's been pretty trying. And with respect to C++, yes I'm a total noob.

Before I move forward though, I want to know: Are there any big gotchas coming my way with my current course of action? Is there a better way to apply the Objective-C/C++ to my classes? Am I doing anything unnecessarily (wrt class design/coding)? Do I even need the C++ parts?






So far I've got a rudimentary .obj loader and renderer built in Objective-C. Totally un-optimized immediate mode (begin/end on each poly!LOL) 117fps for 1200 polys on my MBP. Took about 4 hours of my weekend. Encouraging results so far.

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
Post: #2
The only thing that I can say that you will be frustrated by is the compile times for Obj-C++ - roughly three times longer than the other languages. Now, on an MBP that might not be a problem. Wink

Personally, in my BlackEngine, I most of the engine and game code in C++, with the exception of platform specific parts exiled away into Obj-C .m files. In order to keep them cleanly separated, I have a thin layer of Obj-C functions. The C++ code calls specific functions (say, BlackGlueGLSetFullscreen) that in turn call my Obj-C objects. That way, I can avoid Obj-C++ in most cases.

Now, this is just because there will be another coder that will port the engine to Windows, and that's why I'm being prudent. If you're writing this yourself, or not planning to port, then go with what you suggested. It sounds fine.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
Not really what you're after, but some standard gotchas with ObjC++ are:

* it's really freakin' slow to compile

* constructors of C++ objects stored by value in ObjC classes are not called automatically. If you don't mind being 10.4-only, there is a compiler option you can turn on to enable this. Otherwise, you must use "placement new" to initialize them.

* destructors of C++ objects stored by value in ObjC classes are not called automatically. If you don't mind being 10.4-only, there is a compiler option you can turn on to enable this. Otherwise, you must call them explicitly yourself.
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #4
OneSadCookie Wrote:* it's really freakin' slow to compile
I'm not really familiar with how XCode determines which options to set when compiling. Right now, I have to pass "-x objective-c++" to get everything compiling. Does this mean all my pure Objective-C and pure C++ classes also compile slowly?

Currently, I stick my geometry C++ classes in their own .hpp/.cpp files and then import in the .hpp in an Objectiv-C .h/.mm adaptor class.

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #5
If you have to pass -x objective-c++ then you're doing something wrong Rasp

Xcode uses the source file's extension to determine how to compile it. .m will compile as ObjC, .c as C, .cpp or .cc as C++, .mm as ObjC++, etc.

Remember that any header file included in a given source file must compile in the language of the source file. You may find the preprocessor macros __cplusplus and __OBJC__ useful for this. See also here: http://tips.onesadcookie.net/tips/publis...+for+Xcode

Only ObjC++ source files (only .mm files by default, but your -x objective-c++ causes everything to be compiled as ObjC++) and code included in them (like, say, <Cocoa/Cocoa.h> and <iostream>) suffers the ObjC++ performance penalty, though C++ is pretty slow to begin with...
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #6
OneSadCookie Wrote:If you have to pass -x objective-c++ then you're doing something wrong Rasp
Well, I'm not sure what I'm doing wrong, but XCode seems to try to compile my C++ class as C regardless if it's .h/.cc, .hpp/.cpp, or .h/.mm.

The project

if I pass "-x objective-c++" and turn of pre-compiled headers, it works.

Although, XCode doesn't seem to remember the flag setting when copying the project file... annoying.

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #7
Hmn... if I change my project controller to .mm it compiles. Does this mean I can't use Objective-C++ files from Objective-C files?

Edit:
Okay. I got it.

I can do @class MyObjCppClass; and then do the import in the .m file.

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #8
Quick update:
I've done some work on my loader and wrote a simple non-immediate mode renderer. Runs a bit faster:

2006-07-25 00:32:25.550 Project1[9007] Model loaded; 10408 vertices; 15894 polygons
2006-07-25 00:32:25.550 Project1[9007] 1.00 seconds processing
400fps average in opengl profiler rendering with DrawElements with a 0 wait NSTimer. Running at 90% of one of the cores.

It looks like I'm hitting bandwidth to the card limits at this point as vertex submission to the card is sucking 45% of a core and my app is waiting for the submission to end for the other 42%.

Still not optimized completely mind you as I'm just doing a regular Vertex/NormalPointer call to submit. I'm sure I'll gain a lot more once I throw in VBO, VAR, etc.

Since I'm already hitting the hardware wall, I'll assume my ObjC++ data structures are pretty sound for now. Cool beans.

[Image: nolighting.png]

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #9
Tinker here, tinker there.
Added lighting and various bits.
[Image: marchOfprogress.png]

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Apprentice
Posts: 18
Joined: 2006.06
Post: #10
Hi kelvin,

I am relatively new to Xcode/Objective-C, but I do know my way around the C++ djungle. I am currently trying to develop an application which "might" be ported to Linux/Windows in the future. Your way of separating the core code in this example (a la C++) from the interface is very interesting.

Is it possible for you to post a current copy of your project so that I can get a grasp of how you have been thinking, logically? I've downloaded the early project files you posted above, but it doesn't run without modifactions...

Thanks in advance!

/ M
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #11
Haven't really worked on it lately, but here's the latest:

Project1

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Apprentice
Posts: 18
Joined: 2006.06
Post: #12
kelvin Wrote:Haven't really worked on it lately, but here's the latest:

Project1

Thanks for the fast reply! Now I'll have something to do this weekend Wink
Quote this message in a reply
Post Reply