Ok to mod. 'ge_vector.h' ?



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 17/11/2004 at 06:35, xxxxxxxx wrote:

    User Information:
    Cinema 4D Version:   8.100+ 
    Platform:   Windows  ; Mac  ;  Mac OSX  ; 
    Language(s) :     C++  ;

    ---------
          Hi all,

    I am often finding myself in the situation where I want to access elements of a vector by index rather than name.
    I.e. I want to use <CODE>vec [ i ]</CODE>, where i=0,1, or 2, rather than having to use vec.x, vec.y, vec.z.

    If I add the following to the Vector struct in '_api/ge_vector.h', I get the behaviour I want.

    <CODE>
    Real &operator; [] (unsigned int i) {
    assert(i<3);
    return *((&x;)+i);
    }

    const Real &operator; [] (unsigned int i) const {
    assert(i<3);
    return *((&x;)+i);
    }
    </CODE>

    I also have a test function which I call during plugin initialisation to confirm that the x,y,z elements
    are packed in order without padding. (Originally done with asserts inside the method calls, but this wasn't safe in the case that the compiler re-orders struct packing in an optimised build).
    <CODE>
    bool testVectorAlign(void) {
    Vector vec;
    bool ok = true;
    if(&vec.y-;&vec.x; != 1) ok = false;
    if(&vec.z-;&vec.y; != 1) ok = false;
    return ok;
    }
    </CODE>

    So, I believe that as long as I make sure that 'testVectorAlign()' returns true before I attempt to use these new operators, I am safe to use them.

    Is there any reason why I should not do this?

    Cheers - Steve



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 17/11/2004 at 07:17, xxxxxxxx wrote:

    Hmm, not sure. Because you are modifying the API? :) why don´t you just write a little function that takes care of it?

    something like

    inline Real Vindex(Vector a,LONG i)
    {
    switch(i)
    {
        case 0: return a.x;break;
        case 1: return a.y;break;
        case 2: return a.z;break;
    }
    return a.x;
    }

    Katachi



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 17/11/2004 at 07:54, xxxxxxxx wrote:

    Hi Katachi,
    Yes, I could take that approach.
    But <CODE>'vec [ i ] '</CODE> is less visually cluttered and is clearer than 'vindex(vec, i)', so I'd rather use the [] operator if there is no good reason not to.

    I agree that in general changes to the API are not a good idea, but this is a very small focussed change, which does not change any of the existing methods, it only adds new ones. However, it's still an API change, which is why I'm asking about any possible repercussions.

    By the way, as a side issue I used '*((&x;)+i)' rather than a switch because it compiles to much more efficient code (3 rather than 12 instructions IIRC).

    Efficiency wouldn't normally be an overriding concern, but vector element access is a low-level activity that I'm doing a lot of.

    Cheers - Steve


Log in to reply