I was actually thinking of doing the killing the thread part for a week now..
threads must die on their own, there is simply no killing them, they are like weeds, if you pull it, that is like a slap in the face to all the other weeds and they redouble their efforts… No, a thread must be poisoned to death, the life choked out of it, the killer is long gone when the weed dies.
Shotzo, do you know that lot of people know very well that formula for finding angles and powers? and those who don’t can look it up?
Most players are older than you btw, i’m 21 for example, also, i’m professional programmer i.e. i am programming in C++ for money. But i still coulda do autoaims hax even if i was 13, coz its the ~7th grade physics.
There’s precisely nothing smart about that cheat, and you aint gonna impress anyone by knowledge or something.
Change of money:
Static const int doesn’t change its length. Floating points do. Unless C++ is WHACKED OUT… lol.. Either way; it might change its length.. or it might go over its buffer size limit and make the data next to it get all mucked up… I don’t think you can do any calculations with a static const unsigned int, go negative, and go back to its boundaries, without something horrible happening to the code. (I tried this with a robot… yeesh. One direction it went forward both ways, the other direction one wheel changed its direction, but the other one stayed in place..)
Well, correct me if I’m wrong … but a “static const int” should NEVER change, right?
Could someone who really knows shed some light on this?
Both of you have made both correct & incorrect statements about ANSI C/C++ :
The sizeof() of any native C/C++ data type in number of octet-bytes does NOT scale up or down based on the specific processor & compiler combination & regardless of other variable declaration modifiers (e.g. ‘static’, ‘volatile’, ‘const’, etc.)
‘const’antly declared variables SHOULD NOT change their values at run-time. Although the compiler SHOULD prevent ‘const’ant value changes via direct variable access, it MAY be possible to change ‘const’ant values via indirect memory accesses (e.g. pointers to memory areas with located ‘const’ant variables). However, since ‘const’ant values are often located in non-volatile ROM or FLASH, the hardware itself is likely to prevent ANY possible ‘const’ant value changes at run-time.
Calculations involving both signed & unsigned (integer) results can easily be designed to NOT “get all mucked up” or have “something horrible happening in the code” by correctly handling signed & unsigned data type overflows.
As Shotzo later amended; the maximum, unsigned, 32-bit integer data value is closer to 4,200,000,000+ than 4,200,000+. However depending on processor/compiler, ‘unsigned long’ might be 32-bit or 64-bit (or higher).