Re: Advice on converting this C++ code to Objective-C
Re: Advice on converting this C++ code to Objective-C
- Subject: Re: Advice on converting this C++ code to Objective-C
- From: Dave <email@hidden>
- Date: Thu, 03 Nov 2011 20:31:00 +0000
On 3 Nov 2011, at 13:14, Chris Cleeland wrote:
I would counsel that direct translations of anything rarely make
sense. Despite their shared background, C++ and Objective C are
different languages with distinct idioms. Add the fact that you're
not programming in raw ObjC but rather using Apple's frameworks, and
you have an entire "dialect".
There is real design. As far as I can tell the person that instigated
this, was a anti-Apple guy (yeah, go figure) his main agenda by the
look of it was so he could develop the code on a PC, e.g. edit and
compile. He didn't even have a Mac as far as I know he worked at home
and then came into the office to transfer the C++ files to the Mac
and then spent half a day making it compile under XCode! The really
silly thing about it was that this project was started by someone
that as quite junior and all coded in Objective-C, but as the App
grew in complexity he floundered and so they called an "expert" in.
He then made it all C++. The "Graphics" module just converts things
like CBox to CGRect. In fact most of the code is C++ Class definition
and C++ method definition with a C or Objective C method body. The
only bit that are pure C++ and take advantage or any real C++
specific features are the "system/core" C++ classes which just re-
implement things like NSMuteableString (CString), NSMutableArray
(CList), NSFileManager (CFile), CGPoint (CVector2), CGRect (CBox),
and so on................
The only thing that is anyway time sensitive in this App is an timer
that has to be VERY accurate and not get blocked when an action
occurs. Not much to it really!
Apart from any other reason for converting to at least not trying to
fix it in C++ is that the WHOLE thing is driven off a AppGlobals
Your best results will be obtained by examining the original code,
understanding the design, and implementing it idiomatically in the
Cocoa "dialect". Some things simply do not translate, and the
decision on the best way to re-cast that must be made in the context
of the application itself.
Yes, that's what I am doing, basically CList --> NSMutableArray,
CString --> NSMuteableString, the rest is really just C!
Whenever I've used ObjC++, the C++ has always been relegated to
abstract data type implementations--precisely what you seem to have
wiith the matrix, vector, etc. As you already note, converting those
to ObjC will make the code more verbose and likely far less efficient
(no need for dynamic dispatch on any of those operations).
I really don't see how you can it will *far* less efficient and I'm
willing to bet that it will be faster since there will be no need to
convert a CList into an NSArray, CString to NSString, etc.
All the Matrix stuff or at least the parts that are actually used is
just C++ definition and C code.
I mean:
xpos = xpos * scaleFactor; is pretty much the same in most languages!
and why:
View Controller/View - NSRect
Convert to CBox
Call C++ "core"
Convert to NSRect
Call Core Graphics
This is just a bit of word shuffling, but the waste of converting a
CList to an NSArray, CString to NSString etc. just to convert them
back again to call Core Graphics etc is plain silly!! Any speed that
is lost by converting to Objective-C is more than made up for by this!
For instance CList shuffles the WHOLE list (pointers) each time an
entry is deleted.
Also none of the Cocoa Memory rules have been implemented, so,
instead of retaining an object, copies are made!
It seems that eventually you'll want to ditch those ADT-style types
for native types...or maybe not. If it were me, I would go with an
incremental approach by first writing some unit tests around the
existing class implementations so that I know how they behave, then I
would re-implement the classes internally using the native types
insuring that the unit tests continue working. At some point you can
make a decision as to whether it makes more sense to continue on with
the abstraction or simply go with the native type, and that can only
be made in the context of the rest of the app.
Honestly they do have to go!
Thanks a lot
Dave
_______________________________________________
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