> On Aug 26, 2019, at 6:22 PM, Turtle Creek Software <supp...@turtlesoft.com>
> wrote:
>
> There are links between each Cocoa control class and its matching C++ control
> (which also owns a native MFC control).
> Also links between the view and our C++ controller, to load window layouts
> and set up the control links.
> A couple utility links for showing progress bars, log window, etc.
Ah, OK. Your C++ code goes higher up the stack than I thought. (It sounds like
using Qt would have been a good idea, but it's probably much too late to
rethink that now.)
My suggestion is simply to compile all your C++ code as Objective-C++. In your
project settings just tell Xcode to map the ".cpp" suffix to Objective-C++
instead of C++.
Then you can refer to Cocoa classes by their regular names in the C++ code,
just as if you were writing Objective-C. ARC will automatically manage their
reference-counting. If you have an NSButton* data member in a C++ class, the
compiler will insert retain/release when it's assigned, and will add a -release
call to your destructor. (Just make sure to initialize it to nil in its
declaration!)
This way you aren't fooling the compiler, and it can do the right thing with
reference-counts.
For x-plat compatibility, you can either #ifdef out the places those are
referred to, or conditionally declare those class names as bogus C++ classes:
#ifndef __APPLE__
namespace cocoa {
class NSButton;
class NSWindow;
…
}
#endif
—Jens
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
