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

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.

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.

wrldwzrd89 said:

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

Click to expand...

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.

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.

yeroen said:

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.

Click to expand...

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.

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

Catfish_Man said:

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.

Click to expand...

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.

yeroen said:

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.

Click to expand...

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/

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 said:

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.

Click to expand...

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