SAFE_DELETE -> RageUtil::SafeDelete
SAFE_DELETE_ARRAY -> RageUtil::SafeDeleteArray
Update JsonUtil.h to include RageUtil.h - MSVC doesn't need it included for some reason, but GCC and XCode does.
- Use fast data types where possible so the compiler can optimize for speed based on platform
- for example, 128 bits might be fastest on ARM
- good future-proofing
- Refactor GetTimeSinceStart() to be a bit faster
- multiplication is much faster than division
- Implement a RageTimer method to get the seconds value as a plain int, for the places which cast the seconds value to an int
- Changing from GetTimeSinceStartFast() to GetTimeSinceStart() where accuracy is important
- Changing from GetTimeSinceStart() to GetUsecsSinceStart() for timestamp diffs
- Adjust RageThreads to accomodate an unsigned timestamp value
- a constant for the maximum value of `uint_fast64_t` replaces `-1` to accommodate the change from signed to unsigned for the `locked_at` variable
- i have separate constants for `std::numeric_limits<std::uint_fast64_t>::max()` and `static_cast<std::uint_fast64_t>(-1)`, so the reader understands -1 represents an error code, though they evaluate to the same value, so i could remove one of the two
- Add two methods to calculate the MMSSMsMs / MMSSMsMsMs time value from usecs directly instead of inferring it from a seconds value, in RageUtil
- Use a similar counter/modulo based method for WheelNotifyIcon, similar to what i did for text_glow in NoteField in 2eeee03
- Make `g_iStartTime` static const for safety
Rename two timer functions:
GetUsecsSinceStart -> GetTimeSinceStartMicroseconds
GetMicrosecondsSinceStart -> GetSystemTimeAsMicroseconds
Remove std prefix from uint_fast64_t
This is meant to be a safer alternative since
NULL can often be 0. Let's not rely on that.
And yes, I know this is a lot of files. This is
a safer thing to do in big commits vs for loops.
5f7001e: "Added a new branch"
01456ed: "Fixed a lot of memory leaks"
dac4493: "Fixed all remaining memory leaks that I could figure out"
0792db7: "Removed the smnew macro and the call to _CrtSetDbgFlag()"
Some of these caused destructor-time problems due to static initialization
order fiasco and related issues. Notably, the program would no longer exit on
OSX and had to be killed.
There were probably legitimate fixes in here, but since these are monolithic
commits it's too much work to extract them now. Let's reapply them
individually and in the forward direction.
the debug output for the Debug and FastDebug project configurations. This
requires replacing all instances of new with a macro, smnew, that defines a
special form of new which outputs file and line number information along with
the memory leak details. This makes finding memory leaks much easier since you
can just double-click the leak in the output window and it will take you to the
line that caused it.
sukibaby