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: Andreas Grosam <email@hidden>
- Date: Thu, 03 Nov 2011 11:59:28 +0100
On Nov 3, 2011, at 10:29 AM, Dave wrote:
> Hi,
>
> I've inherited a project that has a "core" of C++ files. Basically, it looks like some standard methods have been cut and pasted into the project.
>
> I've been converting the higher level code to Objective-C and it's going quite well, but I'm at the point where I now need to address some of the low level classes in the core.
>
> Here are the files in question:
>
> sysplatform.h
>
> sysafx.h, …
> Firstly, do the files mean anything to anyone or are they just the names chosen by the last programmer?
I'm guessing, these are files which are platform-specific, containing facade or adapter classes. The names are chosen by the programmer.
>
> Secondly, the sysgraphics module is a class that interfaces to Core Graphics, when it's initialized a CGContextRef is passed in.
>
> Here is a shortened version of the class definition:
> class CGraphics
> {
> public:
> CGContextRef &FRef;
> CMatrix FMatrix;
> float FAlpha;
> …
> };
>
> And here is a sample method that uses CMatix:
>
> void CGraphics::WorldToScreen(float &x, float &y)
> {
> CVector3 a(x, y, 0);
> a = FMatrix.Transform(a);
> x = a.x;
> y = a.y;
> }
>
> Can anyone offer any ideas or suggestions on the best course of action to convert this?
>
> My initial idea is to make a corresponding Objective-C for "CGraphics" and then change all references CGraphics to use the new class.
> Does this sound like a good idea?
This is certainly possible - but you wouldn't gain much. The C++ class seems to be a thin wrapper around a CGContext. Converting it to Objective-C would only be a tiny step to make your program a good Cocoa citizen.
Performance-wise, there seems to be no issue. But you may also consider to strip this class as a whole and use CG function calls directly.
>
> Once that was done, I'd have the CMatrix, CVector2 and CVector3 to remaining in C++, which I want gone!!! Also one thing that is going to make it difficult is that there operator overrides in operation which will mean expanding out loads of code in Objective-C. So I could either convert them to Objective-C but it strikes me that CoreGraphics has all this built in.
Really, I would these low level classes remain as they are.
Reason:
Take a look at the member function CGraphics::WorldToScreen:
I can imagine, that this function is frequently called. It's using a local variable "a" as a CVector3. In C++ creating local variables happens on the stack, there is no heap allocation required.
In Objective-C you would need to allocate the local object "a" on the heap. If CVector3 implements relatively "cheap" functions, an allocation on the heap and also deallocation would probably cost you an unduly amount of CPU cycles which can slow down the function/method WorldToScreen considerable.
When converting to Objective-C, you should consider the performance impact. Where performance matters (and I mean, where it really matters) Objective-C is not the first tool of choice. A complex system, with typical OOD applied (many class with small functions) C++ would always be considerably faster.
However, you are less frequently in this situation than you might think, because performance critical sections of code can be implemented in Objective-C such that you don't need to cross from C/C++ to Objective-C methods and avoid allocations/deallocations of objects. So, in the example above, CVector3 should remain as C++ or C struct - regardless if the surrounding method is Objective-C and if you aim to go pure Objective-C for your program. This is perfectly legal.
Once the program runs - and this is priority #1 - you may consider to refactor in order to optimize for Mac OS X and Cocoa:
An alternative for Vector and Matrix may be CGAffineTransform - unless you are required to use a full 3D graphics model.
That's my 3 cents.
Andreas
>
>
> Would it be better to use this? I'm a bit concerned that the results won't be the same and also I'm not sure what to do for the best.
>
> Any suggestions or idea greatly appreciated.
>
> All the Best
> 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