Re: bringing windows c++ code to Macintosh
Re: bringing windows c++ code to Macintosh
- Subject: Re: bringing windows c++ code to Macintosh
- From: M Pulis <email@hidden>
- Date: Wed, 10 Sep 2008 04:52:21 -0700
On Sep 10, 2008, at 2:34 AM, Ken Thomases wrote:
As others have pointed out, a big part of your problem is that
you're trying to compile plain C (or Objective-C) files that
contain C++ code. You need to put C++ code into .cpp or .mm
files. (It is possible to tell Xcode to treat a file as C++ or
Objective-C++ regardless of its extension, but you'll just confuse
yourself if you go that route.)
The C++ code is in .cpp files. I looked a File Types in the workspace
guide, and I agree, I do not need more confusion.
What is the difference between ".m" and ".mm" files? A .m file can
not access C++ code?
Thanks!
Beyond that...
On Sep 10, 2008, at 1:33 AM, M Pulis wrote:
(1) How should fields declared as HGLOBAL be declared as on
Macintosh? I have tried "handle" but Xcode complains (why???).
Tried uint32, which allowed compilation to continue, BUT, it feels
wrong.
The short answer is that you don't declare those fields as anything
on the Mac. If you don't understand that porting to the Mac means
totally revamping or replacing any code which currently uses Win32-
specific data types, then you're not going to get very far.
Yes, I understand. However, some things can be revamped easier than
re-written and sometimes similar concepts are simply called different
names. As my very first C++ port to Mac Xcode _and_ first Obj C Xcode
project (but not my first port, I have moved Windows C code libraries
to MPW Pascal and MPW Pascal Units to Windows C, ISO Pascal (PC) to
UCSD Pascal (Mac) and vice-versa), I am looking for experienced tips
to avoid doing more work than needed.
You need to examine what those HGLOBAL fields are being used for
(their semantics, not their syntax), research what the appropriate
alternative would be to achieve similar semantics in the Mac API(s)
that you've chosen, and then rework the code in terms of those new
Mac APIs. It is never going to be as simple as just declaring the
same fields with different type. You may not need those fields,
you may need different fields, you may need more fields or fewer --
it requires redesign.
Of course, yes, that was the case in my other porting projects. In
the case of the fields I am looking at they appear to be simple
pointers to pointers to globally allocated blocks of memory, much
like having an opaque handle as a field in a record. And, the fields
appear to be necessary as the underlying record pointed at by the
field contains fields needed to function. Whether they need to remain
that way (as handles to reference a global or if a global reference
in a field is even appropriate) is highly doubtful as you point out.
So far all I am dealing with are data types, no Mac API calls in this
level. In fact, we have isolated most of the platform-specific low-
level stuff such as hardware I/O and callbacks into a framework.
Fortunately, zero GUI elements are involved.
My intent was to use the original source code with a define to
isolate Macintosh versions of the various classes, structs and other
hoo-hah.
Regards,
Ken
Thanks, Ken!
Gary
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden