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: Jean-Daniel Dupas <email@hidden>
- Date: Thu, 03 Nov 2011 14:44:33 +0100
Le 3 nov. 2011 à 13:09, Dave a écrit :
> 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?
>
Yes
http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_affine/dq_affine.html#//apple_ref/doc/uid/TP30001066-CH204-CJBECIAD
http://en.wikipedia.org/wiki/Affine_transformation
>> 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
>
>
>
> _______________________________________________
> 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
-- Jean-Daniel
_______________________________________________
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