Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your feedback on a survey! Each completed response supports our community and gives you a chance to win a $25 Amazon gift card!


#ActualiMalc

Posted 24 June 2013 - 01:07 AM

Thanks all, my conclusions:

- making these variables mutable should work, but is tricky (as it is today akready), risk on faulty initializiation etc.
- since they're just simple ints and unsigned ints, no complex / higher level algorithms etc, I will create them all locally within the member functions and cleanup the ones in the class(es)

This also fits perfectly within the given principles.

Don't even look at it as if you have an option or choice there. Misusing a member variable for this purpose has many dire consequences:

  1. It inhibits some optimisation because at the very least, the final value must needlessly be written back into the member variable, and worst case may even cause the compiler to not use a register where it otherwise could.
  2. Stack allocation is cheap, very cheap. So cheap that adding an extra variable your stack frame normally has absolutely zero impact on performance.
  3. As a member it increases the amount of memory your class occupies. With many instances, and/or on smaller objects, this could bump up RAM usage very significantly.
  4. It simply will not work when you try to have nested functions using the same member variable as the for-loop variable.
  5. Making it mutable requires that you also wear the added runtime cost of making it threadsafe.
  6. Trying to use any functions which use the same member variable as a loop counter from multiple threads simply will not work.

Long story short, do not ever misuse use a member variable for the purpose of what should be a local loop variable.


#1iMalc

Posted 24 June 2013 - 01:06 AM

Thanks all, my conclusions:

- making these variables mutable should work, but is tricky (as it is today akready), risk on faulty initializiation etc.
- since they're just simple ints and unsigned ints, no complex / higher level algorithms etc, I will create them all locally within the member functions and cleanup the ones in the class(es)

This also fits perfectly within the given principles.

Don't even look at it as if you have an option or choice there. Misusing a member variable for this purpose has many dire consequences:

  1. It inhibits some optimisation because at the very least, the final value must needlessly be written back into the member variable, and worst case may even cause the compiler to not use a register where it otherwise could.
  2. Stack allocation is cheap, very cheap. So cheap that adding an extra variable your stack frame normally has absolutely zero impact on performance.
  3. As a member it increases the amount of memory your class occupies. With many instances, and/or on smaller objects, this could bump up RAM usage very significantly.
  4. It simply will not work when you try to have nested functions using the same member variable as the for-loop variable.
  5. Making it mutable requires that you also wear the added cost of making it threadsafe.
  6. Trying to use any functions which use the same member variable as a loop counter from multiple threads simply will not work.

Long story short, do not ever misuse use a member variable for the purpose of what should be a local loop variable.


PARTNERS