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 12:09:37 +0000
Hi,
On 3 Nov 2011, at 10:59, Andreas Grosam wrote:
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.
Yes, I was thinking that too, the trouble is that the object holds
the Matrix and Alpha channel iVar's, so I might need to keep these
around. Also it seems like a good step since these methods contain
take as entry parameters:
CBOX - CGRect equivalent.
CVector2 - CGPoint equivalent.
So the rest of the App is using the C++ versions which makes the
whole App hard to use from an Application Programmers point of view.
We want to hire some junior iOS developers but this will be source of
confusion.
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.
I understand your concern here, WorldToScreen is called a lot, but
surely I could pre-allocate these the CVector3's etc, as iVar's in
the init method?
Also, Here are the transform methods:
CVector3 Transform(const CVector3 &in) const
{
float x = in.x, y = in.y, z = in.z;
return CVector3(x * m[0][0] + y * m[1][0] + z * m[2][0] + m[3][0],
x * m[0][1] + y * m[1][1] + z * m[2][1] + m[3][1],
x * m[0][2] + y * m[1][2] + z * m[2][2] + m[3][2]);
}
CVector2 Transform(const CVector2 &in) const
{
float x = in.x, y = in.y;
return CVector2(x * m[0][0] + y * m[1][0] + m[3][0],
x * m[0][1] + y * m[1][1] + m[3][1]);
}
void Transform(CVector3 *pt) const
{
float x = pt->x, y = pt->y, z = pt->z;
pt->x = x * m[0][0] + y * m[1][0] + z * m[2][0] + m[3][0];
pt->y = x * m[0][1] + y * m[1][1] + z * m[2][1] + m[3][1];
pt->z = x * m[0][2] + y * m[1][2] + z * m[2][2] + m[3][2];
}
These could easily just be put in the GraphicsHelper class which
would be faster still.
As far as I know at the moment, it only does 2D transforms and they
are limited to Translate and Scale.
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.
This really isn't a performance hungry app, but yes, I take your point.
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.
Yes, but see above, I was thinking that's I'd just implement the
methods used as C functions and call it from the GraphicsHelper class.
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.
At the moment I can't get it to build, hence my other thread. This is
another reason to get rid of the C++ code.
It only does 2D AFAIK. Once I've isolated out all the C++ code and I
had then change it to use CGAffineTransform. I've had a quick look
and there only seems to be methods for Translate. Rotate, and Scale.
Do these work together? e.g. Call Set Translate, Set Scale and Set
Rotate will result in a Translated, Scaled and Rotated line or whatever?
Thanks again for your help.
All the very Best
Dave
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:
40looktowindward.com
This email sent to email@hidden
_______________________________________________
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