The global_alloc/global_free functions have outlived their usefulness.
They don't allow consistently overriding the default memory allocation
behaviour because they aren't used consistently, and we don't have
standard library allocator wrappers for them that we'd need to use them
consistently with all the standard library containers we're using. If
you need to change the default allocator behaviour, you can override the
new/delete operators, and there are ways to get more fine-grained
control that way. We're already doing that to pre-fill memory in debug
builds.
Code was already starting to depend on global_alloc/global_free wrapping
new/delete. For example some parts of the code (including the UI and
Windows debugger) was putting the result of global_alloc in a
std::unique_ptr wrappers without custom deleters, and the SPU sound
device was assuming it could use global_free to release memory allocated
with operator new. There was also code misunderstanding the behaviour
of global_alloc, for example the GROM port cartridge code was checking
for nullptr when a failure will actually throw std::bad_alloc.
As well as substituting new/delete, I've made several things use smart
pointers to reduce the chance of leaks, and fixed a couple of leaks,
too.
"byte per chunk" is sostituted by "data format"
data formats lesser than 9 work as before, data format 9 is 32 but floating point
in the debug_view_memory class method bytes_per_chunk is substituted by get_data_format, set_bytes_per_chunk is substituted by set_data_format
floating point values cannot be edited
currently floating point values are available only in the windows debugger, next commit will add them to the qt debugger, osx i won't be able to do it
afterwards 64 and 80 bit formats will be added
