Objective-C++

Discussion in 'Mac Programming' started by CoolGamer48, Aug 11, 2008.

  1. CoolGamer48 macrumors newbie

    Joined:
    Aug 11, 2008
    #1
    Hey, (sorry if this is the wrong forum for this)

    I'm a fairly decent C++ programmer, and a friend of mine asked me to work on an app for the iPhone using Objective-C with him. I began learning Objective-C (for like, a half-hour), and I found the syntax very different from C++.

    Anyway, then I heard about how you can use C++ code with an Objective-C compiler. Exactly how fully can you use C++ interchangeably with Objective-C code? I mean, could you write an entire program in C++ and compile it with an Objective C compiler? If I'm trying to use as much C++ code as possible, what's the bare minimum of Objective-C I'd have to use?

    Thanks.
     
  2. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #2
    The bare minimum Objective-C you'd have to use is anything that interacts with the Cocoa Touch APIs (which will be a lot). This will be necessary for your UI, and it would probably be best to use Cocoa I/O rather than fstream, but I haven't tried so you may be able to use fstream without issue on the iPhone. You'll also need to use Objective-C to get things like the current location, if the device has a network connection, etc.

    It's probably possible to write Objective-C functions that do a particular thing, that are not class or instance methods, that you can just call from your C++ code. Then you can write the rest of the application logic in C++. I don't know if you can use C++ in a .m source file or if you need it in a separate .cpp file. It's probably better that you separate it even if you don't have to.

    -Lee
     
  3. CoolGamer48 thread starter macrumors newbie

    Joined:
    Aug 11, 2008
    #3
    So basically, the only time I need to use Obj-C is when I need to get some input from the iPhone, which would be done through Cocoa Touch (which is written in Obj-C?)?

    How do normal functions work in Objective-C? Is it the same as in ANSI C?
    Like:
    Code:
    int ThisIsAFunc(int x,int y)
    {
         return x + y;
    }
    
    or do you use the syntax used to create methods?
    Code:
    (int) ThisIsAFunc: (int) x secondParam: (int) y
    {
         return x + y;
    }
    
     
  4. lazydog macrumors 6502a

    Joined:
    Sep 3, 2005
    Location:
    Cramlington, UK
    #4
    Hi

    You're best reading the Apple Objective-C reference. It has a section on using C++ with Objective-C.

    b e n
     
  5. CoolGamer48 thread starter macrumors newbie

    Joined:
    Aug 11, 2008
    #5
    I've read that, but I still was unclear about a few things.
     
  6. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #6
    You should look at the reference lazydog posted, but Objective-C, being a proper superset of C, supports "standalone" functions like your first example. The second example you gave would only work as a class or instance method. You cannot declare "standalone" functions that way, as you will have nothing to pass a message to in that case.

    Your whole interface would need to be built in interface builder or generated using Cocoa (Touch) functions. So not just getting input, but all of your UI would have to be in Objective-C so you could interact with the Cocoa Touch API (which is Objective-C).

    -Lee
     
  7. CoolGamer48 thread starter macrumors newbie

    Joined:
    Aug 11, 2008
    #7
    Are the Cocoa Touch APIs the only APIs you need to deal with? My friend mentioned learning OpenGL to make a game. Can you make an app dealing only with Cocoa Touch? On the other hand, could you make an app using OpenGL to output visuals instead of Cocoa Touch? From your previous post I'm guessing no.
     
  8. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #8
    Well... you will still need to use Cocoa Touch to get an OpenGL ES panel or setup OpenGL ES in full screen.

    I never want to discourage anyone, but I want to set your expectations realistically...

    if you've never programmed for the mac using Objective-C and Cocoa, and you've never used OpenGL, writing game for the iPhone that uses OpenGL ES is going to require a LOT of learning. You won't be there for a number of months, at least. That's not to say that you shouldn't try to learn what is required, but don't expect to have a prototype done by the end of the week.

    -Lee
     
  9. CoolGamer48 thread starter macrumors newbie

    Joined:
    Aug 11, 2008
    #9
    Alright, so basically you need Cocoa Touch even if you do plan to use OpenGL. Now, if I did want to try and make a game, should I learn OpenGL, or is it possible/realistic to create a game using only Cocoa Touch? I've worked with Direct3D in the past (for 2D graphics), so I think that I should be able to pick up OpenGL without too much difficulty, but I've never actually worked with it, so I don't know.
     
  10. JVene macrumors newbie

    Joined:
    Jul 22, 2008
    #10
    I must preface my post with the caveat that I'm not developing iPhone applications, I target OSX on the various Macs. There are enough similarities that I think my post is pertinent, but you'll need to filter that through your understanding of the iPhone SDK (I'm not familiar with Cocoa Touch, for example).

    I, too, am an experienced C++ developer (from 1987, when it wasn't much yet).

    I have the same viewpoint you mentioned:

    To a C++ developer approaching Cocoa, the natural tendency is to plan an interface to AppKit, so that it is represented as a C++ interface to the application layer. This may be a 'facade' pattern or a 'pImpl' pattern. That approach begins to appear as a C++ framework for Cocoa development, which are sadly lacking from 3rd party sources in stable forms (they're all Carbon, Cocoa is either planned or in alpha stages).

    To put this another way, if your viewpoint is to factor your application development such that C++ is your primary language, then every time you reach for a Cocoa/AppKit feature more than once, it becomes a candidate for this proposed C++ facade/implementation approach.

    After a little time, you reach for Cocoa less and less, but you should seek to retain the design, because MVC is well known, predating Next and OSX, robust and flexible.

    If you're familiar with boost, and in particular the function library within it, you'll have a suitable response to those that might counter that C++ isn't dynamic enough to implement Cocoa. If that's not familiar, then you'll still be able to approach the interface between your application and Cocoa from the design perspectives you're familiar with.

    I've encountered a number of suggestions on various forums that recommend using Cocoa for services beyond AppKit (like files, network connections, etc). However, there's two schools of thought on the subject. There are, for example, platform independent representations for file systems in boost, as well as threads, connections, etc. If you're targeting Cocoa and intend never to target outside Cocoa, then choose what suits. On the other hand, it is obvious to a C++ developer that NSString offers limited utility in the context of C++ code, and extrapolating that realization to the rest of the development leads to similar conclusions regarding issues like filesystems and the like, where the underlying Unix base to OSX is equally applicable, and more portable, than Cocoa counterparts.

    I think it noteworthy, too, that objective-C messaging (which, in C++, is analogous to member functions) can be slower than C or C++ function calls, and the memory management concepts in objective-C are also slower than shared_ptr in boost (which is expected to fold into the C++ standard library).

    Since OpenGL is not objective-C oriented, you may find that performance is better in C++/OpenGL development when appropriate.

    It seems there is a 'gravity' associated with objective-C++ discussions targeting Cocoa applications, where favoring objective-C solutions appears as a bias against C++. So far I've not found that bias compelling, but objective-C is unavoidable where Cocoa is required. With modern C++ techniques, that can be represented in a fashion so lightweight that, eventually, you can view Cocoa as an implementation of a C++ library, provided you're willing to develop that portion of one you're interested in using. I predict that we'll see viable C++ frameworks appear that target Cocoa; QT is in alpha on theirs now, but the application interface is QT. wxWidgets had a Cocoa in alpha for years, but it appears to have been abandoned. The problem for both is that they must implement that framework's application interface design, and so Cocoa is obscured behind that. Besides, QT is expensive for commercial development.
     
  11. ghayenga macrumors regular

    Joined:
    Jun 18, 2008
    #11
    It all depends on the type of game. If you're talking a first person shooter, then you won't get the performance you need without OpenGL ES. If you're talking Tetris, you could just use the basic Cocoa Touch API's.
     
  12. lazydog macrumors 6502a

    Joined:
    Sep 3, 2005
    Location:
    Cramlington, UK
    #12
    OpenGL isn't C++ orientated either, it's C orientated. Drawing with OpenGL is identical whether you are using Objective-C or C++, it's just a bunch of C function calls.

    If somebody ported GLUT (or something similar) over to the iPhone then you could, I imaging, write a game entirely in C++.

    CoolGamer48, OpenGL is pretty easy to learn. I would recommend playing around with it on the Mac first. If you do a search for GLUT then you should be able to get something up and running on the Mac in next to no time. GLUT is a framework that will display a window and handle all inputs and timer functions for you, Using GLUT means there is no Mac specific code for you to write and you can concentrate on learning OpenGL - if that's what you want to do. A good book to get is 'OpenGL Programming Guide', also known as The Red Book.

    b e n
     

Share This Page