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

[wrldwzrd89]

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.

 

[iSee]

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.

 

[wrldwzrd89]

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.

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.

 

[iSee]

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.

 

[Eraserhead]

Windows, though, is more complicated, due to the .NET system Microsoft is encouraging their developers to use.

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.

 

[wrldwzrd89]

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.

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.

 

[yeroen]

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.

 

[Catfish_Man]

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.

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.

 

[Eraserhead]

I've heard good things about Qt it could well be worth a look.

 

[Cromulent]

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.

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.

 

[Ti_Poussin]

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.

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/

 

[wrldwzrd89]

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/

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.

 

[yeroen]

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.

 

[wrldwzrd89]

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.

 

[Cromulent]

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.

http://www.trolltech.com/products/qt/

 

[wrldwzrd89]

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.