Maxon Developers Maxon Developers
    • Documentation
      • Cinema 4D Python API
      • Cinema 4D C++ API
      • Cineware API
      • ZBrush Python API
      • ZBrush GoZ API
      • Code Examples on Github
    • Forum
    • Downloads
    • Support
      • Support Procedures
      • Registered Developer Program
      • Plugin IDs
      • Contact Us
    • Categories
      • Overview
      • News & Information
      • Cinema 4D SDK Support
      • Cineware SDK Support
      • ZBrush 4D SDK Support
      • Bugs
      • General Talk
    • Unread
    • Recent
    • Tags
    • Users
    • Login

    Ok to mod. 'ge_vector.h' ?

    Scheduled Pinned Locked Moved SDK Help
    3 Posts 0 Posters 212 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H Offline
      Helper
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • H Offline
        Helper
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • H Offline
          Helper
          last edited by

          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

          1 Reply Last reply Reply Quote 0
          • First post
            Last post