Calling functions in other languages (Obj-C <-> C)

Discussion in 'Mac Programming' started by wrldwzrd89, May 8, 2008.

  1. macrumors G4

    wrldwzrd89

    Joined:
    Jun 6, 2003
    Location:
    Solon, OH
    #1
    I have a book on Objective-C, and I read through it (but haven't had time, until today, to try following the examples). I would like to make a project in XCode that uses a mixture of Objective-C code and plain old C. I understand how to call C functions from Objective-C code, but not calling Objective-C functions from C code. Is this even possible? If it is, how would I go about doing it?

    EDIT: If this isn't possible, it's no big deal. I should be able to work around it.
     
  2. macrumors 68040

    iSee

    Joined:
    Oct 25, 2004
    #2
    Well, Objective-C is a superset of C. So you can compile your "C" code with the Objective-C compiler and therefore, make Objective-C calls easily.

    In fact, I'd say if your C code is calling Objective-C methods, it's not C code at all--it's really Objective-C.
     
  3. thread starter macrumors G4

    wrldwzrd89

    Joined:
    Jun 6, 2003
    Location:
    Solon, OH
    #3
    That's good to know. The reason I ask is this: I wish to write a cross-platform application, and I realize that the easiest way to do this is to write the back-end in C and the GUI parts in Objective-C, for the Mac OS X version. The question then becomes one of what language to use for the Windows and Linux versions for the GUI portions. For Linux, of course, it's a no-brainer: C++ is the obvious choice. Windows, though, is more complicated, due to the .NET system Microsoft is encouraging their developers to use.
     
  4. macrumors 68040

    iSee

    Joined:
    Oct 25, 2004
    #4
    In that case, I'd see if I could avoid having any Objective-C in the backend at all. If you do, that means some platform specific stuff is creeping in to what is supposed to be the cross-platform layer.

    You'll what to structure it so that primarily the GUI, platform-specific layer (Obj-C on Mac, C++ on linux, C? on Windows) makes calls to the cross-platform C layer but not the other way around.

    If/when you do need callbacks from the platform neutral layer to the platform specific layer, it makes sense to consider using C functions and data types for that interface.

    If your project is large, consider three layers:
    1. GUI - platform specific language
    2. PAL - "platform abstraction layer" You'll have one version of this for each platform
    3. Cross-platform backend.

    The PAL sits between the two other layers. It's only job is to make the connection between layer's 1 and 3. Each version presents the same logical interface to each of the GUI platforms it supports, but each implementation would contain language/platform specific details. It's important that the interface for the GUI-layer be logically identical across platforms even though it is implemented in the platform-specific language. For example, if a function took a rectangle parameter, it might be a CGRect on Mac and a RECT structure on Windows, but it's still representing the same thing. If you don't maintain a logically identical interface for the PAL, it loses its purpose and advantages. If the cross-platform layer does need to make callbacks to the GUI layer, the PAL would also expose an interface for that.

    So calls from the GUI to the backend go through the PAL.

    Mac: Layer 1 makes Objective-C call to the PAL. The PAL, in turn, makes a C call to the backend, transforming parameters, objects, etc, as needed. Return values are bundled back up a an Objective-C type, if needed.

    Linux: Layer 1 makes C++ call to the PAL. The PAL transforms the parameters as needed and makes the same C call to the backend. Return values are bundled back up as a C++ type, if needed.

    Win: Layer 1 makes a C# (for example) call to the PAL. The PAL transforms the parameters as needed (probably needs a lot coming from managed C# to unmanaged C) and makes the call to the PAL. Return values are bundled back up as a C# type, as needed.
     
  5. macrumors G4

    Eraserhead

    Joined:
    Nov 3, 2005
    Location:
    UK
    #5
    With regards to .NET the problem is that it is incomplete so not all functions in Win32 are implemented so you may well have to fall back to C++/Win32 anyway. I can't go into technical details of whether this will be an issue for your application however, and depending on what you want to do it may not be an issue.

    .NET also isn't being widely used for desktop applications, currently there are very few applications written in .NET currently on Windows, certainly considerably less than there are Cocoa applications for the Mac.

    FWIW Adobe Lightroom has used C++/Win32 for Windows and Objective C/Cocoa for Mac.
     
  6. thread starter macrumors G4

    wrldwzrd89

    Joined:
    Jun 6, 2003
    Location:
    Solon, OH
    #6
    Thank you, I did not know this about .NET... in which case I probably WILL use Win32 for the Windows version, simply because I can target more versions of Windows that way.
     
  7. macrumors 6502a

    yeroen

    Joined:
    Mar 8, 2007
    Location:
    Cambridge, MA
    #7
    For cross-platform C++ application development with native GUI support on each platform, use Qt.

    It's a very elegant framework and will save you much strain, effort, and time trying to maintain three different forks of the development tree: OSX/Aqua, Linux/BSD/X11, and Windows.
     
  8. macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #8
    Native is a funny word. Yes, it's using CG/Cocoa/whatever under the hood, but native from a user perspective (arguably the main one that matters) means that it *behaves* like a native app as well as looking like one.
     
  9. macrumors G4

    Eraserhead

    Joined:
    Nov 3, 2005
    Location:
    UK
    #9
    I've heard good things about Qt it could well be worth a look.
     
  10. macrumors 603

    Cromulent

    Joined:
    Oct 2, 2006
    Location:
    The Land of Hope and Glory
    #10
    Surely all that native means is that it is compiled to run on the processor that the computer uses, i.e it is not emulated which is the opposite of a native application.

    I know where you are coming from but it is a rather confusing use of a term which up until recently had a very clear cut meaning.
     
  11. macrumors regular

    Ti_Poussin

    Joined:
    May 6, 2005
    #11
    You may also take a look at wxWidgets, it's a lot like Qt. I personnaly prefer it to Qt, but it's really personnal on that matter.
    http://www.wxwidgets.org/
     
  12. thread starter macrumors G4

    wrldwzrd89

    Joined:
    Jun 6, 2003
    Location:
    Solon, OH
    #12
    I was not aware that Qt was a cross-platform toolkit. I was aware of wxWidgets but I'm not sure if I want to use it or not, yet.
     
  13. macrumors 6502a

    yeroen

    Joined:
    Mar 8, 2007
    Location:
    Cambridge, MA
    #13
    Qt used to only emulate the look and feel of the native widget sets, but the latest versions (from Qt4 onwards, I believe) use the native APIs.
     
  14. thread starter macrumors G4

    wrldwzrd89

    Joined:
    Jun 6, 2003
    Location:
    Solon, OH
    #14
    Anyone got a link to the Qt homepage? I'm interested in looking into this - if it works the way I hope it does it'll save me a ton of time.
     
  15. macrumors 603

    Cromulent

    Joined:
    Oct 2, 2006
    Location:
    The Land of Hope and Glory
    #15
    http://www.trolltech.com/products/qt/
     
  16. thread starter macrumors G4

    wrldwzrd89

    Joined:
    Jun 6, 2003
    Location:
    Solon, OH
    #16
    Well, I looked at both products. Qt doesn't meet my needs very well, but wxWidgets meets them VERY well. I think I'll be using wxWidgets, then.
     

Share This Page