Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Your question is rather general so I can only give some high level architectural tips for a predominantly C++ based application that you want to port to Mac OS X and have a native Cocoa UI.</p> <p><strong>Threads:</strong> Just because the C++ code has the main thread on Windows does not mean that it needs to be on Mac OS X. Start your application the usual Cocoa way with NSApplication and then in your app delegate's <code>applicationDidFinishLaunching</code> you should do two things:</p> <ol> <li>Launch an NSThread even if it does nothing and just returns immediately. You need to do this to switch Cocoa to be internally thread safe (such as it can be). Since your C++ code will instead be launching pthreads you need to start at least one higher level NSThread first.</li> <li>Call into the startup routines of your C++ code. If this code is long running, launch a separate thread. There is no reason why the your C++ code needs to be running on the main thread on Mac OS X; it can be on any auxiliary thread. The only special thing about the main thread on Mac OS X is that events are delivered there and UI changes should take place from there. Both of these things should be handled in Cocoa native code, not in portable C++ code.</li> </ol> <p><strong>Language Barrier</strong> You have a language barrier to deal with. Your C++ code can't directly access Objective-C objects and visa versa. You can smooth over this problem with Objective-C++ but best practice is to use Objective-C++ only for a thin translation layer and keep the two separate. In addition to providing a more canonical programming environment it also helps logically to separate UI code (in Objective-C) from lower level application services (in C++). Rob Napier has written a lot about how to do this and I suggest reading <a href="http://robnapier.net/blog/wrapping-cppfinal-edition-759" rel="nofollow">his recent blog post</a> along with some of his earlier posts on the subject.</p> <p>To elaborate a bit more generally you will be using one of several techniques to go from C++ to Objective-C since that is the direction you asked about:</p> <ol> <li><p>Provide C interface functions that can be called from Objective-C or C++. Their implementation can be written in whatever language is most convenient. The header for these functions will have lines like the following to let the C++ code know they have C and not C++ interfaces:</p> <pre><code>#if defined __cplusplus extern "C" { #endif void passAString(const char *string); // ... some other C interface functions #if defined __cplusplus } #endif </code></pre></li> <li><p>Provide Objective-C++ bridge functions that take C++ objects and translated them to Objective-C objects before calling the native Objective-C code.</p></li> <li><p>Write Objective-C++ bridge objects. These provide a thin C++ veneer to an underlying Objective-C object so the C++ layer can interact with it.</p></li> </ol> <p>Obviously you will need to use similar techniques in the reverse to call from Objective-C code to C++.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload