> On Aug 26, 2019, at 4:41 PM, Pier Bover via Cocoa-dev
> wrote:
>
> I'd prefer avoiding C++ if possible.
I had a similar dilemma in 2015 but went with C++, despite earlier bad
experiences with it. I've been happy with my choice; C++11 improved the
language quite a lot and C++17 even furthe
> On Aug 26, 2019, at 6:22 PM, Turtle Creek Software
> 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 li
> I had a similar dilemma in 2015 but went with C++, despite earlier bad
experiences with it. I've been happy with my choice; C++11 improved the
language quite a lot and C++17 even further
Hmm I might consider it. I did a couple of small C++ projects some years
ago before C++11 but I would be prac
Writing that logic in C seems very intimidating to be honest, but thanks
for the suggestion.
A priori I think it would be less painful to maintain two codebases in
Swift and C#.
On Tue, Aug 27, 2019 at 1:44 PM Robert Tillyard
wrote:
> I had a UNIX project that was already in C that I ported to
If it’s any help: Microsoft Visual Studio now offers C++/winrt, a pure C++
environment that works great. Doesn’t seem to be well-known yet but it’s
efficient for Windows Store apps. So all our C++ code goes straight into the
Win version.
No need for C# or C++/CX, etc.
On the Mac I use C++ too ex
We are happy with the lifetime management in our C++ classes.
And C++ keeps improving. ARC doesn't go there and that is fine.
We tried QT early on, but decided against it.
Casey McDermott
TurtleSoft.com
On Tue, Aug 27, 2019 at 2:35 PM Jens Alfke wrote:
>
>
> On Aug 26, 2019, at 6:22 PM, Turt
> On Aug 27, 2019, at 12:35 PM, Turtle Creek Software
> wrote:
>
> We are happy with the lifetime management in our C++ classes.
You're having mysterious ref-counting bugs, so the fact that you're storing
Obj-C references as void* sets off alarm bells.
> And C++ keeps improving. ARC doesn
On 8/26/2019 8:28 PM, Turtle Creek Software via Cocoa-dev wrote:
@property (weak) GSOutlineWindowController *mainWindowController;
self.mainWindowController = [[GSOutlineWindowController alloc]
initWithWindowNibName : @"GSOutlineWindowController"];
[self.mainWindowController showWindow : s
On 8/26/2019 2:49 AM, Turtle Creek Software via Cocoa-dev wrote:
> In the hybrid C++/Obj-C++ files, we use __bridge on all the casts of void
> pointers to Cocoa object > No use of NSBridgingRetain or Release at
all. Is that necessary
under ARC?
NSBridgingRetain() etc. are basically wrappers ar
I highly doubt that setting a breakpoint on objc_retain would be useful: it’s
called too often. Just launching Calculator, for example, hits the function
over 20 times, so even a conditional breakpoint would make execution
prohibitively slow. I would expect you to have more luck finding ever
There is an option in Build Settings, Apple Clang, to Compile Sources As.
That converts everything at once.
Previously I didn't notice Obj-C++ at the bottom. The C++ classes do build
and run OK with that selected.
Using the hybrid forward declaration that Uli suggests, I converted one of
our C++
11 matches
Mail list logo
